I have now upgraded both my desktop (sybil) and laptop (basil) to 11.10. For several years now, NFS has worked successfully. I have been using the same procedures and now they no longer work and come back with error. The error message on basil is:
My hosts file on basil has:
And my hosts.allow on basil has:
Naturally my hosts.deny has ALL: ALL
My exports file on basil has:
Last but not least my fstab on basil has:
I have the complementary entries on sybil to access basil.
As far as i can tell this is an outstanding kernel bug. Has anyone been able to get around this NFS problem or even get NFS to work? It is such a pain to no longer have NFS available
.
An error occurred while accessing '/home/aurora on sybil', the system responded: mount.nfs: rpc.statd is not running but is required for remote locking.
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified
mount.nfs: Either use '-o nolock' to keep locks local, or start statd.
mount.nfs: an incorrect mount option was specified
Code:
127.0.0.1 localhost 127.0.1.1 basil 192.168.10.4 sybil # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters
Code:
# /etc/hosts.allow: list of hosts that are allowed to access the system. # See the manual pages hosts_access(5) and hosts_options(5). # # Example: ALL: LOCAL @some_netgroup # ALL: .foobar.edu EXCEPT terminalserver.foobar.edu # # If you're going to protect the portmapper use the name "portmap" for the # daemon name. Remember that you can only use the keyword "ALL" and IP # addresses (NOT host or domain names) for the portmapper, as well as for # rpc.mountd (the NFS mount daemon). See portmap(8) and rpc.mountd(8) # for further information. # # Sybil portmap: 192.168.10.4 lockd: 192.168.10.4 rquotad: 192.168.10.4 mountd: 192.168.10.4 statd: 192.168.10.4 sshd: 192.168.10.4 nfsd: 192.168.10.4
My exports file on basil has:
Code:
# /etc/exports: the access control list for filesystems which may be exported # to NFS clients. See exports(5). # # Example for NFSv2 and NFSv3: # /srv/homes hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check) # # Example for NFSv4: # /srv/nfs4 gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check) # /srv/nfs4/homes gss/krb5i(rw,sync,no_subtree_check) # / 192.168.10.0/255.255.255.0(rw,sync,no_subtree_check) /home/aurora 192.168.10.0/255.255.255.0(rw,sync,no_subtree_check)
Code:
# /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc nodev,noexec,nosuid 0 0 # / was on /dev/sda1 during installation UUID=4129747b-fcd9-40e7-b916-359003a93eff / ext4 errors=remount-ro 0 1 # /home was on /dev/sda6 during installation UUID=9907d3c8-c432-436d-ad5a-dd8058fb4713 /home ext4 defaults 0 2 # swap was on /dev/sda5 during installation UUID=f8873d15-e093-4c05-bd73-db0c56efd552 none swap sw 0 0 # NFS Mounts sybil:/home/aurora /home/aurora/aurora/sybil_home nfs rw,user,noauto,hard,intr 0 0
As far as i can tell this is an outstanding kernel bug. Has anyone been able to get around this NFS problem or even get NFS to work? It is such a pain to no longer have NFS available

Comment