Fw: Linux/KDE and NFS locking on 7-stable

[Gerrit Kühn]

On Thu, 17 Sep 2009 11:03:55 -0400 (EDT) Rick Macklem
<rmacklem at uoguelph.ca> wrote about Re: Fw: Linux/KDE and NFS locking on
7-stable:

RM> > I upgraded a FreeBSD fileserver last week from 7.0-stable to
RM> > 7.2-stable and experience some weird problems now with Linux NFS
RM> > clients. The Linux Clients mount their home directories via nfs. I
RM> > usually use "nolock" on the client side, because file locking was
RM> > always troublesome in the past. On the Clients the users run kde 3.5
RM> > or 4.2. After the update of the server kde 3.5 quit starting up
RM> > (after logging in with kdm) on the spalsh screen and comes up with
RM> > some kind of I/O error when writing to the home dir. At the same
RM> > time the server complains about

RM> > kernel: NLM: failed to contact remote rpcbind, stat = 5, port = 28416

RM> I think this happens when the nlm in the server tries to contact the
RM> client. 

???
My NFS-Clients are accessing the server via a NAT router. There is no way
the server could contact the clients.

RM> I believe setting the following in the server's /etc/rc.conf
RM> and rebooting the server (or just killing off lockd on the server),
RM> combined with "nolock" as you have on the above Linux mount, might
RM> work ok:
RM>  	rpc_lockd_enable="NO"
RM>  	rpc_statd_enable="NO"

I did not try that so far, as there are some clients which seem to work
fine with locking.

RM> Imo, the nlm protocol was poorly designed and has always resulted in
RM> interoperability problems. Although I fiddle with NFS, I avoid the NLM
RM> like the plague:-)

Seems so. Why would one want to have a server contact a client anyway? :-)
Yesterday I played around with it some more, and have a solution now (at
least I hope so :-) with combining "nolock" with "tcp" on the client side.
I read some oder mails (from you?) here that stated problems with the new
server and strange combinations of mounting via udp and accessing via tcp
(although I did not look up what the Linux clients actually do).
Before I had either no protocol setting for the clients or they were
explicitely using udp (because that solved the problems I had with locking
when I was still using 7.0-stable :-).

RM> Good luck with it, rick
RM> ps: If you need to run the lockd on the server, starting the lockd in
RM>      the Linux client might help, although I'd still use "nolock" on
RM>      the Linux mount.

I think statd is running on the Linux client anyway. Will have to look for
lockd. Thanks for the hints. I still wonder a bit why nfs/locking is often
so much of a hassle. Shouldn't it be some kind of established standard
technique after all the years? Not that I would want to use smb instead,
but still... btw: are there any alternatives?


cu
  Gerrit