Description of problem: I have an nfsv4 mount, secured with kerberos, specified in /etc/fstab as: box:/ /mnt/box nfs4 sec=krb5,intr,soft 0 0 To be able to mount this automatically at boot time, it appears the "nfs-secure" service must be running. If I run 'systemctl start nfs-secure', then 'mount /mnt/box' mounts the share properly, but /mnt/box fails to mount automatically when booting. Trying to enable nfs-secure.service fails: # systemctl enable nfs-secure Failed to execute operation: No such file or directory What is the proper procedure to make a krb5 secured nfsv4 share mount at boot time ? I can make this work, so the /mnt/box share gets mounted at boot time, by manually running: ln -s /usr/lib/systemd/system/nfs-secure.service /etc/systemd/system/multi-user.target.wants/nfs-secure.service But since 'systemctl enable nfs-secure' should do something similar (??), there seem to be something wrong. Version-Release number of selected component (if applicable): nfs-utils-1.3.1-2.0.fc21.x86_64
(In reply to Nils Olav Selesdal from comment #0) > Description of problem: > > I have an nfsv4 mount, secured with kerberos, specified in /etc/fstab as: > > box:/ /mnt/box nfs4 > sec=krb5,intr,soft 0 0 > > To be able to mount this automatically at boot time, it appears the > "nfs-secure" service must be running. > If I run 'systemctl start nfs-secure', then 'mount /mnt/box' mounts the > share properly, but /mnt/box fails to mount automatically when booting. > > Trying to enable nfs-secure.service fails: > > # systemctl enable nfs-secure > Failed to execute operation: No such file or directory > > What is the proper procedure to make a krb5 secured nfsv4 share mount at > boot time ? > the nfs-secure.service is now a symlink to the rpc.gssd.service which now part of the nfs-client.target script, which should be enabled by default. Please check to see it is with systemctl status nfs-client.target The daemon will be automatically started with the existence of the /etc/krb5.keytab file. which means systemctl enable nfs-secure is no longer needed which is why it fails.
# systemctl status nfs-client.target nfs-client.target - NFS client services Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; disabled) Active: inactive (dead) Running 'systemctl enable nfs-client.target' solves this, and mounts the nfs share at boot. (Setting up an nfs client should probably be documented somewhere, or the nfs-client.target should be enabled automatically if /etc/fstab contains an nfs4 mount point)
(In reply to Nils Olav Selesdal from comment #2) > # systemctl status nfs-client.target > nfs-client.target - NFS client services > Loaded: loaded (/usr/lib/systemd/system/nfs-client.target; disabled) > Active: inactive (dead) > > > Running 'systemctl enable nfs-client.target' solves this, and mounts the > nfs share at boot. > > > (Setting up an nfs client should probably be documented somewhere, or the > nfs-client.target should be enabled automatically if /etc/fstab contains an > nfs4 mount point) Its the latter... I'll take care of it....
nfs-utils-1.3.1-4.0.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/FEDORA-2014-15315/nfs-utils-1.3.1-4.0.fc21
Package nfs-utils-1.3.1-4.0.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nfs-utils-1.3.1-4.0.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-15315/nfs-utils-1.3.1-4.0.fc21 then log in and leave karma (feedback).
I just installed this package. Something went horribly wrong with it. First, it took ages to install. The "yum update" was hanging at the installation of nfs-utils-1.3.1-4.0.fc21 without cpu nor disk activity. At some point, it continued without any message. After a reboot, the init process kept trying to start nfs client target (looking at the systemd screen output). So I could not get to the login prompt (not a nice behaviour BTW, one should expect network connections to fail occasionally). System is a notebook, connected to the network/internet via wifi. Wifi light was flashing during attempted boot, so it looks like there was some network activity. Up to date with current updates, updates-testing and rpmfusion (non)free updates and updates-testing. Kernel 3.17.7-300.fc21.x86_64, but failed on other kernels too (even on fc20 kernel). System is updated from fc20 and before. It took me a while to find out the nfs-client target was not starting and holding up boot. After disabling the nfs-client.target, boot went fine again. My /etc/fstab does not contain any NFS or any other remote mount, only a few entries for the local disk partitions. If I can be of any help in debugging this, please let me know.
(In reply to Bas Mevissen from comment #6) > I just installed this package. Something went horribly wrong with it. First, > it took ages to install. The "yum update" was hanging at the installation of > nfs-utils-1.3.1-4.0.fc21 without cpu nor disk activity. At some point, it > continued without any message. I've heard other complaints about the install taking forever... I didn't think it had to do with nfs-utils.... but maybe there is something timing out. > > After a reboot, the init process kept trying to start nfs client target > (looking at the systemd screen output). So I could not get to the login > prompt (not a nice behaviour BTW, one should expect network connections to > fail occasionally). The nfs-client.target is not started... it just enabled or disabled. If it is enable then other daemon are started. I see this: [ OK ] Reached target NFS client services Is that where its hanging? > > System is a notebook, connected to the network/internet via wifi. Wifi light > was flashing during attempted boot, so it looks like there was some network > activity. Up to date with current updates, updates-testing and rpmfusion > (non)free updates and updates-testing. Kernel 3.17.7-300.fc21.x86_64, but > failed on other kernels too (even on fc20 kernel). System is updated from > fc20 and before. > > It took me a while to find out the nfs-client target was not starting and > holding up boot. After disabling the nfs-client.target, boot went fine again. Would it be possible to show me the exact place the boot was hanging? Also what version of rpcbind are you using?
nfs-utils-1.3.1-4.1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/FEDORA-2014-15315/nfs-utils-1.3.1-4.1.fc21
Package nfs-utils-1.3.1-4.1.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing nfs-utils-1.3.1-4.1.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-15315/nfs-utils-1.3.1-4.1.fc21 then log in and leave karma (feedback).
nfs-utils-1.3.1-4.1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Steve Dickson from comment #7) > (In reply to Bas Mevissen from comment #6) > > I just installed this package. Something went horribly wrong with it. First, > > it took ages to install. The "yum update" was hanging at the installation of > > nfs-utils-1.3.1-4.0.fc21 without cpu nor disk activity. At some point, it > > continued without any message. > I've heard other complaints about the install taking forever... I didn't > think it had to do with nfs-utils.... but maybe there is something timing out. > It was exactly there and took ages. > The nfs-client.target is not started... it just enabled or disabled. If it > is enable then other daemon are started. I see this: > > [ OK ] Reached target NFS client services > > Is that where its hanging? > Yes, indeed. > Would it be possible to show me the exact place the boot was hanging? > Also what version of rpcbind are you using? Notebook has received updates in the mean time. So I cannot reproduce the exact situation any more. Would it be useful to enable the nfs-client.target again and see if it still hangs? I tried in a cleanly installed virtual machine and there it seems to be fine.
(In reply to Bas Mevissen from comment #11) > (In reply to Steve Dickson from comment #7) > > (In reply to Bas Mevissen from comment #6) > > > I just installed this package. Something went horribly wrong with it. First, > > > it took ages to install. The "yum update" was hanging at the installation of > > > nfs-utils-1.3.1-4.0.fc21 without cpu nor disk activity. At some point, it > > > continued without any message. > > I've heard other complaints about the install taking forever... I didn't > > think it had to do with nfs-utils.... but maybe there is something timing out. > > > > It was exactly there and took ages. > > > The nfs-client.target is not started... it just enabled or disabled. If it > > is enable then other daemon are started. I see this: > > > > [ OK ] Reached target NFS client services > > > > Is that where its hanging? > > > > Yes, indeed. > > > Would it be possible to show me the exact place the boot was hanging? > > Also what version of rpcbind are you using? > > Notebook has received updates in the mean time. So I cannot reproduce the > exact situation any more. Would it be useful to enable the nfs-client.target > again and see if it still hangs? > > I tried in a cleanly installed virtual machine and there it seems to be fine. OK... thanks for the information!