2.6: can't lockf() over NFS

2.6: can't lockf() over NFS

[Matt Bernstein]

I can't get Debian testing to log in to GNOME when home directories are
mounted over NFS (Linux 2.6 client -> Linux 2.4-ac server). It claims not
to be able to lock a file..

I tried writing a trivial program to test lockf() and it returns ENOLCK 
over NFS, but succeeds locally. The client kernel offers some grumbles:

RPC: Can't bind to reserved port (13).
RPC: can't bind to reserved port.
nsm_mon_unmon: rpc failed, status=-5
lockd: cannot monitor a.b.c.d
lockd: failed to monitor a.b.c.d

[where a.b.c.d is our NFS server]

/sbin/rpc.statd is running on both client and server, and with a 2.4
kernel on the client (as the only change) GNOME logins and the lockf()  
test program work just fine.

Any ideas? I'm stumped at this point.

Cheers,

Matt

Re: 2.6: can't lockf() over NFS

[Trond Myklebust]

>>>>> " " == Matt Bernstein <mb/lkml@dcs.qmul.ac.uk> writes:

     > I can't get Debian testing to log in to GNOME when home
     > directories are mounted over NFS (Linux 2.6 client -> Linux
     > 2.4-ac server). It claims not to be able to lock a file..

IIRC Debian had some issues with rpc.statd. They were using some
incorrect compilation options. Try grabbing a newer version from
'unstable'.

Cheers,
  Trond

Re: 2.6: can't lockf() over NFS

[Chris Wright]

* Matt Bernstein (mb/lkml@dcs.qmul.ac.uk) wrote:
> I can't get Debian testing to log in to GNOME when home directories are
> mounted over NFS (Linux 2.6 client -> Linux 2.4-ac server). It claims not
> to be able to lock a file..
> 
> I tried writing a trivial program to test lockf() and it returns ENOLCK 
> over NFS, but succeeds locally. The client kernel offers some grumbles:
> 
> RPC: Can't bind to reserved port (13).
> RPC: can't bind to reserved port.
> nsm_mon_unmon: rpc failed, status=-5
> lockd: cannot monitor a.b.c.d
> lockd: failed to monitor a.b.c.d
> 
> [where a.b.c.d is our NFS server]
> 
> /sbin/rpc.statd is running on both client and server, and with a 2.4
> kernel on the client (as the only change) GNOME logins and the lockf()  
> test program work just fine.
> 
> Any ideas? I'm stumped at this point.

Yes, can you either change your config to:

CONFIG_SECURITY=n

or:

CONFIG_SECURITY=y
CONFIG_SECURITY_CAPABILITIES=y

or:

CONFIG_SECURITY=y
CONFIG_SECURITY_CAPABILITIES=m
and modprobe capability

Thanks, this had fallen off my radar.
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net

Re: 2.6: can't lockf() over NFS

[Trond Myklebust]

>>>>> " " == Chris Wright <chrisw@osdl.org> writes:

     > Yes, can you either change your config to:

     > CONFIG_SECURITY=n

     > or:

     > CONFIG_SECURITY=y CONFIG_SECURITY_CAPABILITIES=y

     > or:

     > CONFIG_SECURITY=y CONFIG_SECURITY_CAPABILITIES=m and modprobe
     > capability

Sorry, yes. That one slipped my mind...

Cheers,
  Trond

Re: 2.6: can't lockf() over NFS

[Matt Bernstein]

On Nov 25 Chris Wright wrote:

>> I tried writing a trivial program to test lockf() and it returns ENOLCK 
>> over NFS, but succeeds locally. The client kernel offers some grumbles:
>> 
>> RPC: Can't bind to reserved port (13).
>> RPC: can't bind to reserved port.
>> nsm_mon_unmon: rpc failed, status=-5
>> lockd: cannot monitor a.b.c.d
>> lockd: failed to monitor a.b.c.d

>Yes, can you either change your config to:
>
>CONFIG_SECURITY=n
>
>or:
>
>CONFIG_SECURITY=y
>CONFIG_SECURITY_CAPABILITIES=y
>
>or:
>
>CONFIG_SECURITY=y
>CONFIG_SECURITY_CAPABILITIES=m
>and modprobe capability
>
>Thanks, this had fallen off my radar.

Thank you, problem solved :)