0

NFS has been working for more than a year with the current configuration but has recently developed this issue:

Ubuntu 20.04 Kernel 5.40.0-40 NFS nfs-kernel-server/focal-updates,focal-security,now 1:1.3.4-2.5ubuntu3.3 amd64 [installed]

systemctl restart nfs-server

Failed to restart nfs-server.service: Transaction order is cyclic. See system logs for details.
See system logs and 'systemctl status nfs-server.service' for details.

systemctl status :

 systemctl status nfs-server
 nfs-server.service - NFS server and services
 Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled; vendor preset: enabled)
 Drop-In: /run/systemd/generator/nfs-server.service.d
         └─order-with-mounts.conf
 Active: inactive (dead)

 Jul 03 06:37:38 acer systemd[1]: export-3T.mount: Found ordering cycle on nfs-server.service/start
 Jul 03 06:37:38 acer systemd[1]: export-3T.mount: Found dependency on export-3T.mount/start
 Jul 03 06:37:38 acer systemd[1]: export-3T.mount: Unable to break cycle starting with export-3T.mount/start
 Jul 03 06:43:47 acer systemd[1]: export-3T.mount: Found ordering cycle on nfs-server.service/start
 Jul 03 06:43:47 acer systemd[1]: export-3T.mount: Found dependency on export-3T.mount/start
 Jul 03 06:43:47 acer systemd[1]: export-3T.mount: Unable to break cycle starting with export-3T.mount/start

From journal

systemd[1]: Requested transaction contains an unfixable cyclic ordering dependency: Transaction order is cyclic. See system logs for det>
systemd[1]: export-3T.mount: Unable to break cycle starting with export-3T.mount/start
systemd[1]: export-3T.mount: Found dependency on export-3T.mount/start
systemd[1]: export-3T.mount: Found ordering cycle on nfs-server.service/start

/etc/fstab

UUID=uid /mnt/3T ext4 defaults 0 0 
/mnt/3T /export/3T nfs bind 0 0

/etc/exports

/export/3T 10.0.0.0/24(rw,nohide,insecure,no_subtree_check,async)
Stephen Boston
  • 1,928
  • 3
  • 25
  • 50
  • @Archemar added `fstab` and `exports` entries. – Stephen Boston Jul 03 '20 at 15:53
  • @Archemar Sorry. I don't follow. How am I hiding `3T` under a remote dir? `/export/3T` is local to the same host that is mounting `3T` to `/mnt`. I nfs-export from the `/export/` directory. I don't understand how that makes `/export` a remote directory? I don't doubt you, but please explain. – Stephen Boston Jul 03 '20 at 16:25
  • I was puzzled by `nfs bind` in `fstab`. may be you want to look at Gille's https://unix.stackexchange.com/questions/198590/what-is-a-bind-mount – Archemar Jul 04 '20 at 10:08
  • @Archemar That is to hide the server's file structure from NFS clients. I understand that to be fairly standard procedure. See `bind` in this article https://wiki.archlinux.org/index.php/NFS I don't see how this gets us closer to the issue I'm having. – Stephen Boston Jul 04 '20 at 15:03
  • Maybe the export process from NFS server is run before your bind mount. Did you try to : comment the export line in exports file, reboot (nfs server should start normally), then uncomment the line and restart the NFS server again. – JulienV Sep 01 '21 at 16:08

1 Answers1

0

Update

I was recently affected by this issue again, and the below didn't resolve the issue. I did find a "correct"(?) fix that has been stable for us.

The solution is to not put your mount in /etc/fstab. Rather, create a systemd mount unit for your mount point. Useful links include:

In your case, you'd want /etc/systemd/system/mnt-3T.mount that looks something like this (untested):

[Unit]
Description=3T mount
After=network.target

[Mount]
Where=/mnt/3T
Type=nfs
Options=bind

[Install]
WantedBy=multi-user.target

(I've never done an NFS bind mount before; you may need to tweak Requires= and After= to achieve the order you want)

Original Answer

This is a bit old, but I see various flavors of this issue reported in several places. For me, the key was https://bbs.archlinux.org/viewtopic.php?id=183999 or more specifically, adding DefaultDependencies=False to /usr/lib/systemd/system/nfs-client.target

The error message is surprisingly clear, but not necessarily intuitive. systemd has a cycle in the dependencies between units. The question is how to break that cycle. This blog describes the issue in more detail.

Also, the systemd unit manual pages describe default dependencies. For example, the target.target man page includes this:

Default Dependencies

The following dependencies are added unless DefaultDependencies=no is set:

  • Target units will automatically complement all configured dependencies of type Wants= or Requires= with dependencies of type After= unless DefaultDependencies=no is set in the specified units. Note that Wants= or Requires= must be defined in the target unit itself — if you for example define Wants=some.target in some.service, the automatic ordering will not be added.

In the case of NFS, I can't say explicitly what causes the cycle between the NFS server and the NFS client, but I can say empirically that when I disabled DefaultDependencies in the nfs-client.target, my problem went away. Cycle broken.

jwm
  • 231
  • 2
  • 6