I had two different cases concerning these directories. On 1 machine the directories weren't created at all. This happened after an upgrade from a previous version (can't remember which one). Adding them by hand and setting the right permissions solved the problem. If these directories aren't present with read/write access by the user that runs rpc.statd On another machine the directories were created but with the wrong permissions, breaking up the nfs daemon. The sm and sm.bak directories belonged to root in this case. Reproducible: Didn't try Steps to Reproduce: 1.emerge nfs-utils (being upgraded from a previous version to 1.0.6) Actual Results: Described in the details Expected Results: There need to be 2 directories in /var/lib/nfs called "sm" and "sm.bak" with read/write access by the user who runs rpc.statd. Thus : #ls -l /var/lib/nfs -rw-r--r-- 1 root root 0 Oct 7 01:56 etab -rw-r--r-- 1 root root 0 Oct 7 01:56 rmtab drwx------ 2 nobody root 4096 Oct 7 02:03 sm drwx------ 2 nobody root 4096 Oct 7 02:03 sm.bak -rw------- 1 nobody root 0 Oct 7 01:56 state -rw-r--r-- 1 root root 0 Oct 7 01:56 xtab solves the problem. The ebuild itself didn't produce any errors.
It happened to me today when I upgraded from 1.0.6 to 1.0.6-r1. I too had to create /var/lib/nfs/sm.bak, for user "nobody". I've never had this problem before.
added a hack to nfs-1.0.6-r3 to work around this stupid portage bug *** This bug has been marked as a duplicate of 16162 ***
