I just tried it on recent Samba (from about a week ago) with the same results Version 4.2.0pre1-GIT-47e7440 and also Version 4.1.6-Ubuntu If "store dos attributes = yes" (on by default in Ubuntu) is in smb.conf then the following fails mount -t cifs //someserver/someshare /mnt touch /mnt/newfile1 chmod 0000 /mnt/newfile1 stat /mnt/newfile1 (mode displays as expected) rm /mnt/newfile1 (fails with access denied) if the identical scenario is tried with "store dos attributes = no" in smb.conf then it works mount -t cifs //someserver/someshare /mnt touch /mnt/newfile2 chmod 0000 /mnt/newfile2 stat /mnt/newfile2 (mode displays as expected) rm /mnt/newfile2 (delete works), and also removing the newfile1 created above also works) rm /mnt/newfile1 (also works) Details: posix unlink (set path info) fails with access denied/status cannot delete, as does subsequent smb delete. Attempts to clear the readonly bit also fails with access denied The chmod 0000 causes Samba server to set the read-only dos attribute in the failing case On Thu, Aug 21, 2014 at 4:13 PM, Jeremy Allison <jra@xxxxxxxxx> wrote: > On Tue, Aug 19, 2014 at 09:33:12PM -0500, Steve French wrote: >> Noticed that even with Unix Extensions on cifs mount that Samba >> refuses to delete a file in this scenario (locally and presumably over >> nfs it still works since it is in cthon suite). This causes >> connectathon special tests to fail >> >> touch newfile >> chmod 0000 newfile >> rm newfile >> >> (works locally but samba rejects) >> >> Samba 4.1 rejects posix unlink (set path info) STATUS_CANNOT_DELETE >> then client falls back to SMB unlink which fails. STATUS_CANNOT_DELETE >> then client falls back to a set path info of file info basic which >> also fails STATUS_ACCESS_DENIED >> >> Will do quick test with Samba master when build completes - but does >> this server unlink bug look familiar (or am I missing an smb.conf that >> I have forgotten about)? > > Can't reproduce this on current v4-1-test > git branch. > > Can you give me details please ? > > Jeremy. -- Thanks, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
