| Summary: | [nfsv3] umount.nfs: Failed to find '' protocol | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | JianHong Yin <jiyin> | |
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | unspecified | |||
| Version: | 26 | CC: | bcodding, bfields, carsten.grohmann, gansalmon, ichavero, itamar, jiyin, jlayton, jonathan, kernel-maint, madhu.chinakonda, mchehab, smayhew, steved, xzhou, yoyang, zhibli | |
| Target Milestone: | --- | |||
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | ||
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1395068 (view as bug list) | Environment: | ||
| Last Closed: | 2018-02-28 12:53:03 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: | ||
| Bug Depends On: | ||||
| Bug Blocks: | 1395068 | |||
|
Description
JianHong Yin
2016-11-15 03:35:13 UTC
Additional info: test with nfsv4, there's not this problem. $ sudo mount -overs=4.0 localhost:/ /mnt/nfsmp $ ls /mnt/nfsmp/boot /mnt/nfsmp/home /mnt/nfsmp/boot: config-4.5.5-300.fc24.x86_64 grub2 lost+found vmlinuz-4.5.5-300.fc24.x86_64 config-4.5.7-300.fc24.x86_64 initramfs-0-rescue-1d9b0263e1ff4dc196101629c084355d.img memtest86+-5.01 vmlinuz-4.5.7-300.fc24.x86_64 config-4.6.3-300.fc24.x86_64 initramfs-4.5.5-300.fc24.x86_64.img System.map-4.5.5-300.fc24.x86_64 vmlinuz-4.6.3-300.fc24.x86_64 efi initramfs-4.5.7-300.fc24.x86_64.img System.map-4.5.7-300.fc24.x86_64 elf-memtest86+-5.01 initramfs-4.6.3-300.fc24.x86_64.img System.map-4.6.3-300.fc24.x86_64 extlinux initrd-plymouth.img vmlinuz-0-rescue-1d9b0263e1ff4dc196101629c084355d /mnt/nfsmp/home: backup ftp lost+found VMImages $ ls /mnt/nfsmp/boot /mnt/nfsmp/home -d /mnt/nfsmp/boot /mnt/nfsmp/home $ mount -t nfs4 localhost:/ on /mnt/nfsmp type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1) localhost:/boot on /mnt/nfsmp/boot type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1) localhost:/home on /mnt/nfsmp/home type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,port=0,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1) $ sudo umount /mnt/nfsmp/home $ sudo umount /mnt/nfsmp/boot $ mount -t nfs4 localhost:/ on /mnt/nfsmp type nfs4 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,clientaddr=::1,local_lock=none,addr=::1) The problem is the empty 'mountproto=' option on this line:
localhost:/home on /mnt/nfsmp/home type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,mountproto=,local_lock=none,addr=::1)
^^^^^^^^^^^
That happens because the nfs_server->mountd_protocol field (among others) doesn't get set when a v3 submount is created.
The umount.nfs program reads in the mount options from the /etc/mtab. On systems where mtab is a symlink to /proc/mounts, you wind up getting that error when the program tries to validate the 'mountproto=' option.
I can reproduce this from git going all the way back to the 1.2.3 branch (probably further, but after that I start having problems compiling due to F24 not having old stuff like libgssglue and librpcsecgss). But if I jump over to RHEL6, which also uses nfs-utils version 1.2.3 it works fine. That's because /etc/mtab isn't a symlink to /proc/mounts on RHEL6.
The easiest fix seems to be to not display the 'mountproto' option in /proc/mounts if it's not set (http://marc.info/?l=linux-nfs&m=147924359703972&w=2).
(In reply to Yin.JianHong from comment #0) > Description of problem: > Got an error message when do umount /nfs_mountpoint > > Version-Release number of selected component (if applicable): > [yjh@dhcp-12-116 ~]$ rpm -q nfs-utils > nfs-utils-1.3.3-8.rc5.fc24.x86_64 Try updating both the kernel and nfs-utils I'm unable to reproduce this with nfs-utils-1.3.4-1.rc2.fc24 kernel-4.8.6-201.fc24 (In reply to Steve Dickson from comment #3) > (In reply to Yin.JianHong from comment #0) > > Description of problem: > > Got an error message when do umount /nfs_mountpoint > > > > Version-Release number of selected component (if applicable): > > [yjh@dhcp-12-116 ~]$ rpm -q nfs-utils > > nfs-utils-1.3.3-8.rc5.fc24.x86_64 > Try updating both the kernel and nfs-utils > I'm unable to reproduce this with > nfs-utils-1.3.4-1.rc2.fc24 > kernel-4.8.6-201.fc24 Those are the same versions I'm running. Are you using a separate filesystem for for the directory that you're doing the ls on? If not, then doing the ls is just going to list the contents of the directory and not trigger a submount. The easiest way to reproduce this is to create a small fs on a loopback device, e.g. # dd if=/dev/zero of=fs.img bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 4.21247 s, 249 MB/s # losetup /dev/loop0 fs.img # mkfs.ext4 /dev/loop0 mke2fs 1.42.13 (17-May-2015) Discarding device blocks: done Creating filesystem with 256000 4k blocks and 64000 inodes Filesystem UUID: 996f1aa8-2bbd-4c0e-94fb-dd51ec906818 Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done # mkdir /export/foo # mount /dev/loop0 /export/foo # systemctl start nfs-server # mount -o v3 localhost:/export /mnt/t # ls /mnt/t/foo lost+found # umount /mnt/t/foo umount.nfs: Failed to find '' protocol # *********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 25 has now been rebased to 4.10.9-100.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those. We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. The kernel moves very fast so bugs may get fixed as part of a kernel update. Due to this, we are doing a mass bug update across all of the Fedora 26 kernel bugs. Fedora 26 has now been rebased to 4.15.4-200.fc26. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 27, and are still experiencing this issue, please change the version to Fedora 27. If you experience different issues, please open a new bug report for those. Hi Zhibin could you help to confirm if this issue is still in Fedora-27 Ok, I've checked it on fedora 27, kernel version 4.15.4-300.fc27.x86_64 and it seems that the bug no longer exists. -------------------------- # dd if=/dev/zero of=fs.img bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 0.632306 s, 1.7 GB/s # losetup /dev/loop0 fs.img # mkfs.ext4 /dev/loop0 mke2fs 1.43.5 (04-Aug-2017) Discarding device blocks: done Creating filesystem with 256000 4k blocks and 64000 inodes Filesystem UUID: 5066f37c-5811-4b8f-a66c-3340e780a579 Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: done Writing inode tables: done Creating journal (4096 blocks): done Writing superblocks and filesystem accounting information: done # mkdir -p /export/foo # mount /dev/loop0 /export/foo/ # echo '/export *(ro,no_root_squash,crossmnt)' >/etc/exports # systemctl restart nfs.service # exportfs -v /export <world>(ro,sync,wdelay,hide,crossmnt,no_subtree_check,sec=sys,secure,no_root_squash,no_all_squash) # mount -o vers=3 localhost:/export /mnt/bz-test/ # ls /mnt/bz-test/foo/ lost+found # mount -l|grep mnt localhost:/export on /mnt/bz-test type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,mountaddr=::1,mountvers=3,mountport=20048,mountproto=udp6,local_lock=none,addr=::1) localhost:/export/foo on /mnt/bz-test/foo type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,local_lock=none,addr=::1) #the subdir is now mounted too and we can see the proto=tcp6 # umount /mnt/bz-test/foo #it works # mount -t nfs localhost:/export on /mnt/bz-test type nfs (rw,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp6,timeo=600,retrans=2,sec=sys,mountaddr=::1,mountvers=3,mountport=20048,mountproto=udp6,local_lock=none,addr=::1) -------------------------- This was fixed by this commit
commit 6f6e3c09c0dde7fbaf36f02ffa97bbb13fecd637
Author: NeilBrown <neilb>
Date: Fri Jan 13 11:04:27 2017 +1100
NFS: tidy up nfs_show_mountd_netid
This function is a bit clumsy, incorrectly producing
",mountproto=" if mountd_protocol is 0 and !showdefaults,
and duplicating the code for reporting "auto".
Tidy it up so that it only makes a single seq_printf() call,
and more obviously does the right thing.
Fixes: ee671b016fbf ("NFS: convert proto= option to use netids rather than a protoname")
Signed-off-by: NeilBrown <neilb>
Signed-off-by: Anna Schumaker <Anna.Schumaker>
|