As reported by our user in Debian: When remounting a CIFS mount to change the byte-range locking option, the system reports success; but the system's behavior continues to reflect the originally-mounted choice. While researching http://bugs.debian.org/483216, i discovered that byte-range locks against files CIFS shares mounted with mount.cifs are normally interpreted as "mandatory" locks, instead of "advisory" locks. This is adjustable with the nobrl/brl mount options. mount claims to be able to successfully modify those options using -o remount, but in practice, the changed options don't seem to have any effect at all, and the option selected at initial mount time is the persistent behavior. In particular, locking a certain range of a file with a read lock and then locking the same range with a write lock gives an error when a CIFS share is mounted with "brl". This doesn't make much sense to me, but i'm willing to accept it as intended for now. I wrote a simple program (source attached) to test this locking behavior. I also observed that "brl" is translated into the "mand" option in the relevant line in /proc/mounts, and that "nobrl" maps to the *absence* of the "mand" option in the /proc/mounts entry. You can adjust the options reported in /proc/mounts using the standard "mount -o remount,newoptions" syntax, but the mountpoint's behavior does not change. Here's a transcript demonstrating the problem. "bob" is running the most recent version of samba available in debian etch. Note that the behavior of the "testlocking" program is not changed by the -o remount commands, even though /proc/mounts reflects the change: [0 root@squeak ~]# grep /mnt /proc/mounts [1 root@squeak ~]# mount -t cifs -o guest,uid=dkg,sec=none //bob/dmz /mnt [0 root@squeak ~]# grep /mnt /proc/mounts //bob/dmz /mnt cifs rw,mand,unc=\\bob\dmz,username=,uid=1000,posixpaths,rsize=16384,wsize=57344 0 0 [0 root@squeak ~]# touch /mnt/foo [0 root@squeak ~]# ~dkg/src/cmrg/test/testlocking/testlocking /mnt/foo write lock failed [1 root@squeak ~]# mount -o remount,nobrl,guest,uid=dkg,sec=none /mnt [0 root@squeak ~]# grep /mnt /proc/mounts //bob/dmz /mnt cifs rw,unc=\\bob\dmz,username=,uid=1000,posixpaths,rsize=16384,wsize=57344 0 0 [0 root@squeak ~]# ~dkg/src/cmrg/test/testlocking/testlocking /mnt/foo write lock failed [1 root@squeak ~]# umount /mnt [0 root@squeak ~]# grep /mnt /proc/mounts [1 root@squeak ~]# mount -t cifs -o nobrl,guest,uid=dkg,sec=none //bob/dmz /mnt [0 root@squeak ~]# grep /mnt /proc/mounts //bob/dmz /mnt cifs rw,unc=\\bob\dmz,username=,uid=1000,posixpaths,rsize=16384,wsize=57344 0 0 [0 root@squeak ~]# ~dkg/src/cmrg/test/testlocking/testlocking /mnt/foo [0 root@squeak ~]# mount -o remount,brl,guest,uid=dkg,sec=none /mnt [0 root@squeak ~]# grep /mnt /proc/mounts //bob/dmz /mnt cifs rw,mand,unc=\\bob\dmz,username=,uid=1000,posixpaths,rsize=16384,wsize=57344 0 0 [0 root@squeak ~]# ~dkg/src/cmrg/test/testlocking/testlocking /mnt/foo [0 root@squeak ~]#
Created attachment 3829 [details] Test case provided by our user This is the test program provided by our user
Yes, -o remmount does not seem to change the original mount options to the ones during remount, looking into this. It also adds an additional entry in /etc/mtab that does not get removed during unmount and has to be removed from /etc/mtab manually.
Looking at the mount.cifs documentation (man mount.cifs), I do not see a remount option (i.e. -o remount). cifs vfs client does not support a remount option.
We should support changing most of the cifs_fs_sb.h flags (at least those that might not conflict with values on the tcon). For updating tcon bit flags we need to first check if the share (tcon) is mounted twice (two superblocks pointing to one tcon - which presumably would preclude changing a flag common to both). Similarly we could change things on the smb session but few things seem like good candidates to allow user to change there so for time being we probably can fix cifs_remount to only allow chaning flags (most but not all) of those in cifs_fs_sb.h and fail or ignore other changes.
The handling of mand should now be cleaner and make more sense. Enabling "mand" by default was a mistake since that tells the kernel to enforce mandatory locks instead of leaving it up to the server. This should be fixed now in current mount.cifs and kernel releases.