More user reports: '{Random,Consistent} mount refusals'

I really don't know what to make of Debian bugs 81428 and 131811:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=81428&repeatmerged=yes
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=131811&repeatmerged=yes

Here is the most recent message from 81428. Please help me figure out what's going on here ... I'm mostly packaging and mostly not coding in NFS land, and these reports are awfully confusing.

----- Forwarded message from Adam C Powell IV <[email protected]> -----

Subject: Bug#81428: I'm still getting random mount refusals
From: Adam C Powell IV <[email protected]>
Date: Tue, 15 Jan 2002 09:58:39 -0500

Even with 1.0-2 on a 2.4.9 kernel which I rebooted yesterday, I'm still getting this problem. For a while I thought it was just a matter of being slow to respond to changes in /etc/exports (like, I make a change, but it doesn't take, then suddenly a few days later without restarting the server, it magically works and I can mount). I often try testing every day after a change, and it takes somewhere between five and eight days for the change to take effect. This goes both for netgroup, wildcard (*.domain.edu) and individual machine type entries in /etc/exports, for clients in /etc/hosts.

Last night, the server crashed (no idea why), so I rebooted, and remounted one of the dirs on the client machines while the server was still fscking it, so the fs was not mounted on the server, and the dir was empty. When the fsck was done and the dir mounted on the server, "ls /dir" on the client still showed it empty. This morning, I tried to unmount and remount, but got:

mount: <server>:/dir failed, reason given by server: Permission denied

Here's /var/log/messages on the server for this unmount-mount:

Jan 15 09:35:44 <server> rpc.mountd: authenticated unmount request from 
<client.domain.edu>:702 for /dir (/dir)
Jan 15 09:35:46 <server> rpc.mountd: authenticated mount request from 
<client.domain.edu>:703 for /dir (/dir)
Jan 15 09:35:46 <server> rpc.mountd: getfh failed: Operation not permitted

It's possible that kernels newer than 2.4.9 have fixed this, but 2.4.14 through 2.4.17 have been misidentifying my disk labels (I'm about to file a bug), so I can't test them on that server.

This bug is *so* annoying, I can't tell you, and has been since about the time this bug was submitted. Please don't close this until you know for certain it is fixed - until the submitter or (if you can't reach him/her) I confirms that it's fixed. I really hope it gets fixed before the woody release!

Zeen,

-Adam P.

GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8 564E E4B6

Welcome to the best software in the world today cafe! 
<http://lyre.mit.edu/%7Epowell/The_Best_Stuff_In_The_World_Today_Cafe.ogg>

----- End forwarded message -----

-- 
Chip Salzenberg         - a.k.a.  -        <[email protected]>
         "It furthers one to have somewhere to go."


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

81428 is the "you cannot export a directory and an ancestor of that directory both in the same filesystem" problem. In this case, /datadisk.

From the /etc/exports mentioned in the first email:
# Linux devices
/datadisk *.pangalhq.paul.de(rw,no_root_squash,no_subtree_check)
/datadisk/src *.pangalhq.paul.de(rw,no_root_squash,no_subtree_check)
/datadisk/old_stuff/ *.pangalhq.paul.de(ro)
/datadisk/projects labor(rw) idefix(rw,no_root_squash)

so all for /datadisk is rw, but all of /datadisk/old_stuff is ro. This is impossible.
If the second and third of these four lines are removed it should work.

This restriction is gone in 2.5.latest. I'll probably modify the user-space tools to do the check instead and to give better error messages.

NeilBrown

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs

131811 is hard to diagnose as there is little hard info. No /etc/exports etc.

I do note that:
server is running 2.3.18-pre4. I don't have any coherent patch history for what was happen that long ago, but I wouldn't be surprised if a pre-release of a devel kernel was broken.

error message was: ENOSYS
nfsservctl(0x1, 0xbfffcd08, 0) = -1 ENOSYS (Function not implemented)
nfsservctl(0x7, 0xbfffd9b8, 0x8055f60) = -1 ENOSYS (Function not implemented)

which suggests that nfsd support wasn't compiled into the kernel.

NeilBrown

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs