2003-11-25 16:17:39

by Matt Bernstein

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

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

2003-11-26 00:40:15

by Trond Myklebust

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

>>>>> " " == Matt Bernstein <mb/[email protected]> 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

2003-11-26 00:55:08

by Chris Wright

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

* Matt Bernstein (mb/[email protected]) 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

2003-11-26 01:35:34

by Trond Myklebust

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

>>>>> " " == Chris Wright <[email protected]> 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

2003-11-26 11:21:37

by Matt Bernstein

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

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