FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 01-07-2008, 11:51 PM
Vincent McIntyre
 
Default nfs - odd behaviour of server after reboots

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 debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-08-2008, 12:28 AM
 
Default nfs - odd behaviour of server after reboots

... a followup, if I may ...


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


I also see this in the server strace, when the failure occurs:
open("/proc/fs/nfsd/filehandle", O_RDWR|O_LARGEFILE) = 9
write(9, "@mygroup /data/A_1 64
", 24) = -1 EPERM (Operation not permitted)
read(9, "", 4096) = 0
close(9) = 0

This does not occur on a successful automount attempt, instead I get:
open("/proc/fs/nfsd/filehandle", O_RDWR|O_LARGEFILE) = 10
write(10, "@mygroup /data/A_1 64
", 24) = 24
read(10, "x0100000000fe000502000000
", 4096) = 27
close(10) = 0


Cheers
Vince


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 01:24 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org