1

Let's say I am the user Alice and I have a publicly accessible folder /samba/public

The permissions of the public Samba folder (/samba/public/) are nobody:nogroup and 0777.

When Alice tries to copy over something from her home folder to the shared public drive

(e.g cp ~/Downloads/* /samba/public),

Alice wants the newly copied files to be editable/deletable by all guests who have access to the public Samba share.

I want the copied files to be owned by nobody:nogroup and set to 0777.

Instead, what happens is that the newly copied files are owned by alice:alice and guest users on the public drive can't edit or delete the files.

How can I ensure that future copy/move operations of content from Alice's home folder to the shared/public Samba folder will be owned by nobody:nogroup so that guest users aren't then prevented from deleting/editing the files themselves?

2
  • @sourcejedi One idea that I've thought of so far is to run a cron job every 5 minutes that "resets" permissions recursively on the contents of the public directory so that any newly pasted Alice-owned files become nobody-owned files. However, this feels like a very inelegant way of addressing an underlying problem.
    – chivano
    Jul 5, 2018 at 21:30
  • I have the same frustration - the question I linked is my own :). Some day I might write a script which uses inotify to detect newly created files, and changes the permissions immediately, I think it would work quite nicely for my case.
    – sourcejedi
    Jul 5, 2018 at 21:41

2 Answers 2

Reset to default
0

I appear to have got this fixed now (touch wood).

I've tried various different fixes so it's hard to identify what precisely made everything work but these are the steps which I think helped:

  1. I have a Docker application running which downloads content to my home directory (this seemed irrelevant at the time).
  1. After following the advice of @sourcejedi, my umask was changed to 0002.
  2. Following the advice given by @Isaac, I was able to create/copy/move files as well as directories from my home directory to /samba/public/ and Samba guest users were able to rename/edit/delete freely.

  1. However, when I tried to copy/move anything in my home dir that was downloaded using this Docker application, Samba guest users were not able to rename/edit/delete freely (because the Docker app was creating directories with a chmod val of 755).

  2. I then changed the umask of the Docker application to 0002. Subsequent downloads and directories generated by the Docker app were of chmod val 775. When these directories are copied over to /samba/public/, Samba guest users can now rename/edit/delete.

Footnotes:

  • Changing umask to a value of your choice is as simple as performing umask XXXX where XXXX is the value you want. You can check your umask value by simply typing umask into the terminal.

  • Changing the umask of the Docker application that I was using was done by adding a new ENV parameter called umask and setting that to 0002. When starting a Docker container, you can pass in this parameter via CLI or if you use Portianer to manage your running containers, you can pass in this ENV parameter with the web-UI.

  • Major caveat: As part of getting this working, I first tried following the advice given in the Setting up permissions for common folder thread as well trying to use a User Private Groups (UPG) pattern that @sourcejedi recommended before following @Isaac's advice.

    If anyone in the future encounters similar issues, this might be relevant?

1
  • I would try to make clear that umask XXXX is temporary. I.e. if you need to run it, you need to run it each time you log in. E.g. the manual for the old RHEL 5 (redhat) says they already set the default umask by including umask 002 in /etc/bashrc, which will be run when you ssh in, assuming you don't change the users shell to something different from bash.
    – sourcejedi
    Jul 7, 2018 at 8:36
0

Welcome to U&L! You probably don't need files to become nobody:nogroup 0777. I am very sorry but the pattern you would want was broken by Gnome/systemd (and udisks). At least, if Alice uses these on the same computer that runs the Samba server.

This is discussed (not very clearly) in the questions Shared, read-write, photo directory tree, for normal users and Share folder/files between multiple users on ext4 disk

If Alice isn't using Gnome (including the Gnome file manager), nor udisks (to allow users to mount removable filesystems ) on the same computer that runs the Samba server, then you might actually be able to use the original User Private Groups pattern.

IIRC, Redhat systems already set the correct umask for UPG. For Debian-based systems, you might need to enable and configure pam_umask. See https://stackoverflow.com/questions/10220531/how-to-set-system-wide-umask

EDIT: if you have to change the umask, you will also have to change the access mode of any existing files, that you might want to share in future. E.g. chmod -R g+w $HOME/* or chmod -R g+w /home/*/*. Do not use chmod -R g+w $HOME. It will change the mode of $HOME/.ssh, and likely stop you logging in using ssh.

Otherwise, maybe someone can suggest a workaround based on this information.

I can suggest one alternative, based on the thread Setting up permissions for common folder

It sounds like you want the guest users to be able to delete and edit these files... this suggests they might not be very big files.

From the information you give, it seems Alice could act as a guest herself, using the Samba share to upload the files. ...you just have to avoid telling Alice where the Samba directory is on the server. And if she's smart enough to find it, she's smart enough to be told that computers were a mistake and her perfectly logical idea will not work because Reasons.

(If you absolutely needed to, you could "hide" the Samba server by running it inside a container such as LXC.)

In case Alice has an account on the Samba server which is not a guest, it might also be necessary to use chmod g+s on the directory, and in smb.conf set

create mask = 0775
directory mask = 0775
7
  • I'm going to attempt the "setting up perms for common folder" workaround and I'll report back! In my case, this is a Ubuntu Sever OS installed on a NUC and "Alice" is an SSH user so Gnome doesn't apply here.
    – chivano
    Jul 5, 2018 at 22:01
  • 1
    @chivano if Alice connects via SSH the create mask and directory mask won't do anything if she logs in and creates a file/directory - they only affect things done via Samba.
    – ivanivan
    Jul 5, 2018 at 22:14
  • Unfortunately, no luck with the "Setting up permissions for common folder" solution. Even though "Alice" and nobody both belong to the newly created group and even though the group owns the public folder, when Alice copies something over, nobody is still unable to edit/delete.
    – chivano
    Jul 5, 2018 at 22:15
  • @sourcejedi I'm reading through the UPG blog post but I'm not sure I get it...is it as simple as performing chmod g+s? Alice (the user) already belongs to a group called Alice but nobody only belongs to a group called nogroup (and a group called samba_public_access which I created for test purposes). Is there anything preventing me from assigning nobody to a group called nobody when they already exist in a group called nogroup?
    – chivano
    Jul 5, 2018 at 22:28
  • Maybe I should add that when Alice transfers files over to the public folder, this is happening via SSH and NOT via Samba. Meanwhile, the guest who's trying to delete a file/folder that Alice pasted into the public folder is attempting to do so via Windows Explorer. I could be wrong but I suppose this means we can rule out an incorrect smb.conf config because Alice isn't copying files via Samba. She's literally just copying a file from one location to another on the same drive.
    – chivano
    Jul 5, 2018 at 22:33

You must log in to answer this question.

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