I've created a new Samba instance and it works, but when I copy new files onto the Samba share they get created with the owner:group as root:myuser. All the files that I create on Linux itself have myuser:myuser. Why does Samba set root as the owner? I'm aware of the force user and force group options but I'd rather not use them as it seems they apply globally to all configured Samba shares; if I had 2 shares set up with 2 different users, I would want the files to be created with those respective users as the owner and group, and root shouldn't be owner or group for anything.

The relevant smb.conf is:

# Make Samba follow symlinks
follow symlinks = yes
wide links = yes
unix extensions = no

# Custom shares
create mask = 0664
directory mask = 0755
valid users = myuser
admin users = myuser
  • "I'm aware of the force user and force group options [...] it seems they apply globally;" - the documentation declares the options as force user (S), which shows that they can apply at the share level Commented Apr 28 at 19:48

1 Answer 1


The answer to the question in the title is: because you've told it to do just that.

From man smb.conf (emphasis mine):

admin users (S)

This is a list of users who will be granted administrative privileges on the share. This means that they will do all file operations as the super-user (root).

You should use this option very carefully, as any user in this list will be able to do anything they like on the share, irrespective of file permissions.

If you have set the directory permissions correctly, and don't make a habit of fiddling with things in shared directories as root, then you don't need the admin users line in Samba configuration at all.

If you are setting up a directory for shared access, whether for Samba or just within Linux, the easiest way to do it is to set up a group for it, then set the top-level shared directory with owner root, group as the group that's set up for this share, and permissions drwxrws--- or maybe drwxrwsr-x if necessary (chmod 2770 or chmod 2775 respectively).

Note that the setgid bit (chmod g+s) is now set for the directory: that means the group ownership will be inherited by any new file or sub-directory created into this directory, and the setgid bit itself will be automatically inherited by any new directory. Then share the directory with Samba if necessary.

It is important that you create only the top level as root - let the users do the rest.

If you need to maintain the contents of the shared directory yourself, add your regular user account to the group that grants write access to that directory, and then "do the needful" as your regular user account. If not - keep your root-powered hands away from that directory unless you absolutely have to do something. You'll find that will be very rare exceptions.

On a modern Linux system that follows the common "usergroups" principle (i.e. all users have a personal group with UID=GID assigned for them only, and the umask does not restrict group write access) you don't have to do anything else: everything Just Works, and everyone who needs to be able to modify things will be able to do it, with the powers granted by the group ownership.

Unless the directory has the sticky bit (chmod +t) set, anyone with write permissions to a directory can delete anything and everything within it, including root-owned sub-directories.

  • Hmm, so there's no way to configure it so that a user can delete a root-owned file, but when saving a file it'll be saved as user:user instead of root:user?
    – Jez
    Commented Apr 28 at 19:48
  • Sure is. If the directory is writeable to the user, and has no sticky bit set, then the user will be able to delete any files in that directory just fine, no matter who owns them. Basic POSIX file permission rules.
    – telcoM
    Commented Apr 28 at 19:50
  • Should I just remove the admin users line from the config then?
    – Jez
    Commented Apr 28 at 19:51
  • Yes. In Unix systems, if you are the owner of some basic resource (file, directory, process, etc), then you have basically the same power to that resource that root has. If you assign the directory permissions (group write + maybe setgid to the directory) correctly, you don't need the admin users line at all.
    – telcoM
    Commented Apr 28 at 19:54
  • Still, the user won't be able to delete a root-owned directory.
    – Jez
    Commented Apr 28 at 19:56

You must log in to answer this question.

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