Bug 534616

Summary:	nfs4 mounts broken after update to kernel 2.6.27.29-0.1
Product:	[openSUSE] openSUSE 11.1	Reporter:	Michael Buchau <mike>
Component:	Kernel	Assignee:	Neil Brown <nfbrown>
Status:	RESOLVED DUPLICATE	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None	CC:	ba, meissner
Version:	Final
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE 11.1
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Michael Buchau 2009-08-26 22:30:10 UTC

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.2) Gecko/20090730 SUSE/3.5.2-2.1 Firefox/3.5.2

After installing the recent update kernel 2.6.27.29-0.1, nfs4 mounting fails with the error

mount.nfs4: an incorrect mount option was specified

Reproducible: Always

Steps to Reproduce:
1. Set up an NFSv4 server with an export root directory /export and run
   exportfs -o fsid=0,insecure,root_squash,no_subtree_check *:/export

2. Mount additional filesystem to be exported
   mkdir /export/srv
   mount --bind /srv /export/srv

3. Export the additional filesystem
   exportfs -o nohide,insecure,root_squash,no_subtree_check *:/export/srv

4. Try mounting this filesystem
   mount -t nfs4 -o hard,intr nfsserver:/srv /mnt
Actual Results:  
mount.nfs4: an incorrect mount option was specified

Expected Results:  
The mount command should succeed and the contents of /export/srv on the NFSv4 server should appear on the NFSv4 client under /mnt

Mounting the export root with

mount -t nfs4 -o ro,hard,intr nfsserver:/ /mnt

succeeds.

If you omit the "nohide" option from the exportfs command in step 3 above, the mount in step 4 will succeed but you will only see the mountpoint directory without any content.

Comment 1 Bernhard Amann 2009-08-27 06:17:22 UTC

I have the same bug on openSUSE x86 32 bit, after applying the kernel update.

Debugging with /proc/sys/sunrpc/nfs_debug = 1 gives the following output:

Aug 27 08:15:10 linux-glyw kernel: NFS: nfs_fhget(0:14/70645174 ct=1)
Aug 27 08:15:10 linux-glyw kernel: NFS: permission(0:14/70645174), mask=0x1, res=0
Aug 27 08:15:10 linux-glyw kernel: NFS: atomic_lookup(0:14/70645174), home
Aug 27 08:15:10 linux-glyw kernel: NFS: lookup(/home)
Aug 27 08:15:10 linux-glyw kernel: NFS: nfs_fhget(0:14/128 ct=1)
Aug 27 08:15:10 linux-glyw kernel: --> nfs_follow_mountpoint()
Aug 27 08:15:10 linux-glyw kernel: nfs_follow_mountpoint: enter
Aug 27 08:15:10 linux-glyw kernel: --> nfs_do_submount()
Aug 27 08:15:10 linux-glyw kernel: nfs_do_submount: submounting on /home
Aug 27 08:15:10 linux-glyw kernel: --> nfs4_xdev_get_sb()
Aug 27 08:15:10 linux-glyw kernel: NFS: nfs_fhget(0:15/128 ct=1)
Aug 27 08:15:10 linux-glyw kernel: <-- nfs4_xdev_get_sb() = 0
Aug 27 08:15:10 linux-glyw kernel: nfs_do_submount: done
Aug 27 08:15:10 linux-glyw kernel: <-- nfs_do_submount() = f5863e40
Aug 27 08:15:10 linux-glyw kernel: NFS: dentry_delete(/, 4)
Aug 27 08:15:10 linux-glyw kernel: nfs_follow_mountpoint: done, returned -22
Aug 27 08:15:10 linux-glyw kernel: <-- nfs_follow_mountpoint() = -22
Aug 27 08:15:10 linux-glyw kernel: NFS: dentry_delete(/home, 0)
Aug 27 08:15:10 linux-glyw kernel: <-- nfs4_get_sb() = -22 [error]

Comment 2 Neil Brown 2009-08-27 09:51:10 UTC

This is bug has been fixed but hasn't made it into a released kernel yet.
See bug #531633

*** This bug has been marked as a duplicate of bug 531633 ***