Date: Thu, 17 Sep 2009 11:03:55 -0400 (EDT) From: Rick Macklem <rmacklem@uoguelph.ca> To: =?utf-8?B?R2Vycml0IEvDvGhu?= <gerrit@pmp.uni-hannover.de> Cc: freebsd-fs@freebsd.org Subject: Re: Fw: Linux/KDE and NFS locking on 7-stable Message-ID: <Pine.GSO.4.63.0909171056210.1169@muncher.cs.uoguelph.ca> In-Reply-To: <20090917094412.962e8729.gerrit@pmp.uni-hannover.de> References: <20090917094412.962e8729.gerrit@pmp.uni-hannover.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Sep 2009, Gerrit Kühn wrote:
>
> I upgraded a FreeBSD fileserver last week from 7.0-stable to 7.2-stable
> and experience some weird problems now with Linux NFS clients.
> The Linux Clients mount their home directories via nfs. I usually use
> "nolock" on the client side, because file locking was always troublesome
> in the past. On the Clients the users run kde 3.5 or 4.2.
> After the update of the server kde 3.5 quit starting up (after logging
> in with kdm) on the spalsh screen and comes up with some kind of I/O error
> when writing to the home dir. At the same time the server complains about
>
> kernel: NLM: failed to contact remote rpcbind, stat = 5, port = 28416
>
I think this happens when the nlm in the server tries to contact the
client. I believe setting the following in the server's /etc/rc.conf
and rebooting the server (or just killing off lockd on the server),
combined with "nolock" as you have on the above Linux mount, might
work ok:
rpc_lockd_enable="NO"
rpc_statd_enable="NO"
Imo, the nlm protocol was poorly designed and has always resulted in
interoperability problems. Although I fiddle with NFS, I avoid the NLM
like the plague:-)
Good luck with it, rick
ps: If you need to run the lockd on the server, starting the lockd in
the Linux client might help, although I'd still use "nolock" on
the Linux mount.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.63.0909171056210.1169>