I'm forced to use an NFS-share as home directory for a while. The mount is using default options -- nothing fancy: narawntapu:/green/home /home nfs rw 0 0 However, various things (browsers, Thunderbird) aren't working -- manifesting all sorts of very strange problems. Apparently, the underlying reason is the same for all of them -- SQLite3 can not operate on its database-files, which are used for much of the software's configuration nowadays. A very simple test-case is: % echo .databases | sqlite3 ~/meow.db Error: disk I/O error Using /tmp -- or any other local filesystem instead of ~/ -- works as expected. I used ktrace to see, what exactly is failing in sqlite3, and found this: 43469 sqlite3 CALL fcntl(0x3,F_SETLK,0x7fffffffb920) 43469 sqlite3 RET fcntl -1 errno 45 Operation not supported 43469 sqlite3 CALL write(0x2,0x7fffffffc8c0,0x16) 43469 sqlite3 GIO fd 2 wrote 22 bytes "Error: disk I/O error The NFS-server (narawntapu) has lock-daemon running: PID TT STAT TIME COMMAND 785 - Ss 0:02,00 /usr/sbin/rpc.lockd Neither the client nor the server have any kernel messages in the logs relating to this problem. Why is not F_SETLK working? I'm not expecting high performance, but I expect it to work...
Is rpc.lockd running on both the server and client? It needs to be on both.
Or use the "nolockd" mount option, which should work ok unless the locks need to be visible to other clients (which does not sound like it is the case here). Another alternative, if your NFS server supports it, is switching to NFSv4. Maybe a little more bothersome to configure, but does support file locking pretty well. (The rpc.lockd implements a crappy protocol called NLM, which can work ok, but should be avoided imho.)
(In reply to Alan Somers from comment #1) > Is rpc.lockd running on both the server and client? It needs to be on both. Yes, this is, what this was... I wish, there was some indication of the problem -- in the logs somewhere :( Thank you!