Bug 1173564
| Summary: | Cannot properly enable the nfs-secure service | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nils Olav Selåsdal <nos> | |
| Component: | nfs-utils | Assignee: | Steve Dickson <steved> | |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | unspecified | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 21 | CC: | abuse, bfields, jlayton, steved | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | nfs-utils-1.3.1-4.1.fc21 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1245804 (view as bug list) | Environment: | ||
| Last Closed: | 2015-01-14 07:28:27 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1245804 | |||
|
Description
Nils Olav Selåsdal
2014-12-12 12:28:04 UTC
(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! |