I've discovered I think a peculiarity with handling mount paths with fsid=0.
This is on Ubuntu Precise (old) but I've used 3.13 too with the same
problem.
I have an exports line like this:
/storage/local
*(rw,sync,wdelay,nohide,crossmnt,insecure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,fsid=0,anonuid=65534,anongid=65534)
And mounted a directory like this (which succeeded)
# mount -t nfs4 10.157.208.1:nfs-01 /mnt
And unmount did this:
# umount 10.157.208.1:nfs-01
/mnt was not found in /proc/mounts
/mnt was not found in /proc/mounts
Examination showed /proc/mounts contained the line:
10.157.208.1:/nfs-01 /mnt nfs4
rw,relatime,vers=4.0,rsize=262144,wsize=262144,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=10.157.208.1,local_lock=none,addr=10.157.208.1
0 0
Whereas the outptut of 'mount' contained the line:
10.157.208.1:nfs-01 on /mnt type nfs4
(rw,addr=10.157.208.1,clientaddr=10.157.208.1)
There is a difference here between "/nfs-01" and "nfs-01".
This might merely be an annoying bug, where it not for the fact that as
far as I can tell the mount is now cannot be unmounted with userspace
tools. No amount of --fake and -n appears to help. System reset required.
Of course had I typed:
# mount -t nfs4 10.157.208.1:/nfs-01 /mnt
all would have been well.
I suspect something should be canonicalising the path consistently.
--
Alex Bligh
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
