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 S-1-5-21-1951701912-1418144344-1147873810-2551 failed [2004/09/21 15:06:46, 3] smbd/posix_acls.c:unpack_nt_owners(927) unpack_nt_owners: unable to validate owner sid for S-1-5-21-1951701912-1418144344-1147873810-2551 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 working. Ed Spragins -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
