Description of problem: On boot exports fail: Feb 02 15:19:05 localhost.localdomain systemd[1]: Starting NFS server and services... Feb 02 15:19:05 localhost.localdomain exportfs[912]: exportfs: Failed to resolve yflyer (and rest of export list fails similarly) Version-Release number of selected component (if applicable): nfs-utils-2.1.1-1.fc25.x86_64 How reproducible: every time Steps to Reproduce: 1. enable nfs-server to start on boot. Add exports to /etc/exports. Using NetworkManager to start wired network via dhcp. Have NetworkManager-wait-online.service enabled. 2. reboot 3. Actual results: exports are not exported Expected results: exports will be exported Additional info: Note error messages above: nfs server is trying to do export even before local host name is set from dhcp using systemd-hostnamed.service. Adding After=network-online.target to nfs-server.service solves the problem. I did not have this problem in Fedora 23 (I did not even have NetworkManager-wait-online enabled there) on the same machine (I just rebooted back into F23 to check). Openvpn also has the same problem (and the same solution works), so I don't know if this is a problem with nfs-utils or NetworkManager or systemd. Or perhaps a change that was made to NetworkManager or systemd that makes this addition necessary.
Started the upstream discussion http://marc.info/?l=linux-nfs&m=149157766819591&w=2
nfs-utils-2.1.1-4.rc2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-bca43e3f7e
nfs-utils-2.1.1-4.rc2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-218c78b2e7
Why do you only add Wants=network-online.target ? Wants= option is independent of After= option. So you should also add After=network-online.target, unless if you really do not want to care the order of that the network becomes online and that the NFS related services are started. See systemd.unit(5). In the description of the "Requires=" option, > If a unit foo.service requires a unit bar.service as configured > with Requires= and no ordering is configured with After= or Before=, > then both units will be started simultaneously and without any > delay between them if foo.service is activated.
I installed nfs-utils-2.1.1-4.rc2.fc25.x86_64 and moved my service file in /etc/systemd/system out of the way, disabled and re-enabled nfs-server and rebooted: [root@taylor ~]# journalctl -r -u nfs-server.service -- Logs begin at Mon 2017-01-16 13:19:53 CST, end at Tue 2017-04-11 14:11:28 CDT. -- Apr 11 14:10:41 localhost.localdomain systemd[1]: Started NFS server and services. Apr 11 14:10:41 localhost.localdomain exportfs[830]: exportfs: Failed to resolve laser so I agree that wants is not enough, my addition of after as above is what works for me. Restarting the nfs-server.service does bring it up.
(In reply to Yu Watanabe from comment #4) > Why do you only add Wants=network-online.target ? > Wants= option is independent of After= option. > So you should also add After=network-online.target, unless if you really do > not want to care the order of that the network becomes online and that the > NFS related services are started. There is the upstream discussion https://www.spinics.net/lists/linux-nfs/msg63132.html It seems the systemd.special(7) man page says to use Wants= Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a service that delays further execution until the network is sufficiently set up. What precisely this requires is left to the implementation of the network managing service.
(In reply to Steve Dickson from comment #6) > (In reply to Yu Watanabe from comment #4) > > Why do you only add Wants=network-online.target ? > > Wants= option is independent of After= option. > > So you should also add After=network-online.target, unless if you really do > > not want to care the order of that the network becomes online and that the > > NFS related services are started. > There is the upstream discussion > https://www.spinics.net/lists/linux-nfs/msg63132.html > > It seems the systemd.special(7) man page says to use Wants= > > Units that strictly require a configured network connection should > pull in network-online.target (via a Wants= type dependency) and > order themselves after it. This target unit is intended to pull in > a service that delays further execution until the network is > sufficiently set up. What precisely this requires is left to the > implementation of the network managing service. I read "and order themselves after it" to mean that you should also use After= along with Wants=.
nfs-utils-2.1.1-4.rc2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Tom Shield from comment #7) > I read "and order themselves after it" to mean that you should also use > After= along with Wants=. Yes. Right. Please do not close this bug. This bug is not fixed yet.
nfs-utils-2.1.1-4.rc2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Fedora Update System from comment #10) > nfs-utils-2.1.1-4.rc2.fc25 has been pushed to the Fedora 25 stable > repository. If problems still persist, please make note of it in this bug > report. Already did note that this is not fixed. See comment #5.
(In reply to Tom Shield from comment #5) > I installed nfs-utils-2.1.1-4.rc2.fc25.x86_64 and moved my service file in > /etc/systemd/system out of the way, disabled and re-enabled nfs-server and > rebooted: If you moved a service file out of the way, How do you expect things to work? > > [root@taylor ~]# journalctl -r -u nfs-server.service > -- Logs begin at Mon 2017-01-16 13:19:53 CST, end at Tue 2017-04-11 14:11:28 > CDT. -- > Apr 11 14:10:41 localhost.localdomain systemd[1]: Started NFS server and > services. > Apr 11 14:10:41 localhost.localdomain exportfs[830]: exportfs: Failed to > resolve laser > > so I agree that wants is not enough, my addition of after as above is what > works for me. > > Restarting the nfs-server.service does bring it up.
(In reply to Steve Dickson from comment #12) > (In reply to Tom Shield from comment #5) > > I installed nfs-utils-2.1.1-4.rc2.fc25.x86_64 and moved my service file in > > /etc/systemd/system out of the way, disabled and re-enabled nfs-server and > > rebooted: > If you moved a service file out of the way, How do you expect things to work? > Note the path. I moved my edited service file (as described in the original bug report) in /etc/systemd/system out of the way so that the updated one in /lib/systemd/system would be picked up and linked to by the enable command. When you put edited/custom service files in /etc/systemd/system (so updates don't over write them) you need to disable and enable the service again to get the links updated. Same is true when you remove a service file in /etc/systemd/system.
Note, I started an upstream discussion http://marc.info/?l=linux-nfs&m=149261158415078&w=2 Maybe you could add to it?
The upstream posting http://marc.info/?l=linux-nfs&m=149304767813604&w=2
just installed nfs-utils.x86_64 1:2.1.1-5.rc2.fc25 and rebooted. Nfs exports succeeded. Addition of After= network-online.target seems to have solved the problem. Thanks.