Return to Answer

Samba tends to force its own idea of permissions and ownerships on files so that it more closely mimics the (hierarchical) NTFS style of permissions.

If you extend your Samba definition to include the force user and force group directives you can ensure that all files created on the share (through Samba) will have the specified owner and group.

[MEDIA] read only = no locking = yes path = /mnt/local/int001/MEDIA guest ok = yes create mask = 0664 directory mask = 0775 force user = Bob force group = SharedFiles 

You can't implement the same thing directly with local users, though, because it's not possible for a user to create a file owned by someone else. This is where inotifywait can help. Set it up at boot to monitor the directory hierarchy and change the ownership of any newly created file:

cd /mnt/local/int001/MEDIA || exit inotifywait --monitor --recursive --event create --format '%w%f' . | while IFS= read -r file do if [[ -f "$file" || -d "$file" ]] && [[ ! -h "$file" ]] then chown Bob:SharedFiles "$file" chmod u+rw,go=u,o-w "$file" fi done 

With this inotifywait solution you don't need the filesystem ACLs.

Samba tends to force its own idea of permissions and ownerships on files so that it more closely mimics the (hierarchical) NTFS style of permissions.

If you extend your Samba definition to include the force user and force group directives you can ensure that all files created on the share (through Samba) will have the specified owner and group.

[MEDIA] read only = no locking = yes path = /mnt/local/int001/MEDIA guest ok = yes create mask = 0664 directory mask = 0775 force user = Bob force group = SharedFiles 

You can't implement the same thing directly with local users, though, because it's not possible for a user to create a file owned by someone else. This is where inotifywait can help. Set it up at boot to monitor the directory hierarchy and change the ownership of any newly created file:

cd /mnt/local/int001/MEDIA || exit inotifywait --monitor --recursive --event create --format '%w%f' . | while IFS= read -r file do if [[ -f "$file" || -d "$file" ]] && [[ ! -h "$file" ]] then chown Bob:SharedFiles "$file" chmod u+rw,go=u,o-w "$file" fi done 

With this inotifywait solution you don't need the filesystem ACLs.

Personally, I'm not convinced you really need to change file ownership. The ACLs you specified (and the corresponding force group in Samba) will ensure that all users of the directory tree can access the files and directories within in. There is good reason for ordinary users being denied chown.

Samba tends to force its own idea of permissions and ownerships on files so that it more closely mimics the (hierarchical) NTFS style of permissions.

If you extend your Samba definition to include the force user and force group directives you can ensure that all files created on the share (through Samba) will have the specified owner and group.

[MEDIA] read only = no locking = yes path = /mnt/local/int001/MEDIA guest ok = yes create mask = 0664 directory mask = 0775 force user = Bob force group = SharedFiles 

You can't implement the same thing directly with local users, though, because it's not possible for a user to create a file owned by someone else. This is where inotifywait can help. Set it up to monitor the directory hierarchy and change the ownership of any newly created file. (When I get to a PC I'll copy n paste a working solution.)

Samba tends to force its own idea of permissions and ownerships on files so that it more closely mimics the (hierarchical) NTFS style of permissions.

If you extend your Samba definition to include the force user and force group directives you can ensure that all files created on the share (through Samba) will have the specified owner and group.

[MEDIA] read only = no locking = yes path = /mnt/local/int001/MEDIA guest ok = yes create mask = 0664 directory mask = 0775 force user = Bob force group = SharedFiles 

You can't implement the same thing directly with local users, though, because it's not possible for a user to create a file owned by someone else. This is where inotifywait can help. Set it up at boot to monitor the directory hierarchy and change the ownership of any newly created file:

cd /mnt/local/int001/MEDIA || exit inotifywait --monitor --recursive --event create --format '%w%f' . | while IFS= read -r file do if [[ -f "$file" || -d "$file" ]] && [[ ! -h "$file" ]] then chown Bob:SharedFiles "$file" chmod u+rw,go=u,o-w "$file" fi done 

With this inotifywait solution you don't need the filesystem ACLs.

Samba tends to force its own idea of permissions and ownerships on files so that it more closely mimics the (hierarchical) NTFS style of permissions.

If you extend your Samba definition to include the force group directive you can ensure that all files created on the share (through Samba) will have the specified group ownership.

[MEDIA] read only = no locking = yes path = /mnt/local/int001/MEDIA guest ok = yes create mask = 0664 directory mask = 0775 force group = SharedFiles 

Your guest ok seems strange. This suggests you don't want to worry about authentication for the share, so there's no (technical) way to ensure only Bob or Sue can create files there. On the other hand, if only Bob and Sue exist then it's probably irrelevant...

Samba tends to force its own idea of permissions and ownerships on files so that it more closely mimics the (hierarchical) NTFS style of permissions.

If you extend your Samba definition to include the force user and force group directives you can ensure that all files created on the share (through Samba) will have the specified owner and group.

[MEDIA] read only = no locking = yes path = /mnt/local/int001/MEDIA guest ok = yes create mask = 0664 directory mask = 0775 force user = Bob force group = SharedFiles 

You can't implement the same thing directly with local users, though, because it's not possible for a user to create a file owned by someone else. This is where inotifywait can help. Set it up to monitor the directory hierarchy and change the ownership of any newly created file. (When I get to a PC I'll copy n paste a working solution.)