Hello, this could be related to #2606 and #2521 but am not sure if this is a duplicate. Anyways I was asked to file this as a bug. Here is what happens: Create a file with permission bits set to 470, owned by root. With setfacl give write permission to a group. Users in that group will not be able to modify the file when accessing the share from a windows client. This is true for smbclient as well. Modifying the file under Linux works as expected. $ ls -l testi2.txt -r--rwx---+ 1 root QLEAP+domänen-benutzer 14 Apr 15 16:40 testi2.txt (Note the file belongs to root but has no write permission) $ getfacl testi2.txt # file: testi2.txt # owner: root # group: QLEAP+dom\303\244nen-benutzer user::r-- user:QLEAP+testi2:rwx group::r-- group:QLEAP+testgruppe20:rwx mask::rwx other::--- $ id uid=10032(QLEAP+testi2) gid=10029(QLEAP+domänen-benutzer) ...,10067(QLEAP+testgruppe20),... $ vi testi2.txt (can edit the file) $ smbcacls -U testi2 //hatest1/admin testgruppe20/testi2.txt creating lame upcase table creating lame lowcase table Password: REVISION:1 OWNER:HATEST1+root GROUP:QLEAP+Domänen-Benutzer ACL:HATEST1+root:ALLOWED/0/R ACL:QLEAP+testgruppe20:ALLOWED/0/FULL ACL:QLEAP+Domänen-Benutzer:ALLOWED/0/R ACL:QLEAP+testi2:ALLOWED/0/FULL ACL:+Jeder:ALLOWED/0/ $ smbclient -U testi2 //hatest1/admin creating lame upcase table creating lame lowcase table Password: Domain=[QLEAP] OS=[Unix] Server=[Samba 3.0.13-Debian] smb: \> cd testgruppe20 smb: \testgruppe20\> lcd /etc smb: \testgruppe20\> put passwd putting file passwd as \testgruppe20\passwd (1122.9 kb/s) (average 1123.0 kb/s) smb: \testgruppe20\> put passwd testi2.txt NT_STATUS_ACCESS_DENIED opening remote file \testgruppe20\testi2.txt smb: \testgruppe20\> q $ Please see also: http://lists.samba.org/archive/samba/2005-April/103296.html http://lists.samba.org/archive/samba/2005-April/103172.html thanks for your attention, Peter
Please send me the debug level 10 log from smbd when doing the smbclient operation listed below. Thanks, Jeremy.
(In reply to comment #1) > Please send me the debug level 10 log from smbd when doing the smbclient > operation listed below. Did you receive the log? I had a look at them myself and saw this: [2005/04/19 10:25:32, 8] smbd/dosmode.c:dos_mode_from_sbuf(151) dos_mode_from_sbuf returning r [2005/04/19 10:25:32, 8] smbd/dosmode.c:dos_mode(315) dos_mode returning r which looks like not related to acl at all. And I think this is what happens: - when a user changes the dos attribute to readonly it is translated by samba to remove the write permissions of the unix-user part (u-w) - the next time the user wants to access the file she receives a permission denied because because samba translates the u-w permission back to readonly - in this special case she even cannot remove the readonly flag again because she's not the owner of the flag (that can be overwritten with "dos filemode = yes") - notice that ACLs are not involved at all. Ok, the question is: bug or feature? Would the solution be to use extended attributes and do this? store dos attributes = yes map hidden = no map system = no map archive = no I have not yet tested with extended attributes, but I would expect it will work, please correct me. The root of the problem lies in the fact that samba translates dos attributes to unix permissions (and fate takes its run...) The question remains: are you or have you been aware of this?
IMO by default it should work like in Windows. I.e., if doc or xls file has a read only attribute on Windows, Word or Excel can still modify such file. After I copy file to samba share, it gets u-w permission, and Word or Excel can no longer modify file, until I remove r/o DOS attribute.
This all needs to be reevaluated in light of 3.0.20. If there is still a bug here, please reopen.