as title. First, that nfs server is fine, other client can mount, and only one client (A) can't. If I try to go into the mount point, it just stuck there and there is no output, even an error. So I have to do ctrl+c to stop it, and I got "bad directory" messages. Here is whole picture. Client A --- Can't mount NFS server B, but A can mount other servers like, C, D. NFS server B can be mounted by other client, like E, F.... I have checked everything, but couldn't find out. It was fine in the morning, and in the afternoon, it happend. And it acutally happened once, and I couldn't figure out, and have to make a reboot to solve this problem. Any idea?
![]() |
0 |
![]() |
Don't you see this filesystem mounted when run "mount" command without arguments on client A? Have you tried to reboot client A? If yes, do you get any error messages from "mount" command? Anything suspicious in /var/adm/messages on both machines? To me, it all looks like "stale NFS handle" - the exported filesystem's layout has changed while client A had it mounted. Usually, reboot of client A helps. Regards, Andrei
![]() |
0 |
![]() |
Is reboot the only solution? I can see it from output of mount command. Here is the info from /var/adm/messages. Mar 8 10:04:05 jupiter nfs: [ID 265537 kern.notice] NFS write error on host Mars: Not owner. Mar 8 10:04:05 jupiter nfs: [ID 702911 kern.notice] (file handle: 2e050100 f00 f9640300 100 45f03666 42040000 cb310600 cf050000) Mar 8 10:04:05 jupiter nfs: [ID 265537 kern.notice] NFS write error on host Mars: Not owner. Mar 8 10:04:05 jupiter nfs: [ID 702911 kern.notice] (file handle: 2e050100 f00 f9640300 100 45f03666 42040000 cb310600 cf050000) Mar 8 10:04:05 jupiter nfs: [ID 265537 kern.notice] NFS write error on host Mars: Not owner. This NFS server Mars is a window 2003 server, and there another sun box can mount this NFS share correctly. Last time it couldn't mount a FS from another sun server. Thanks for the help. <aryzhov@spasu.net> wrote in message news:1173892677.466250.68670@y66g2000hsf.googlegroups.com... > Don't you see this filesystem mounted > when run "mount" command without arguments > on client A? > Have you tried to reboot client A? > If yes, do you get any error messages from "mount" command? > Anything suspicious in /var/adm/messages on both machines? > > To me, it all looks like "stale NFS handle" - > the exported filesystem's layout has changed while client A > had it mounted. Usually, reboot of client A helps. > > Regards, > Andrei > >
![]() |
0 |
![]() |
On Mar 15, 3:53 am, "steeles" <stee...@gmail.com> wrote: > Is reboot the only solution? > You can try umount -f MOUNTPOINT on the client, where MOUNTPOINT is the directory OR server:/PATH that you can see when run "mount" command without arguments. If "umount -f" does not work, client's reboot is the only option. Please post more details on how the filesystem is exported on the server - NFS version (2,3, or 4), export options, and about clients's default NFS version (you can see it in /etc/default/nfs text file) Another crude guess - try to remount on the fly, possibly forcing another NFS version, for instance: mount -o rw,vers=3,remount server:/PATH MOUNTPOINT I never tried to change the version via remount. Should not harm, anyway. Regards, Andrei
![]() |
0 |
![]() |
Those are setting in /etc/default/nfs file NFSD_LISTEN_BACKLOG=32 NFSD_PROTOCOL=ALL NFSD_SERVERS=16 LOCKD_LISTEN_BACKLOG=3 LOCKD_SERVERS=20 LOCKD_RETRANSMIT_TIMEOUT=5 GRACE_PERIOD=90 #NFS_SERVER_DELEGATION=on #NFS_SERVER_VERSMAX=4 #NFS_CLIENT_VERSMIN=2 under /etc/mnttab /etc/auto_direct /dev autofs direct,ignore,dev=5500004 1173750927 Mars:/K/dev /dev nfs rw,xattr,dev=54c0142 1173973894 when I do rpcinfo, I believe it is using version 3. Thanks. <aryzhov@spasu.net> wrote in message news:1173946754.151271.276510@e1g2000hsg.googlegroups.com... > On Mar 15, 3:53 am, "steeles" <stee...@gmail.com> wrote: >> Is reboot the only solution? >> > > You can try umount -f MOUNTPOINT > on the client, where MOUNTPOINT is the directory > OR server:/PATH that you can see > when run "mount" command without arguments. > > If "umount -f" does not work, client's reboot > is the only option. > > Please post more details on how the > filesystem is exported on the server - NFS version (2,3, or 4), > export options, > and about clients's default NFS version (you can see it in > /etc/default/nfs text file) > > Another crude guess - try to remount > on the fly, possibly forcing another NFS version, > for instance: > mount -o rw,vers=3,remount server:/PATH MOUNTPOINT > > I never tried to change the version > via remount. Should not harm, anyway. > > Regards, > Andrei >
![]() |
0 |
![]() |
> under /etc/mnttab > > /etc/auto_direct /dev autofs direct,ignore,dev=5500004 > 1173750927 > Mars:/K/dev /dev nfs rw,xattr,dev=54c0142 1173973894 Out of curiosity, what exactly are you trying to achieve by keeping /dev on a remote filesystem? For me, unpredictable system behavior would be the very first thing to expect as result of such mount. Regards, Andrei
![]() |
0 |
![]() |
sorry man, wrong one. it should be /etc/auto_direct /window autofs direct,ignore,dev=5500004 1173750927 Mars:/K/users /window nfs rw,xattr,dev=54c0142 1173973894 <aryzhov@spasu.net> wrote in message news:1173981859.674055.96990@l75g2000hse.googlegroups.com... > >> under /etc/mnttab >> >> /etc/auto_direct /dev autofs direct,ignore,dev=5500004 >> 1173750927 >> Mars:/K/dev /dev nfs rw,xattr,dev=54c0142 1173973894 > > Out of curiosity, what exactly are you trying to achieve > by keeping /dev on a remote filesystem? > For me, unpredictable system behavior would be > the very first thing to expect as result of such mount. > > Regards, > Andrei > >
![]() |
0 |
![]() |