Bug 190091 - After mount -t cifs, ls -l shows incorrect values
Summary: After mount -t cifs, ls -l shows incorrect values
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
(Show other bugs)
Version: 5
Hardware: All Linux
Target Milestone: ---
Assignee: Jeff Layton
QA Contact: Brian Brock
Whiteboard: NeedsRetesting
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2006-04-27 14:13 UTC by Peter Gordon
Modified: 2014-06-18 07:35 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-11-15 18:16:56 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Peter Gordon 2006-04-27 14:13:14 UTC
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 // /aaa -o
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:

Comment 1 Peter Gordon 2006-04-27 14:14:55 UTC
Text change: For me, this makes the cifs mount virtually unusable

Comment 2 Jay Fenlason 2006-04-28 17:33:40 UTC
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. 

Comment 3 Dave Jones 2006-10-16 20:35:09 UTC
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.

Comment 4 Jeff Layton 2007-09-24 10:49:07 UTC
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.

Comment 5 Jeff Layton 2007-09-24 11:03:31 UTC
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.


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...

Comment 6 Jeff Layton 2007-09-24 13:55:48 UTC
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).

Comment 7 Jeff Layton 2007-11-15 18:16:56 UTC
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);

Note You need to log in before you can comment on or make changes to this bug.