Bug 5863 - mkdir -p failed on a CIFS share
mkdir -p failed on a CIFS share
Status: RESOLVED WONTFIX
Product: CifsVFS
Classification: Unclassified
Component: kernel fs
2.6
x86 Linux
: P3 enhancement
: ---
Assigned To: Jeff Layton
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-31 11:24 UTC by nyal
Modified: 2009-11-30 05:49 UTC (History)
4 users (show)

See Also:


Attachments
Patch part 1 for 3.0.x (792 bytes, patch)
2008-11-06 00:44 UTC, Jeremy Allison
no flags Details
Patch part 2 for 3.0.x. (635 bytes, patch)
2008-11-06 00:44 UTC, Jeremy Allison
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description nyal 2008-10-31 11:24:15 UTC
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.
Comment 1 Jeremy Allison 2008-10-31 13:03:50 UTC
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.
Comment 2 nyal 2008-10-31 19:47:30 UTC
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)

Comment 3 nyal 2008-11-03 09:04:42 UTC
(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. 
Comment 4 nyal 2008-11-03 13:28:25 UTC
(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. 


Comment 5 Jeremy Allison 2008-11-03 19:40:09 UTC
Ok, I'll look at the 3.0.32 server code and see about back-porting the fix from 3.2.x.
Thanks,
Jeremy.
Comment 6 Jeremy Allison 2008-11-06 00:40:29 UTC
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.
Comment 7 Jeremy Allison 2008-11-06 00:44:17 UTC
Created attachment 3713 [details]
Patch part 1 for 3.0.x
Comment 8 Jeremy Allison 2008-11-06 00:44:48 UTC
Created attachment 3714 [details]
Patch part 2 for 3.0.x.
Comment 9 Jeremy Allison 2008-11-06 00:45:46 UTC
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.
Comment 10 nyal 2008-11-06 03:45:03 UTC
(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;
}

Comment 11 Jeremy Allison 2008-11-06 09:01:09 UTC
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.
Comment 12 nyal 2008-11-07 04:24:04 UTC
(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
Comment 13 Jeremy Allison 2008-11-07 08:26:31 UTC
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.
Comment 14 Douglas Thrift 2009-01-19 00:09:41 UTC
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?
Comment 15 urcentral 2009-04-03 19:31:15 UTC
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.
Comment 16 Karolin Seeger 2009-05-13 03:35:15 UTC
Jeremy, any news on this one?
Comment 17 Jeremy Allison 2009-05-13 12:58:18 UTC
This works perfectly with current v3-2-test and v3-3-test git code. Closing.
Jeremy.

Comment 18 urcentral 2009-05-30 02:03:21 UTC
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

Comment 19 urcentral 2009-05-30 04:29:54 UTC
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.
Comment 20 Jeremy Allison 2009-05-30 14:14:41 UTC
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.
Comment 21 Jeff Layton 2009-05-30 20:30:25 UTC
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.
Comment 22 urcentral 2009-05-31 09:11:26 UTC
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 :)
Comment 23 Jeff Layton 2009-05-31 13:08:20 UTC
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.

Comment 24 Karolin Seeger 2009-08-06 09:29:35 UTC
Can we close this one? Or mark as "enhancement"?
Comment 25 Jeremy Allison 2009-08-06 12:33:20 UTC
Mark as "enhancement" IMHO.
Jeremy.
Comment 26 Jeff Layton 2009-08-06 12:49:28 UTC
Agreed. I'll grab this one and plan to do a patch for CIFS when I get the time.
Comment 27 Jeff Layton 2009-08-26 07:30:51 UTC
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.
Comment 28 John Lepikhin 2009-11-30 04:55:04 UTC
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?
Comment 29 Jeff Layton 2009-11-30 05:49:29 UTC
Correct (unless you or someone else can suggest a way to securely do so)