# Samba4 (4.1.2) permissions issues on WinXP network

Samba 4.1.2 on CentOS 6.4 serving WinXP clients from /home/srv/shared. /home, /home/srv, /home/srv/shared, and /home/srv/shared/pics all have unix 777 perms. WinXP client copies a file into S:\pics (S: being /home/srv/shared and having our domain group mydom\Users with Full Control in win ACLs, as does S:\pics) and the file has 770 perms and mydom\Users with Full Control. Problem is, our apache user, which serves up from pics via httpd, cannot access the file, thanks to the 770 unix perms.

smb.conf has:

read only = No
force create mode = 0777
force directory mode = 0777
profile acls = yes
inherit acls = yes
inherit owner = yes
mangle prefix = 6


...and just the straight path under the S: share.

The error Apache gives is:

Forbidden

You don't have permission to access /shared/pics/Test Pic.jpg on this server.


I thought that maybe it was a configuration error, but even with Allow from all in httpd.conf I get this. Until I chmod 777 the file and then no problem. chmod 770 and the problem returns.

The manpage for samba 4.1.2 has this to say about my conf choices:

inherit acls (S)

This parameter can be used to ensure that if default acls exist on parent directories, they are always honored when creating a new file or subdirectory in these parent directories. The default behavior is to use the unix mode specified when creating the directory. Enabling this option sets the unix mode to 0777, thus guaranteeing that default directory acls are propagated. Note that using the VFS modules acl_xattr or acl_tdb which store native Windows as meta-data will automatically turn this option on for any share for which they are loaded, as they require this option to emulate Windows ACLs correctly.

inherit owner (S)

The ownership of new files and directories is normally governed by effective uid of the connected user. This option allows the Samba administrator to specify that the ownership for new files and directories should be controlled by the ownership of the parent directory. Common scenarios where this behavior is useful is in implementing drop-boxes where users can create and edit files but not delete them and to ensure that newly create files in a user's roaming profile directory are actually owner by the user.

After reviewing profile acls I decided to try commenting that line out because I couldn't fully understand the description and saw the note "that this parameter should be set to yes on dedicated profile shares only. On other shares, it might cause incorrect file ownerships," but I can't test that until after hours.

I do not have any win-to-unix id map happening. Is that necessary for ACLs to work as you'd expect them to with a Windows 2003 fileserver? If not, what exactly do I need to do so that new files inherit ACLs correctly without destroying unix perms?

-