Re: nfs insecure_locks / Tru64 behaviour

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Thu, 2005-12-22 at 08:36 -0500, Ron Peterson wrote:
> If I mount a linux export on Tru64, it seems the execute bit for 'other'
> needs to be set on a directory in order edit files within it using vi.
> 'Nobody' and 'nogroup' also appear to be special.

man 5 exports

read all about the "no_root_squash" option

As for your problem accessing files in the directory

drwxr-x---  2 root     system  4096 Dec 22 08:22 d/

as an unprivileged user on group 'kmw', the solution is obvious:

'chgrp kmw d'

or

chmod a+x d

Cheers,
  Trond

> I'm running 2.6.14.3 on Debian Sarge.
> 
> For example.
> 
> On linux, in directory /db/test:
> 
> 1185# ll
> total 16
> drwxr-x--x  2 root     kmw     4096 Dec 21 22:39 a/
> drwxr-x---  2 nobody   kmw     4096 Dec 21 22:39 b/
> drwxr-x---  2 rpeterso nogroup 4096 Dec 21 22:46 c/
> drwxr-x---  2 root     system  4096 Dec 22 08:22 d/
> 
> where /etc/exports looks like
> 
> /db/test  \
>               depot.p(rw,sync) \
>               polar.p(rw,sync,insecure_locks)
> 
> I mount this on Tru64 like:
> 
> mount -o tcp yogi.p:/db/test dbtest
> 
> Each directory a,b,c,d has a small text file named 'test':
> 
> -rw-rw-r--  1 root kmw 5 Dec 21 22:39 test
> 
> As a user in group kmw I can edit this file in directory a, b, and c.  I
> can't edit the file in directory d.
> 
> I understand that Tru64 doesn't send matching credentials with nfs lock
> requests.  The 'insecure_locks' option seems to help work around
> permission problems on the files themselves, but doesn't seem to work
> around the permissions of the owning directory.
> 
> It's probably fair to point fingers at Tru64, but it seems unlikely
> there will be any changes to nfs on that side...
> 
> I'm not subscribed the lkml, so cc's are appreciated.
> 
> Best.
>