Date: Fri, 18 Sep 2009 09:14:35 +0200 From: Gerrit =?ISO-8859-1?Q?K=FChn?= <gerrit@pmp.uni-hannover.de> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs@freebsd.org Subject: Re: Fw: Linux/KDE and NFS locking on 7-stable Message-ID: <20090918091435.465bfc1e.gerrit@pmp.uni-hannover.de> In-Reply-To: <Pine.GSO.4.63.0909171056210.1169@muncher.cs.uoguelph.ca> References: <20090917094412.962e8729.gerrit@pmp.uni-hannover.de> <Pine.GSO.4.63.0909171056210.1169@muncher.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 17 Sep 2009 11:03:55 -0400 (EDT) Rick Macklem <rmacklem@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090918091435.465bfc1e.gerrit>