OMV General POSIX File System Permission Balance: chmod – chown – setgid - umask concepts

    • Offizieller Beitrag

    OMV General POSIX File System Permission Balance: chmod – chown – setgid - umask concepts


    This guide is intended to explain how OMV deals with file POSIX permissions work and how to set up correctly third party services (daemons, downloaders) to keep your files accessible.


    CHMOD- CHOWN - SETGID:


    First to explain is that every default share created in OMV is created under the following parameters

    • Ownership=root:users (chown)
    • File Permission Mode=775 (chmod)
    • Setgid=2 (chmod)

    Ownership
    First parameter means that every folder created as share, is owned by root as individual user and as group by users. The group “users” is where every user created in the webUI belongs as his PRIMARY GROUP. This should not be changed and cannot be changed from the webUI


    File Permission Mode
    The second parameter 775 explained in words is:
    Owner (root) can read(4)/write(2)/execute(1) 4+2+1=7
    Users that belong to the Group (users) can read(4)/write(2)/execute(1) 4+2+1=7
    Others can only read(4)/execute(1) 4+1=5


    Others are in general referred as anybody who is not root and doesn’t belong to users. Example: the guest account in Samba (nobody)


    So in simple words EVERY USER from the webUI can read/write into that folder….I repeat AGAIN every user created with the webUI in OMV, this applies to the file system itself not a service or daemon (samba for example)


    Execution bit on folders: The execution bit is very important in folders, without it you won't be able to cd into folders. You can have read permissions and list the contents (only contents not details like permissions or dates).


    Setgid
    The third parameter is the set group id, this is one of the most important ones. This will force every underneath file and folder to be created with group ownership of the top folder (In case of OMV is "users").
    Example: OMV user Steve logs into samba into a shared folder with his account from windows, he uploads a file, this file will have steve:users ownership, notice how the file is user owned by steve, but group owned by users. This will allow any other user at least to see those files (write to that file will depend on the umask which I'll explain later)


    Let’s check some real examples
    A simple stat folder command for a default share created in OMV webUI gives us:


    01.png


    We can see all the normal parameters we explained before as default. Green is setgid, red is file permission mode, and blue is owners.


    This is what happens when you create a folder in CLI ssh as root, in the / of the mounted volume.


    02.png


    Notice the difference? Then you ask yourself: why your share isn't accessible or not writable in samba? Or why transmission daemon can’t download to that folder?


    UMASK:

    As defined by Wikipedia: “The umask command is used to control the file mode creation mask, which determines the initial file permissions for newly created files and folders. It is defined in the POSIX.1 specification and available on Unix-like operating system”
    The umask controls whether a file gets created as 700 or 755 or 775, etc, etc mode


    In OMV we run several plugins as daemons. All of this services (especially downloaders) run under a specific daemon username, you can check that yourself with ps aux | grep servicename


    So all files created by these services are user owned by that specific daemon username, but as they are under an OMV share they are forced to be group owned by users (remember the setgid bit we mentioned before?)


    All services and daemons have configurable UMASK settings. If you find that your files downloaded by transmission cannot be modified in samba or ftp is because YOU as a user of those services have not set up a proper umask settings in the daemon that created those folders and files
    Also to clarify that some programs specifically name file creation/permission mode others use umask

    • If a service offers what permission mode you want, you can select 775 (sabnzbd for example)
    • If a service offers the umask for file creation then you must select 002, which would get translated in 775 creation mode. Which service uses umask: transmission and deluge.


    Samba for example has default creation mode of 755, so all your files will not be writable by other than you. Other users might read it.
    The OMV samba share setting has a checkbox to override that default umask, is called enable permission inheritance, this will allow other users to write or delete the files you've created.


    The following is the umask translate table.



    UmaskCreated FilesCreated Directories
    000666 (rw-rw-rw-)777 (rwxrwxrwx)
    002664 (rw-rw-r--)775 (rwxrwxr-x)
    022644 (rw-r--r--)755 (rwxr-xr-x)
    027640 (rw-r-----)750 (rwxr-x---)
    077600 (rw-------)700 (rwx------)
    277400 (r--------)500 (r-x------)


    Bringing folders back to default in OMV (folders created in CLI or coming from other system), is super easy now as you can use the reset utility included with omv-extras. This will apply all the necessary chmod/chown to shares and probably solve all your read/Write problems across different services. It can also flush all ACL in that folder recursively.


    Deleting files


    The ability to delete files in linux is controlled by the permissions on the folder that the files are contained. You can have read only permission on a file, but if the folder has write permissions for you, your group or others then you can delete any files inside. The file can even be in 000 mode and you can still delete it.


    Different daemons umask or chmod settings

    • Transmission: Umask settings in OMV webUI
    • Deluge-Daemon: Umask setting in his init script
    • Sabnzbd: file permission mode in his own web interface
    • Couchpotato & Sickbeard: Technically these aren't downloaders, file processed by these daemons get passed to downloaders. Ownership is by the downloaders. But they do perform rename, move and copy so they need write access.
    • Sonarr (ex-nzbdrone): File permission mode in his own webUI. This is related to the creation of new series and season folders (including setgid). Actual files are created by the downloaders. EDIT: Sonarr also moves, copies or hardlinks files. So the result of this are files owned and created by sonarr.
    • Pyload: File permission mode in his own webUI, including setgid
    • Jdownloader: to be added
    • Headphones: File permission mode in his own webUI. Similar to sickbeard is not a downloader, but it has file permission mode in his interface which is intended for renaming and transcoding files.

    All this previous mentioned daemons run under their own daemon username. Their primary group as defined by their plugin developer is users so by default they all have write access to shares created with OMV in the volume drives. The exception to this is the transmission daemon that has users as secondary group, with this the daemon still has write access.


    BTSync does not belong to group users, thus default shares in OMV need to be modified to 777 mode for btsync to work properly or add the daemon user btsync to group users


    EDIT: The latest Transmission plugin does no longer add debian-transmission to the users group. You need to add the username manually for transmission to be able to write to shares


    Questions? doubts?
    OMV General POSIX File System Permission Balance: chmod – chown – setgid - umask concepts


    This guide is intended to be a complement of this
    Privileges and permissions explained under OMV

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!