Bug 1395059 - [nfsv3] umount.nfs: Failed to find '' protocol
Summary: [nfsv3] umount.nfs: Failed to find '' protocol
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 26
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1395068
TreeView+ depends on / blocked
 
Reported: 2016-11-15 03:35 UTC by JianHong Yin
Modified: 2018-02-28 12:53 UTC (History)
17 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1395068 (view as bug list)
Environment:
Last Closed: 2018-02-28 12:53:03 UTC
Type: Bug


Attachments (Terms of Use)

Description JianHong Yin 2016-11-15 03:35:13 UTC
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

How reproducible:
always

Steps to Reproduce:
1. $ cat /etc/exports
/ *(ro,no_root_squash,crossmnt)
2. $ sudo systemctl restart nfs
3. $ sudo mount -overs=3  localhost:/  /mnt/nfsmp
4. $ ls /mnt/nfsmp/home
5. $ mount -t nfs
localhost:/ on /mnt/nfsmp 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:/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)
6. $ sudo umount  /mnt/nfsmp/home 
umount.nfs: Failed to find '' protocol
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ why ?
7. $ echo $?
0


Actual results:
umount output an error msg

Expected results:
should not output this error msg

Additional info:

Comment 1 JianHong Yin 2016-11-15 03:39:41 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)

Comment 2 Scott Mayhew 2016-11-15 21:16:23 UTC
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).

Comment 3 Steve Dickson 2016-11-16 17:53:12 UTC
(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

Comment 4 Scott Mayhew 2016-11-16 18:10:20 UTC
(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
#

Comment 5 Justin M. Forbes 2017-04-11 14:53:35 UTC
*********** 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.

Comment 6 Laura Abbott 2018-02-28 03:52:15 UTC
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.

Comment 7 JianHong Yin 2018-02-28 04:00:40 UTC
Hi Zhibin
  could you help to confirm if this issue is still in Fedora-27

Comment 8 Zhibin Li 2018-02-28 06:46:14 UTC
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)


--------------------------

Comment 9 Scott Mayhew 2018-02-28 12:53:03 UTC
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>


Note You need to log in before you can comment on or make changes to this bug.