As of v3.0.25 (I think - certainly 3.0.25c) and later, a user requires full *nix 'rwx' permissions on a directory in order to write to it. This seems rather excessive - why should read access be required for a write operation? This change has broken certain behaviour we depended on to provide write-only dropboxes for our faculty members by setting '-wx' permissions on those subdirectories, which worked fine up through v3.0.24.
Can you tell me exactly what you're doing to reproduce this please ? What client, what application etc. The problem is obvious to you, but not from the bug report - there is no real problem description here. Jeremy.
I have experienced the same problem. I have a folder with Unix permissions of -wx for a certain user, shared through samba. If I am using samba v3.0.24 (or earlier), that user is able to drag files into the folder from Windows Explorer. (Of course, the read bit being off keeps them from opening the folder itself.) However, under v3.0.26 and later, that same action gives an "Access is Denied" error, even though the folder permissions have not changed. It seems that Samba is requiring the read permission on the folder even if the user just wants to write. The same problem occurs using the Windows command prompt as well. Given a user 'joe' with -wx permissons on a samba folder 'dropbox', under 3.0.24, joe can run 'copy file.txt \\server\dropbox' and the file is placed into the folder, even if joe cannot open the folder itself. However, under 3.0.26 and later, joe gets an "Access is Denied" error running the same command with the same permissions on the folder.
I can confirm the bad behavior on 3.0.28a -- though this is the first I've used Samba, so I don't have experience with what used to work. to replicate: (not verbatim) mkdir /tmp/dropbox # set sticky bit, so only owner can delete # drwx-wx-wt # users can: # * write new files # * not list dir contents # * not edit or delete (other than own files) chmod 1733 /tmp/dropbox # create a demo file touch /tmp/dropbox/my_file # log in as nobody sudo su - nobody # another demo file touch /tmp/dropbox/something # no problem rm /tmp/dropbox/something # access denied rm /tmp/dropbox/my_file # access denied ls /tmp/dropbox ######## EOF ######### ###### smb.conf ###### [dropbox] path = /tmp/dropbox writeable = yes browseable = yes guest ok = yes ######### EOF ######## Now, a Windows XP client will get "Access Denied" when trying any operation on the share. Judging from my expectations and other comments, any user ought to be able to copy a file onto the share successfully.
I'm also seeing this behavior after having upgraded to a server running 3.0.28-1.el5_2.1 (on RHEL 5.2). Our previous server ran an ancient version (2.2.7a) and it behaved as expected. In other words, it is a bug rather than a misconfiguration. WinXP users are unable to write to a directory unless the directory is also readable to them via the unix read permission. Without the read permission they receive this error message in windows: "Cannot Copy file_name: Access is denied. Make sure the disk is not full or write-protected and that the file is not currently in use."