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?

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

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
>
> 

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

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
> 

> 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

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
>
>