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)
Improve this question
5
  • @Archemar added fstab and exports entries. Commented Jul 3, 2020 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. Commented Jul 3, 2020 at 16:25
  • I was puzzled by nfs bind in fstab. may be you want to look at Gille's unix.stackexchange.com/questions/198590/what-is-a-bind-mount Commented Jul 4, 2020 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 wiki.archlinux.org/index.php/NFS I don't see how this gets us closer to the issue I'm having. Commented Jul 4, 2020 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. Commented Sep 1, 2021 at 16:08

1 Answer 1

Reset to default
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.

Improve this answer
0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.