Hi,
I have a question about NFS behaviour on etch.
Before filing a bug, perhaps people here can point out something I've
missed, or perhaps you know of this as an existing problem.
The scenario is this:
box A is an NFS server with one file system exported
(the mountpoint is the exported directory).
Just after rebooting A, clients B,C,D are unable to access the
filesystem exported by A.
If I then manually restart nfs-kernel-server, the clients are able to
access the filesystem exported by A.
Details:
box A, runs 'etch' (current stable) packages only.
exports one file system /data/A_1
we use NIS netgroups to control access
/etc/exports reads:
/data/A_1 @mygroup(rw,sync,root_squash,subtree_check)
/sbin/showmount -e gives:
/data/A_1 @mygroup
(I don't think this is occurring on other 'etch' machines acting in
similar roles, ie as NFS servers with one exported file system.)
box B,C,D are NFS clients.
also run 'etch' (current stable) packages only.
we use an NIS automount map for the clients.
The relevant line from the automount map (auto.DATA) is
A_1 A:/data/A_1
The automount attempt is made like this:
% ls /DATA/A_1
In /var/log/syslog and /var/log/daemon.log, I get messages like this:
Jan 7 17:49:22 b automount[9608]: mount(nfs): nfs: mount failure
a:/data/A_1 on /DATA/A_1
Now, until bug #428108 was fixed, we were using network ranges instead
of netgroups to limit access. I mention this because showmount -a shows
(and /var/lib/nfs/rmtab also shows) references to the network range mask
we used (but no longer use), as well as the netgroup.
The client systems are definitely in the right range of IP addresses,
and in the netgroup.
As far as I can tell this is limited to clients running 'etch',
machines still on 'sarge' have no issue. But I need to check that.
Stracing does not give many insights;
on the client I get only
stat64("/DATA/A_1", 0x805c8ac) = -1 ENOENT (No such file or directory)
lstat64("/DATA/A_1", 0x805c8ac) = -1 ENOENT (No such file or directory)
write(2, "/bin/ls: ", 9) = 9
write(2, "/DATA/A_1", 9) = 9
... some locale-related calls ...
write(2, ": No such file or directory", 27) = 27
on the server, I tried stracing rpc.mountd, but saw nothing "interesting",
just the log message written to /var/log/daemon.log
send(8, "<29>Jan 7 17:49:22 mountd[5741]: authenticated mount request
from B.atnf.CSIRO.AU:703 for /data/A_1 (/data/A_1)", 130,
MSG_NOSIGNAL) = 130
recording that a mount attempt was made.
Question: on the server, which process should I be stracing to see the
'permission denied' message being sent back?
Cheers
Vince
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
