That will be a hairy one, you've been warned..:-)
This bug was reported in the Debian BTS, originally with Debian lenny (samba 3.2.5, kernel 2.6.26) but is reproduced by our user in Debian unstable (samba 3.3.2, kernel 2.6.26).
*I* (Christian Perrier) have not been able to reproduce it so I was not that keen to report it here....but I've now reached the point where my investigation skills stop.
Initial user report:
On the server there are:
debian stable with kernel 184.108.40.206 and samba 3.2.5-4
On several clients:
debian stable/testing (tested by various kernels), winXP (sp1/2), ubuntu 8.x
mount.cifs //192.168.1.130/upload /home/user0/upload -o "username=user0,password=user0"
ls -la /home/user0/upload
drwxr-xr-x 2 user0 user0 0 2009-04-03 12:29 tmpdir0
-rwxr--r-- 1 user0 user0 2 2009-04-03 12:32 tmpfile0
-rw-r--r-- 1 user0 user0 1 2009-04-03 12:35 tmpfile1
everything is ok :-)
cp -rv /home/user0/10filesdir /home/user0/upload/
cp: cannot create regular file [...] access denied. [...] for all files
Thus: ONLY if I copy a dir with several files inside it born a copy error!
Because seems that the permission (server side) are correctly, but I don't understand the problem :-/
Using konqueror (smb://192.168.1.130/upload) this problem there isn't: everything is ok. Same with winXP and osx
I tried several options on the server and clients: add/remove unix permissions = yes, on mount: add nodfs, etc.
I then asked for a few more details:
>If 10filesdir created on the target?
on the server there is an empyt dir: 10filesdir
ls -la [...] 10filesdir
drwxr-xr-x user0 user0 10filesdir
>What happens when you "mkdir" 10files dir on the target, *then* try to
>"cp" the individual files in it?
So doing everyting is ok.
After this initial report, I asked the user to reproduce this on a box running more recent versions of samba, which he did. So in the next report, the user-space tools version is 3.3.2 (I still need to clear out what is the kernel version. Let's assume this is 2.6.26):
User says he did:
On linux client I created a dir with 3 files inside it, then I copied those in
Searching for: sambatest (name of dir), test0,test1,test2, the 3files inside
Doing this, he had the same permission error. And he grabbed a level 10 log of the failure on the client side, which I'll attach to this bug.
Trying to do *the very same test* I couldn't reproduce his error unfortunately (user-space tools were 3.3.2 and kernel was 2.6.26 and 2.6.28 for me).
I will attach *his* smb.conf file and the one I used to test.
Created attachment 4080 [details]
Level 10 log, server-side, of a failed copy
Here's a level 10 log, taken from our user during a failed copy of a directory named "sambatest" contaiining files named test0, test1 and test2
Created attachment 4081 [details]
smb.cofn file used by our user
is there a work-in-progress about this bug?
Same problem on Debian Squeeze with fresh samba configuration.
Maybe exists some workaround for avoid this bug?
(In reply to comment #1)
> mkdir /home/user0/upload/tmpdir0
> touch /home/user0/upload/tmpdir0/tmpfile0
> touch /home/user0/upload/tmpfile1
> ls -la /home/user0/upload
> drwxr-xr-x 2 user0 user0 0 2009-04-03 12:29 tmpdir0
> -rwxr--r-- 1 user0 user0 2 2009-04-03 12:32 tmpfile0
> -rw-r--r-- 1 user0 user0 1 2009-04-03 12:35 tmpfile1
> everything is ok :-)
I'm fighting the same bug on my lenny debian.
I'm not sure but I think that the test you made in three different
commands would fail with the one line shell command
mkdir /home/user0/upload/tmpdir0; touch /home/user0/upload/tmpdir0/tmpfile0; touch /home/user0/upload/tmpfile1
since in this second case the thee commands are executed without pauses
If I have the mounted dir named 'upload' then
mkdir upload/pippo; mkdir upload/pippo/pluto
mkdir: cannot create directory `upload/pippo/pluto': Permission denied
mkdir upload/pippo; sleep 1; mkdir upload/pippo/pluto
does not fail.
Seems like the client create directory but setting the
permissions on server takes a little more time.
> I'm fighting the same bug on my lenny debian.
problem solved with version 2:3.2.5-4lenny12
Ok, closing this bug based on last comment. Sounds like it might have been
a server bug. Please reopen if we need to revisit it.