Red Hat Bugzilla – Bug 190091
After mount -t cifs, ls -l shows incorrect values
Last modified: 2014-06-18 03:35:20 EDT
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
For me, this makes the cifs mount virtually
Version-Release number of selected component (if applicable):
mount.cifs version: 1.10
Steps to Reproduce:
1. mount -t cifs //10.1.1.1/share /aaa -o
2. cd /aaa
3. ls -l
-rwxrwSrwt 1 root root 231 Dec 27 06:15 share.sfv
-rwxrwxrwx 1 root root 231 Dec 27 06:15 share.sfv
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
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.
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.
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.
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);