Bug#717547: nfs-common: simple remount returns an error
Ben Hutchings:
> Well, I don't understand how this is going wrong. All the logic in
> fs/nfs/super.c (nfs_show_mount_options(), nfs_remount(),
> nfs_parse_security_flavors(), nfs_compare_remount_data()) appears to do
> the right thing with the sec option (stored in various structures as
> auth_flavors[0] or au_flavor).
>
> Perhaps you could add some debug logging to work out how the option is
> getting mangled on remount?
Unfortunately, I don't remember the detail of wheezy 3.2 kernel because
I am reading various versions of mainline kernel. I am going to slightly
mad and confused.
I only remember that
- At the first mount-time, NFS sets RPC_AUTH_UNIX (as default) without
NFS_MOUNT_SECFLAVOUR.
- nfs_show_mount_options() prints "sec=sys" since RPC_AUTH_UNIX is set,
but still NFS_MOUNT_SECFLAVOUR is not set.
- "mount -o remount" retrives "sec=sys" from /proc/mounts and passes it
to mount(2).
- nfs_remount() --> nfs_parse_mount_options() --> nfs_compare_remount_data()
compares the flags and found that
- "sec=sys" string is given.
- but NFS_MOUNT_SECFLAVOUR flag is not set internally.
and returns EINVAL.
I guess one possible solution is stop printing "sec=" in
nfs_show_mount_options() when NFS_MOUNT_SECFLAVOUR is not set.
Another solution can be to force setting NFS_MOUNT_SECFLAVOUR when
setting RPC_AUTH_UNIX as default. But in this case, we may need to care
about /etc/mtab.
In other words,
- it may be hard to keep /etc/mtab and /proc/mounts equivalent.
- some developers think
+ /etc/mtab and /proc/mounts are totally different things
+ it is unnecessary to make them equivalent.
- finally symlinking /etc/mtab can cause a problem (like this case)
since mount(8) and umount(8) highly depends upon /etc/mtab (or
/proc/mounts).
By the way, after forcing /etc/mtab as a regular file on my wheezy
system, I found another problem of mount(8). I will report it to
bugtrack later.
J. R. Okajima
Reply to: