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
On Sunday September 15, [email protected] wrote:
> 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.
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
On Sunday September 15, [email protected] wrote:
> 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
>
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