On Sunday 09 September 2007 21:45:58 James G. Sack (jim) wrote:
> Dexter Filmore wrote:
> > This just came out of thin air: I wanted to cd into this dir:
> >
> > drwxrwx--- 23 root schrcknt 4096 2007-04-13 16:19 other
> >
> > and got a "permission denied" error.
> >
> > The group ids of schrcknt match on server and client, I am in that group
> > still can't dive. As root all fine.
> > It's been working just fine and I don't remember changing anything.
> > Pointers?
>
> Maybe you could post the output of
>   mount -v | grep other
> and
>   id
>

fstab mount options on client:
xerxes:/mnt/data/other on /mnt/xerxes/other type nfs 
(rw,wsize=8192,rsize=8192,intr,soft,timeo=20,addr=192.168.0.2)

Serverside (Slackware 11):
uid=1000(dexter) gid=100(users) Gruppen=6(disk),11(floppy),18(video),100
(users),102(audio),105(antivir),120(schrcknt)

Clientside (Kubuntu 7.04):
uid=1000(dexter) gid=1000(dexter) Gruppen=4(adm),6(disk),20(dialout),24
(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),100(users),104
(scanner),112(netdev),113(lpadmin),115(powerdev),117(fuse),118(admin),120
(schrcknt),1000(dexter),1001(vboxusers)


> just so we could get a better feel for the situation?
>
> I can't recall whether nfsstat -c gives anything useful, but you might
> read man nfsstat, and play with it.
>

nfsstat beats me, if you can get anything useful out of this I'm all ears.

$ nfsstat -c
Client rpc stats:
calls      retrans    authrefrsh
402        0          0

Client nfs v3:
null         getattr      setattr      lookup       access       readlink
0         0% 330      82% 0         0% 5         1% 42       10% 0         0%
read         write        create       mkdir        symlink      mknod
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
remove       rmdir        rename       link         readdir      readdirplus
0         0% 0         0% 0         0% 0         0% 0         0% 3         0%
fsstat       fsinfo       pathconf     commit
11        2% 10        2% 0         0% 0         0%

Client nfs v4:
null         read         write        commit       open         open_conf
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
open_noat    open_dgrd    close        setattr      fsinfo       renew
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
setclntid    confirm      lock         lockt        locku        access
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
getattr      lookup       lookup_root  remove       rename       link
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
symlink      create       pathconf     statfs       readlink     readdir
0         0% 0         0% 0         0% 0         0% 0         0% 0         0%
server_caps  delegreturn
0         0% 0         0%



> If you have access to the logfiles on the server, there might be clues
> there.
>
For reasons beyond me nfsd has no logs. Will check scripts.

I chgrp'ed to "users" on the sever and it worked on the spot. Changed 
back - !perm.
What's really odd is that I can't remember changing anything here and this 
setup has been working for months.
It-worked-the-other-day classic.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCS d--(+)@ s-:+ a- C++++ UL++ P+>++ L+++>++++ E-- W++ N o? K-
w--(---) !O M+ V- PS+ PE Y++ PGP t++(---)@ 5 X+(++) R+(++) tv--(+)@ 
b++(+++) DI+++ D- G++ e* h>++ r* y?
------END GEEK CODE BLOCK------

http://www.stop1984.com
http://www.againsttcpa.com


-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list

Reply via email to