Description of problem: I have been working with Fedora 3 and used smbmount to mount a cifs partition. Results as expected. I moved to Fedora 5. smbmount is no longer available, so I used mount -t cifs ls -l produces incorrect results. I tried doing chmod 777 file, which worked. When I unmounted and remounted the file system, I received the original incorrect results(S and t bits set) I tried setting various options with mount -t cifs, but nothing seemed to make any difference. For me, this makes the cifs mount virtually Version-Release number of selected component (if applicable): mount.cifs version: 1.10 How reproducible: Steps to Reproduce: 1. mount -t cifs //10.1.1.1/share /aaa -o username=name,workgroup=group,password=secret 2. cd /aaa 3. ls -l Actual results: -rwxrwSrwt 1 root root 231 Dec 27 06:15 share.sfv Expected results: -rwxrwxrwx 1 root root 231 Dec 27 06:15 share.sfv Additional info:
Text change: For me, this makes the cifs mount virtually unusable
Once mount.cifs has made the mount system call, it's job is done. Everything after that point is handled by the kernel. I'm reassigning this bug to the correct owner.
A new kernel update has been released (Version: 2.6.18-1.2200.fc5) based upon a new upstream kernel release. Please retest against this new kernel, as a large number of patches go into each upstream release, possibly including changes that may address this problem. This bug has been placed in NEEDINFO state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. In the last few updates, some users upgrading from FC4->FC5 have reported that installing a kernel update has left their systems unbootable. If you have been affected by this problem please check you only have one version of device-mapper & lvm2 installed. See bug 207474 for further details. If this bug is a problem preventing you from installing the release this version is filed against, please see bug 169613. If this bug has been fixed, but you are now experiencing a different problem, please file a separate bug for the new problem. Thank you.
Current CIFS upstream still uses this default file_mode. When file_mode isn't specified for the mount, the kernel code does this: /* 2767 perms indicate mandatory locking support */ vol->file_mode = S_IALLUGO & ~(S_ISUID | S_IXGRP); It's not clear to me what this comment means.
Ahh...from Documentation/mandatory.txt: 2. Marking a file for mandatory locking --------------------------------------- A file is marked as a candidate for mandatory locking by setting the group-id bit in its file mode but removing the group-execute bit. This is an otherwise meaningless combination, and was chosen by the System V implementors so as not to break existing user programs. --------[snip]-------- So this mode is used to indicate that the file is eligible for mandatory locking. You can, of course, force your own mode here by setting "file_mode=0777" and in the mount options to get the expected result above. CIFS isn't quite right though, since the above mode is 03767 not 02767. I'll see about pushing out a patch that fixes that...
Pushed a small patch upstream to clear the sticky bit in the default file_mode. Leaving this open until it's in Steve F's tree (or until there is some comment).
This is now fixed upstream. Mounts get 02767 as their mode by default after the change to this: vol->file_mode = (S_IRWXUGO | S_ISGID) & (~S_IXGRP);