Hi, I have the following architecture: - 1 server with samba 3.2.4 - 1 client with samba 3.0.28a I have the same behaviour : http://lists.samba.org/archive/samba-technical/2007-February/051442.html > mkdir -p foo/bar FAIL, but creates 'foo' > mkdir foo foo/bar FAIL, but creates 'foo' > mkdir foo ; mkdir foo/bar FAIL, but creates 'foo' > mkdir foo ; sleep 1 ; mkdir foo/bar SUCCESS Because of this behaviour, clients can't connect to the workstation (i have : .gnome/accels permission denied in the .xsession-errors) I have tested on a windows CIFS share, i don't have this behaviour. It works well. Best regards, Nyal.
Can you test 3.0.32 please. I believe I have already fixed this in the 3.2.x git tree (marked as 3-2-test from samba.org) but I'll re-test. What version of the CIFS client are you using ? Jeremy.
Okay. I will test with the 3.0.32 version. I'm using ubuntu 8.04 for CIFS client. It seems to be the samba server. (because it works with a CIFS windows share)
(In reply to comment #1) > Can you test 3.0.32 please. I believe I have already fixed this in the 3.2.x > git tree (marked as 3-2-test from samba.org) but I'll re-test. What version of > the CIFS client are you using ? > Jeremy. > I have tested with samba server 3.0.32. I have the same problem.
(In reply to comment #3) > (In reply to comment #1) > > Can you test 3.0.32 please. I believe I have already fixed this in the 3.2.x > > git tree (marked as 3-2-test from samba.org) but I'll re-test. What version of > > the CIFS client are you using ? > > Jeremy. > > > > I have tested with samba server 3.0.32. I have the same problem. If i set "unix extensions = no", it works well.
Ok, I'll look at the 3.0.32 server code and see about back-porting the fix from 3.2.x. Thanks, Jeremy.
Ok, this currently works in the samba_3_0_test git tree (just tested it). I think this may be the same bug as #5790 (which was fixed post 3.0.32). Jeremy.
Created attachment 3713 [details] Patch part 1 for 3.0.x
Created attachment 3714 [details] Patch part 2 for 3.0.x.
Please try these 2 patches on your 3.0.32 tree. They should fix this problem. (We need a new 3.0.33 release soon). Jeremy.
(In reply to comment #9) > Please try these 2 patches on your 3.0.32 tree. They should fix this problem. > (We need a new 3.0.33 release soon). > Jeremy. > I can't use the patches. My files.c is different. Look the "file_find_di_first" function : files_struct *file_find_di_first(SMB_DEV_T dev, SMB_INO_T inode) { files_struct *fsp; if (fsp_fi_cache.dev == dev && fsp_fi_cache.inode == inode) { /* Positive or negative cache hit. */ return fsp_fi_cache.fsp; } fsp_fi_cache.dev = dev; fsp_fi_cache.inode = inode; for (fsp=Files;fsp;fsp=fsp->next) { if ( fsp->fh->fd != -1 && fsp->dev == dev && fsp->inode == inode ) { /* Setup positive cache. */ fsp_fi_cache.fsp = fsp; return fsp; } } /* Setup negative cache. */ fsp_fi_cache.fsp = NULL; return NULL; }
Ah, my mistake - sorry. You only need the patch part 2. Should work with just that change. Give it a try and let me know. Jeremy.
(In reply to comment #11) > Ah, my mistake - sorry. You only need the patch part 2. Should work with just > that change. Give it a try and let me know. > Jeremy. > I have applied the patch and it isn't working :(. (the same behaviour) I copy the log file (i have executed "mkdir -p .pp/ppppp"): [2008/11/06 14:44:40, 3] smbd/process.c:process_smb(1069) Transaction 26 of length 78 [2008/11/06 14:44:40, 3] smbd/process.c:switch_message(927) switch message SMBtrans2 (pid 1210) conn 0x804430c0 [2008/11/06 14:44:40, 3] smbd/trans2.c:call_trans2qfilepathinfo(3304) call_trans2qfilepathinfo: TRANSACT2_QPATHINFO: level = 512 [2008/11/06 14:44:40, 3] smbd/trans2.c:call_trans2qfilepathinfo(3355) call_trans2qfilepathinfo . (fnum = -1) level=512 call=5 total_data=0 [2008/11/06 14:44:40, 3] smbd/process.c:process_smb(1069) Transaction 27 of length 88 [2008/11/06 14:44:40, 3] smbd/process.c:switch_message(927) switch message SMBtrans2 (pid 1210) conn 0x804430c0 [2008/11/06 14:44:40, 3] smbd/trans2.c:call_trans2findfirst(1704) call_trans2findfirst: dirtype = 17, maxentries = 150, close_after_first=0, close_if_end = 2 requires_resume_key = 4 level = 0x202, max_data_bytes = 16384 [2008/11/06 14:44:40, 3] smbd/dir.c:dptr_create(515) creating new dirptr 256 for path ./, expect_close = 1 [2008/11/06 14:44:40, 3] smbd/process.c:process_smb(1069) Transaction 28 of length 78 [2008/11/06 14:44:40, 3] smbd/process.c:switch_message(927) switch message SMBtrans2 (pid 1210) conn 0x804430c0 [2008/11/06 14:44:40, 3] smbd/trans2.c:call_trans2qfilepathinfo(3304) call_trans2qfilepathinfo: TRANSACT2_QPATHINFO: level = 512 [2008/11/06 14:44:40, 3] smbd/trans2.c:call_trans2qfilepathinfo(3355) call_trans2qfilepathinfo . (fnum = -1) level=512 call=5 total_data=0 [2008/11/06 14:44:40, 3] smbd/process.c:process_smb(1069) Transaction 29 of length 86 [2008/11/06 14:44:40, 3] smbd/process.c:switch_message(927) switch message SMBtrans2 (pid 1210) conn 0x804430c0 [2008/11/06 14:44:40, 3] smbd/trans2.c:call_trans2qfilepathinfo(3304) call_trans2qfilepathinfo: TRANSACT2_QPATHINFO: level = 512 [2008/11/06 14:44:40, 3] smbd/trans2.c:call_trans2qfilepathinfo(3336) call_trans2qfilepathinfo: SMB_VFS_LSTAT of .pp failed (Aucun fichier ou r�pertoire de ce type) [2008/11/06 14:44:40, 3] smbd/error.c:unix_error_packet(56) unix_error_packet: error string = Aucun fichier ou r�pertoire de ce type [2008/11/06 14:44:40, 3] smbd/error.c:error_packet_set(106) error packet at smbd/trans2.c(3337) cmd=50 (SMBtrans2) NT_STATUS_OBJECT_NAME_NOT_FOUND [2008/11/06 14:44:40, 3] smbd/process.c:process_smb(1069) Transaction 30 of length 106 [2008/11/06 14:44:40, 3] smbd/process.c:switch_message(927) switch message SMBtrans2 (pid 1210) conn 0x804430c0 [2008/11/06 14:44:40, 3] smbd/trans2.c:call_trans2setfilepathinfo(5831) call_trans2setfilepathinfo(6) .pp (fnum -1) info_level=521 totdata=18
Damn, I've already fixed this in the 3.0.x tree, the test passes. I'll try and find exactly which patch it was that fixed it. Sorry for the problem finding the right patch. Jeremy.
I've observed this problem (mkdir making directories owned by root instead of the user) with Samba 3.0.33 and 3.2.7 as the Server with mount.cifs in Ubuntu 8.10 and Debian Lenny. Is there any progress on tracking down which patch fixes it?
I am running to the same (or similar) problems with my current test setup. On a CIFS mount, mounted as root, all directories created by me are owned by root, and files are owned by myself; $ ls -al total 4 drwxr-x--- 3 jf jf 0 Apr 4 01:54 . drwxr-xr-x 3 root root 0 Apr 4 00:59 .. drwxr-xr-x 2 root root 0 Apr 4 01:54 testdir -rw-rw-r-- 1 jf jf 0 Apr 4 01:54 testfile Above is the result of a 'mkdir testdir; touch testfile' as the 'jf' user. It does not seem to matter whether I use the 'setuids' option when mounting, or if 'MultiuserMount' is '0' or '1'. Currently using the default Samba packages (3.0.33-3.7.el5) that ship with CentOS 5.x, here's the output from the CIFS 'DebugData'; Display Internal CIFS Data Structures for Debugging --------------------------------------------------- CIFS Version 1.50cRH Active VFS Requests: 0 Servers: 1) Name: 127.0.0.1 Domain: WORKGROUP Mounts: 1 OS: Unix NOS: Samba 3.0.33-3.7.el5 Capability: 0x80f3fd SMB session status: 1 TCP status: 1 Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0 MIDs: Shares: 1) \\localhost\test Uses: 1 Type: NTFS DevInfo: 0x0 Attributes: 0x2f PathComponentMax: 255 Status: 1 type: 0 Is there a version in which this bug has been fixed? The previous comments lead me to believe that it should be fixed in the version I am using (3.0.33), but like the original poster the problem persists.
Jeremy, any news on this one?
This works perfectly with current v3-2-test and v3-3-test git code. Closing. Jeremy.
Problem still seems to exist in current stable (3.3.4) with the same setup as used in comment #15. Share mounted as root, created directories are owned by root, created files by myself. The 'mkdir -p' fails. Mounted with "mount -t cifs //localhost/smbtest /tmp/test -o setuids". -- /proc/fs/cifs/cifsFYI: 0 /proc/fs/cifs/DebugData: Display Internal CIFS Data Structures for Debugging --------------------------------------------------- CIFS Version 1.54RH Active VFS Requests: 0 Servers: 1) Name: 127.0.0.1 Domain: WORKGROUP Mounts: 1 OS: Unix NOS: Samba 3.3.4 Capability: 0x80f3fd SMB session status: 1 TCP status: 1 Local Users To Server: 1 SecMode: 0x3 Req On Wire: 0 MIDs: Shares: 1) \\localhost\smbtest Uses: 1 Type: NTFS DevInfo: 0x0 Attributes: 0x1002f PathComponentMax: 255 Status: 1 type: 0 /proc/fs/cifs/Experimental: 0 /proc/fs/cifs/LinuxExtensionsEnabled: 1 /proc/fs/cifs/LookupCacheEnabled: 1 /proc/fs/cifs/MultiuserMount: 1 /proc/fs/cifs/OplockEnabled: 1 /proc/fs/cifs/SecurityFlags: 0x7 /proc/fs/cifs/traceSMB: 0
From what I have been able to dig up from the debug logs and such, it seems that for files, a 'chown' type function is called; [2009/05/30 10:36:09, 3] smbd/trans2.c:call_trans2setfilepathinfo(6790) call_trans2setfilepathinfo(6) jfowned/testfile (fnum -1) info_level=512 totdata=100 [2009/05/30 10:36:09, 10] smbd/trans2.c:smb_set_file_unix_basic(6041) smb_set_file_unix_basic: SMB_SET_FILE_UNIX_BASIC: name = jfowned/testfile size = 0, uid = 501, gid = 501, raw perms = 0100664 [2009/05/30 10:36:09, 10] smbd/trans2.c:smb_set_file_unix_basic(6087) smb_set_file_unix_basic: SMB_SET_FILE_UNIX_BASIC setting mode 0664 for file jfowned/testfile [2009/05/30 10:36:09, 10] smbd/trans2.c:smb_set_file_unix_basic(6101) smb_set_file_unix_basic: SMB_SET_FILE_UNIX_BASIC changing owner 501 for path jfowned/testfile [2009/05/30 10:36:09, 10] smbd/trans2.c:smb_set_file_unix_basic(6124) smb_set_file_unix_basic: SMB_SET_FILE_UNIX_BASIC changing group 501 for file jfowned/testfile but for directories, this step is skipped; [2009/05/30 10:35:33, 3] smbd/trans2.c:call_trans2setfilepathinfo(6790) call_trans2setfilepathinfo(6) jfowned/testdir (fnum -1) info_level=521 totdata=18 [2009/05/30 10:35:33, 10] smbd/trans2.c:smb_posix_mkdir(6253) smb_posix_mkdir: file jfowned/testdir, mode 0755 If I create a directory directly on the filesystem, and then change the group of that directory on the Samba share, it does again call the same function it uses for the files; [2009/05/30 11:21:41, 3] smbd/trans2.c:call_trans2setfilepathinfo(6790) call_trans2setfilepathinfo(6) jfowned/anotherdir (fnum -1) info_level=512 totdata=100 [2009/05/30 11:21:41, 10] smbd/trans2.c:smb_set_file_unix_basic(6041) smb_set_file_unix_basic: SMB_SET_FILE_UNIX_BASIC: name = jfowned/anotherdir size = 0, uid = 4294967295, gid = 10, raw perms = 037777777777 [2009/05/30 11:21:41, 10] smbd/trans2.c:smb_set_file_unix_basic(6124) smb_set_file_unix_basic: SMB_SET_FILE_UNIX_BASIC changing group 4294967295 for file jfowned/anotherdir To a layperson like me it would seem that when a new directory is created, the 'smb_set_file_unix_basic' step is skipped for directories, leading to them being owned by the user who mounted the share. Been digging thru 'trans2.c', not been able to find where that decision is made. I am not C programmer though, so I might be reading it wrong.
This is a client bug. smbd will never chown a file or directory without a request from the client. I'm guessing this is missing from the mkdir path in the CIFSFS client code. Needs re-assigning to Jeff Layton. Jeremy.
Hmmm...tricky. This should only be an issue if you mount the share with root credentials. I'll need to look over the code in 1.54RH, but I think the deal is this: The problem here is that with the kernel you're running, mkdir is done via posix creates but normal files are not. So for normal files, we use standard SMB create calls and then unix setfileinfo calls to set ownership and mode. This kludge is actually very problematic if you want the server to override the mode on file/dir creation. POSIX creates are definitely preferred. Posix creates set the mode on creation so we have no need to follow up with a setfileinfo call. In more recent kernels, we use posix creates for files too. You'll get consistent behavior there -- everything will be owned by root. You'll also get more consistent behavior when mounting using unprivileged creds. There, the mode change works, but the ownership change doesn't. Mounting with root creds is a bit of a corner case... I'll need to ponder this a little more, but my guess is that we have the behaviour about as good as we can get without whipping multiuser mounts into better shape.
Ah, I'll look into other options such as NFS/AFS for now. Thanks for the feedback and cheers for all the work that goes into this :)
In order to get consistent behavior, what we should probably do is just get rid of these follow-on posix setfileinfo calls. At the very least we should probably stop trying to set the uid/gid on creation with them.
Can we close this one? Or mark as "enhancement"?
Mark as "enhancement" IMHO. Jeremy.
Agreed. I'll grab this one and plan to do a patch for CIFS when I get the time.
Actually...the follow-on change in ownership is only done if you mount with "setuids". Disabling that option should make this behave in the way that you expect. I'm hestitant to patch out that behavior since it might be useful for some people. If you've mounted with "-o setuids" then it's sort of expected that you know what you're doing. I'm going to go ahead and close this as WONTFIX. Please reopen if you want to make a case for changing it. If you do then you'll probably want to subscribe to the linux-cifs-client mailing list so that we can discuss this there.
I have chrooted environment inside CIFS mount (with setuids option enabled). Users are very annoyed when they try to work with newly created directories, as they are created with root owner. As far as I understand the discussion, there is no way to fix this. Am I right?
Correct (unless you or someone else can suggest a way to securely do so)