Bug 534616 - nfs4 mounts broken after update to kernel 2.6.27.29-0.1
Summary: nfs4 mounts broken after update to kernel 2.6.27.29-0.1
Status: RESOLVED DUPLICATE of bug 531633
Alias: None
Product: openSUSE 11.1
Classification: openSUSE
Component: Kernel (show other bugs)
Version: Final
Hardware: x86-64 openSUSE 11.1
: P5 - None : Normal with 10 votes (vote)
Target Milestone: ---
Assignee: Neil Brown
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-08-26 22:30 UTC by Michael Buchau
Modified: 2009-08-27 09:51 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
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 ***