0

Looking at other questions, I've done the following:

chmod g+s MEDIA 
setfacl -R -d -m g::rwx MEDIA 
setfacl -R -d -m o::rwx MEDIA 

NOTE: MEDIA is a folder I'm looking to set up so that all files/folders added have the same user/group as the parent folder.

In this example MEDIA is owned by the user Bob and group SharedFiles. The goal is for newly created files/folders to retain this ownership (both Bob and SharedFiles:

MEDIA Bob SharedFiles
MEDIA/NewFolder Bob Bob   <BAD
MEDIA/NewFolder Bob SharedFiles   <GOOD

If I create a subfolder whilst logged in as user 'Bob' that folder is owned by Bob:SharedFiles with [rwxrwxrwx] permissions (as intended). All Good!

If I login as Sue, the new folder becomes part of Sue:Sue with [rwxr-xr-x].

If I login from a different machine via a mounted drive in KDE (user Sue) the folder becomes part of Bob:Bob with [rwxr-xr-x].

Now both Bob and Sue are part of SharedFiles, where am I going wrong. I want all users in SharedFiles group to have RWX permissions and I want all files/folders created by users in SharedFiles group to have the same user/group as the parent folder, why does this only happen with the owner on the machine itself.

getfacl MEDIA/

returns

# file: MEDIA/
# owner: Bob
# group: SharedFiles
# flags: -s-
user::rwx
group::rwx
other::rwx
default:user::rwx
default:group::rwx
default:other::rwx

samba.conf contains:

[MEDIA]
 read only = no
 locking = yes
 path = /mnt/local/int001/MEDIA
 guest ok = yes
 create mask = 0775
 directory mask = 0775
10
  • Your statement "If I login from a different machine via a mounted drive in KDE (UserB) [...]" doesn't make sense. Do you mean you mount the MEDIA folder from a remote machine? If so, which network filesystem protocol are you using to do so? Commented Jul 11, 2017 at 22:22
  • Yes, mounting the MEDIA folder remotely, using CIFS, providing Bob and his password when requested by the file browser Commented Jul 11, 2017 at 22:43
  • So... you need to look at your Samba configuration for that share. Commented Jul 11, 2017 at 23:20
  • On Linux, a newly created file's owner is set to the uid of the creating process, and the file's owner cannot be changed by a non-superuser user, even if the user is the owner of the file. This means you can't give away your files. If there was a mechanism (say by setting the user suid bit on a directory), then this rule could be circumvented by two co-operating regular users. Thus you can't set up a directory so that a file created by a local user would end up being inherited from the directory. Commented Jul 12, 2017 at 6:25
  • @roaima create and directory mask are both set to 0775 in samba.conf Commented Jul 12, 2017 at 21:37

1 Answer 1

2

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .