[Samba] SFU Samba Permission Denied
spragins at gmail.com
Tue Sep 21 22:09:50 GMT 2004
I recently ran into a problem accessing Samba shares from SFU. From
SFU's /net directory, I could read from files, move files, create
directories and even append to files using >>. But, when I tried to
create a file, I received a "Permission Denied" message.
After looking at the logs I found something which looked out of place.
I am currently using (I tried many different variations):
WindowsXP SP1; SFU version 3.5
RedHat version 7.2; Samba version 3.0.7
Below is from the client log after turning the debug level to 10:
[2004/09/21 15:06:46, 10] smbd/posix_acls.c:set_nt_acl(2990)
set_nt_acl: called for file test1.txt
[2004/09/21 15:06:46, 5] smbd/posix_acls.c:unpack_nt_owners(909)
unpack_nt_owners: validating owner_sids.
[2004/09/21 15:06:46, 10] passdb/lookup_sid.c:sid_to_uid(401)
sid_to_uid: winbind lookup for non-local sid
[2004/09/21 15:06:46, 3] smbd/posix_acls.c:unpack_nt_owners(927)
unpack_nt_owners: unable to validate owner sid for
unpack_nt_owners returns False which causes set_nt_acl to return False
which leads to the Permission Denied error message.
Only SFU clients cause Samba to call set_nt_acl on this share. The
share, btw, is on an ext3 file system with no ACL support.
Why is set_nt_acl being called? Bug?
I tried compiling with no ACL support. I also tried several different
share options that looked like they would prevent ACL support. But,
SFU still causes Samba to try and set ACL's using set_nt_acl.
If anyone has any ideas on how to bypass ACL checking/setting using
compile or configuration options, please let me know. For now, I
patched posix_acls.c to bypassed set_nt_acl and the SFU clients are
More information about the samba