Description of problem:
file_mode and dir_mode options of CIFS filesystem driver don't completely work
as expected for newly-created files or directories on shares that have
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Add "unix extensions = no" to the global section in /etc/samba/smb.conf
2. Mount the share like this: "mount -t cifs //host/share /mnt/tmp -o
file_mode=0666,dir_mode=0777,username=xxx" and enter the correct password.
3. Ensure that all files on the mount are mode 666 and all dirs are 777, as
expected. Ensure your umask is 0022.
4. Go into a directory with real (not faked by cifs.ko) write permissions and
execute: "mkdir test; ls -lda test; sleep 1; ls -lda test"
[2|root@zap|/mnt/tmp/incoming]mkdir test; ls -lda test; sleep 1; ls -lda test
drwxr-xr-x 2 root root 0 Янв 1 16:04 test/
drwxrwxrwx 1 root root 0 Янв 1 16:04 test/
drwxrwxrwx 2 root root 0 Янв 1 16:04 test/
drwxrwxrwx 1 root root 0 Янв 1 16:04 test/
It seems like the 'chmod' operation is not ignored as expected, but somehow gets
cached for some indefinite time (it may last for a very long time). Another test
that gives results similar to above:
[2|root@zap|/mnt/tmp/incoming]chmod 700 test; ls -lad test; sleep 1; ls -lad test
drwx------ 1 root root 0 Янв 1 16:04 test/
drwxrwxrwx 1 root root 0 Янв 1 16:04 test/
This wouldn't be so bad if *both* owner and access mode would be cached, the
problem is that only the access mode is cached, so if you are a regular user you
won't be able to write to the directory you just created! This is quite annoying
if you copy large amounts of files recursively; however this does not always
exhibit, I can't understand when, but on some operations this 'cache' is
guaranteedly flushed, so with some applications recursive copy works fine, with
others (e.g. midnight commander) it doesn't.
Does this happen when using the CIFS filesystem to mount non-Samba servers?
Ifso, it's a kernel bug, and should be reassigned to the kernel component.
Otherwise I'll need a complete /etc/samba/smb.conf or a wireshark capture of
the entire interaction between the client and server.
I've tried it today on a Windows share and the bug is still present.
I would reassign it to the kernel component but I couldn't find it in the huge
list, sorry :-)
Kernel CIFS bug, reassigning.
Test kernels for this issue are at:
Please test and report back.
I have tried the kernel-2.6.20-1.2937.fc6.x86_64.rpm package. The bug is still
Linux zap.ozerki.lan 2.6.20-1.2937.fc6 #1 SMP Sun Mar 25 20:34:49 EDT 2007
x86_64 x86_64 x86_64 GNU/Linux
[2|zap@zap|/mnt/cs-zap]mkdir test; ls -lad test; echo "" >test/file; sleep 1; ls
-lad test; echo "" >test/file; ls -la test
drwxr-xr-x 2 root root 0 Mar 27 2007 test/
bash: test/file: Permission denied
drwxrwxrwx 1 root root 0 Mar 27 2007 test/
drwxrwxrwx 1 root root 0 Mar 27 2007 ./
drwxrwxrwx 54 root root 0 Mar 27 2007 ../
-rw-r--r-- 1 root root 1 Mar 27 2007 file
As you can see in the later listing, the mode on the file is 0644, although
file_mode was 0666 while mounting the share. And it doesn't drop to 0666
whatever I do with it, but if you wait some time it will earlier or later reset
to the correct value.
I think this is an artifact of the way that inodes are created in this
situation. When inodes are created they get whatever mode the VFS passed to the
call. Eventually though, they get revalidated and then they pick up whatever
file/dir_mode the share is mounted with. I find this confusing too -- perhaps we
can make an argument to get this changed upstream...
I think this may have been fixed. Can reporter try a 2.6.22 FC6 kernel?
Actually, I don't think this is fixed. I see similar behavior on rawhide, even...
I think I understand what the problem is. When I get some time, I'll see if I
can roll up a patch to fix it.
This is similar to RHEL5 bug #287401
I currently use kernel-184.108.40.206-41.fc7 and I'm still fighting every day with
this bug. Quite annoying.
Created attachment 202051 [details]
proposed patch -- don't override the mode when unix extensions aren't enabled
This patch seems to correct the behavior, and I think it's the right thing to
do here. It just stops the cifs code from overriding the mode when unix
extensions are not enabled.
Not only is this behavior an inconvenience, I think it's potentially a security
issue. For instance, presume that someone has more restrictive permissions on a
cifs share than the typical create mode:
...and then the user goes to create a file:
...the user would probably expect that the file would end up with a mode of
0600. There is a window there where it will be 0644, potentially exposing the
Now, you might make the case someone using a mode of 0644 shouldn't expect that
the file doesn't get exposed. That would probably be valid except for the fact
that when unix extensions aren't enabled, the code also does not respect the
Andrew, could you test this patch and let me know if it seems to fix the issue
The patch works perfectly, thank you! Tried it on kernel-220.127.116.11-34.fc7.
It's sad the patch didn't get into fedora 8 :(
we're still debating this patch upstream. The problem is that while the current
behavior is a bit goofy, it allows certain test suites to run correctly.
Removing it might cause regressions in some cases.
After discussing it with Steve French, he recommended that we wait until the
unix mode to windows ACL mapping patches are in place. A lot of that is upstream
now, so I need to dust off the above patch and see what needs to be done at this
point and what changing this would actually break.
Reposted patch upstream on email@example.com. Awaiting comments...
Adding Steve in case he wants to see the original bug report on this...
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.
If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we are following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Bug is still present with latest kernel (kernel-18.104.22.168-64.fc8).
Yep. There's still some reservations about this patch upstream by the
maintainer, though I still think that it's the right thing to do. I also have
some other somewhat related patches that I'd like to see go in as well. I'll
plan to roll them up in a set and propose them when I get some time.
Feel free to chime in on firstname.lastname@example.org if you wish.
I'm working on a new patchset for this that includes changes to make
cifs_setattr silently ignore ownership and mode changes that don't affect
I've also got a related reproducer that shows that in-memory mode changes like
this can be lost as soon as the box is subject to memory pressure.
I need to do a bit more testing and cleanup on the patches. I'll try to post
them here and upstream in the next few days.
New patchset sent upstream. Awaiting comments...
After working with Steve upstream, I think we have a resolution for this. I sent
him a respun patchset today and hopefully it'll be committed soon...
This patchset does a good job of making sure that we don't allow ephemeral mode
changes, but if someone turns out to need them, then there is a new "dynperm"
mount option that allows it. It also extends the "setuids" mount option to allow
chown to change the ownership of the file if and only if that's enabled when
unix extensions aren't on.
AFAIK, the patchset is acceptible and is just waiting for him to get time to
review and merge it.
Patchset has been merged into Steve F's cifs-2.6 git tree. Barring major
problems, it should go into 2.6.27. I'll leave this case open until the patchset
has had more soak time.
in 2.6.26 as:
Unfortunately, that patch isn't complete. Steve pushed the patch that adds the
new mount option, but the patches to change the default behavior and to make the
mount option actually do anything are still queued for 2.6.27.
I'm going to reopen this since it's not actually in rawhide yet...
Actually...looks like steve pushed the rest of the patches for this into 2.6.26
late. So this should now be fixed in 2.6.26 kernels.