Jump to content

Getting folder permissions right once and for all


geotux

Recommended Posts

Hi People,

 

I've just got into Emby and the more I use it the more I love it. I'm trying to get the folder permissions right once and for all as at the moment iàm having to run a chmod 770 on the media directory every time I add media which is not handy. I would just like all the contents to inherit the file permissions of the main directory. Now i know this may be more of a LInux OS question but I post it here as I want to make sure Emby server is happy with this level of settings.

 

At the moment I have a Movies folder that belongs to "emby" group and "antonio" (a normal unix user that is the admin user of the emby server) is member of that group. I set the sticky bit on te "Movies" folder with:

chmod g+s Movies

so that I have:

 

drwxrwsr--+ 21 antonio emby   4096 nov 10 11:50 Movies

 

You'll see that I have access control set on this folder which I did with the following two commands:

setfacl -d -m g::rwx /<directory>  //set group to rwx default setfacl -d -m o::r /<directory>   //set other

After doing this, I created a folder in the MOvies directory via terminal

 

mkdir Baaria (2009)

 

So that:

 

drwx--S---+ 2 antonio emby    4096 nov 10 11:51 Baaria (2009)

and the file inside this folder:

 

-rw------- 1 antonio antonio 2098558137 apr 15  2015 Baaria (2009).m4v

 

 

When I run the getfacl command on the Movies folder, I get:

 

# file: Movies/
# owner: antonio
# group: emby
# flags: -s-
user::rwx
group::rwx
other::r--
default:user::rwx
default:group::rwx
default:other::r--
 

 

EMBY doesn't seem to be happy with the newly created folder permissions (see below) not quite sure why though. I'm sure this is to do with my ignorance on the unix file system management and the use of the setfacl command or maybe I'm just overcomplicating things.

 

Any suggestions?

 

Thanks

Antonio

2015-11-10 11:51:21.0640 Error - App: Error resolving path /exports/zeusmedia/Movies/Baaria (2009)	*** Error Report ***	Version: 3.0.5781.0	Command line: /usr/lib/emby-server/MediaBrowser.Server.Mono.exe -programdata /var/lib/emby-server -ffmpeg /usr/bin/ffmpeg -ffprobe /usr/bin/ffprobe -restartpath /usr/lib/emby-server/restart.sh	Operating system: Unix 3.2.0.4	Processor count: 2	64-Bit OS: False	64-Bit Process: False	Program data path: /var/lib/emby-server	Mono: 4.0.3 (Stable 4.0.3.20/d6946b4 Wed Aug 19 11:56:04 UTC 2015)	Application Path: /usr/lib/emby-server/MediaBrowser.Server.Mono.exe	Access to the path "/exports/zeusmedia/Movies/Baaria (2009)" is denied.	System.UnauthorizedAccessException	  at System.IO.Directory+<EnumerateKind>c__Iterator0.MoveNext () [0x00000] in <filename unknown>:0 	  at System.IO.DirectoryInfo+<CreateEnumerateDirectoriesIterator>c__Iterator0.MoveNext () [0x00000] in <filename unknown>:0 	  at System.Linq.Enumerable+<CreateSelectIterator>c__Iterator10`2[System.IO.DirectoryInfo,CommonIO.FileSystemMetadata].MoveNext () [0x00000] in <filename unknown>:0 	  at System.Linq.Enumerable+<CreateConcatIterator>c__Iterator1`1[CommonIO.FileSystemMetadata].MoveNext () [0x00000] in <filename unknown>:0 	  at MediaBrowser.Controller.Providers.DirectoryService.GetFileSystemDictionary (System.String path, Boolean clearCache) [0x00000] in <filename unknown>:0 	  at MediaBrowser.Controller.Providers.DirectoryService.GetFileSystemDictionary (System.String path) [0x00000] in <filename unknown>:0 	  at MediaBrowser.Controller.IO.FileData.GetFilteredFileSystemEntries (IDirectoryService directoryService, System.String path, IFileSystem fileSystem, ILogger logger, MediaBrowser.Controller.Library.ItemResolveArgs args, Int32 flattenFolderDepth, Boolean resolveShortcuts) [0x00000] in <filename unknown>:0 	  at MediaBrowser.Server.Implementations.Library.LibraryManager.ResolvePath (CommonIO.FileSystemMetadata fileInfo, IDirectoryService directoryService, MediaBrowser.Controller.Entities.Folder parent, System.String collectionType) [0x00000] in <filename unknown>:0 	  at MediaBrowser.Server.Implementations.Library.LibraryManager+<ResolveFileList>c__AnonStorey1B.<>m__0 (CommonIO.FileSystemMetadata f) [0x00000] in <filename unknown>:0 



			
				


	Edited  by geotux
	
	

			
		
Link to comment
Share on other sites

thefirstofthe300

First off, there should be no need to set the sticky bit on the folders.  I personally have never, ever used that and I have been using all kinds of distros for three years or so.  Second, you actually still do not quite have the permissions set correctly.  For any user or group to be able to actually open a folder, the folder needs to have the execute permission set for that user or group.  IF you look at your permissions, the Baaria folder only has read, write and execute set for your user (700).  You need to have that folder set to 750 at least for it to work.  All of my files are set to be 755 and it works quite well.  Doing a "chmod 770 -R /exports/zeusmedia/Movies" and "chown -R antonio:emby /exports/zeusmedia/Movies" should fix your problems.

 

Second, when you move a file to a new location, it preserves the permissions of that file when you move it.  In other words, a file with the owner:group antonio:antonio with the octal format 700 will have those same permissions in the new folder regardless of whether the parent directory is set to the permissions antonio:emby octal format 777.  Emby will have access to the directory and be able to see the file and write to that folder but it won't be able to read the file to play it.  My point being, remember to change the permissions on any files you add to your media directories.

  • Like 1
Link to comment
Share on other sites

Hi,

 

thanks for the reply. You may be right on the permission for files being imported from other folders into the Movies folder, so long as the permissions, owner and group are the same. BUt I have just tried now to create a folder in the Movies folder and it does not inherit the settings of it's parent folder Movies (antonio.emby 770). THe new folder in the Movies folder has antonio.antonio 700. This is why I had set the sticky bit on the Movies folder. But you are probably right, there is no need for the sticky bit if a set of proper rules can be identified with access control lists which most linux distros/filesystems have now.

 

Happy to hear what others are doing. I'm still not convincend about the fact that every time I copy media in the Movies/Music folders i have to run a chmod/chgrp. That sound laborious ...

 

Antonio

Link to comment
Share on other sites

thefirstofthe300

Hi,

 

thanks for the reply. You may be right on the permission for files being imported from other folders into the Movies folder, so long as the permissions, owner and group are the same. BUt I have just tried now to create a folder in the Movies folder and it does not inherit the settings of it's parent folder Movies (antonio.emby 770). THe new folder in the Movies folder has antonio.antonio 700. This is why I had set the sticky bit on the Movies folder. But you are probably right, there is no need for the sticky bit if a set of proper rules can be identified with access control lists which most linux distros/filesystems have now.

 

Happy to hear what others are doing. I'm still not convincend about the fact that every time I copy media in the Movies/Music folders i have to run a chmod/chgrp. That sound laborious ...

 

Antonio

 

This is just the way that *nix systems are.  I imagine that the reasoning behind this is to prevent users from accidentally exposing something that they don't want others to have access too (e.g. password files).  From my understanding Windows has certain folders that everyone has read and write access too and they can edit files that other users put in those directories.  If a user plops a password file in there, suddenly everyone can see it and write to it.  *nix systems do there best to avoid this issue by not having these directories and maintaining permissions as the files are copied to new directories.  Here is a SE post that deals with this topic.

 

If you want to automatically change the permissions on all files in a folder automatically and are willing to deal with the potential security ramifications listed above, you can use cron to call a script that changes all the permissions automatically.  I have used this solution in the past and it worked quite well.

Link to comment
Share on other sites

Hi,

 

thanks for the reply. You may be right on the permission for files being imported from other folders into the Movies folder, so long as the permissions, owner and group are the same. BUt I have just tried now to create a folder in the Movies folder and it does not inherit the settings of it's parent folder Movies (antonio.emby 770). THe new folder in the Movies folder has antonio.antonio 700. This is why I had set the sticky bit on the Movies folder. But you are probably right, there is no need for the sticky bit if a set of proper rules can be identified with access control lists which most linux distros/filesystems have now.

 

Happy to hear what others are doing. I'm still not convincend about the fact that every time I copy media in the Movies/Music folders i have to run a chmod/chgrp. That sound laborious ...

 

Antonio

 

Regarding file permissions, did you try to make the ACLs recursive?

 

On the other hand, is there any reason why you want to control access to media assets through file permissions instead of creating different libraries for different users?

As an example I'm using separate Movie and TV library for my son.

So my sons user has access to "Movies - Kids" and "TV - Kids" libraries only while my wife and I have access to those libraries plus "Movies" and "TV" with content that is only accessible for us.

Also Emby allows you not only to control access on each Library but also to use ratings. So your kids can only watch content rated below some threshold.

 

Did you try that?

Link to comment
Share on other sites

  • 1 year later...

Actually, I control access for my kids setting the age limitation on the single movies. Probably more work involved but I find its a neater solution. If I set age 15 to a movie, my 10 year old son can't see it. Remember you can set maximum parental rating to a user.

Link to comment
Share on other sites

dcrdev

This isn't working for you because you're assuming that read permissions are enough to browse that folder as other, in unix systems directories require the executable bit to list their contents. From reading your post, your folders need 775 and files 664, there's an easy way to do this using the capital "X" parameter of chmod; this will ensure that only directories are executable.

 

So:

chmod -R u+rwX /Movies
chmod -R g+rwX /Movies
chmod -R o+r-X /Movies

Contrary to above chmod -R g+s is not setting the sticky bit, but setting the gid, this ensures that all new files/folders inherit the parent group. Again setting the default permissions for new files, as noted above can be achieved with acls - which also support the capital "X" parameter:

setfacl -R -d -m u::rwX /Movies
setfacl -R -d -m g::rwX /Movies
setfacl -R -d -m o::r-X /Movies

It really all depends on how you want things set up, for me I wanted four things:

  • To have a common group that allowed write access on my folders.
  • For all new files within those folders to be owned by that common group automatically.
  • For all new files to be writable by that common group.
  • To still allow those permissions to be overridden on a case-by-case basis.

I wrote a small script for another user on the forum, a while ago that does all the above for you:

#!/bin/bash
# --------------------------------------------------
# Usage: script.sh <username> <group> <path>
# --------------------------------------------------

declare -r USERNAME="$1"
declare -r GROUP="$2"
declare -r MEDIA_DIRECTORY="$3"

function tests {

    local thisScript=`basename "$0"`

    # Check for arguments
    if [ -z "$USERNAME" ] || [ -z "$GROUP" ] || [ -z "$MEDIA_DIRECTORY" ]; then
        echo "Usage: $thisScript <username> <group> <directory>"
        exit 1
    fi

    # Does the user exist?
    if ! id "$USERNAME" >/dev/null 2>&1; then
        echo "The user $USERNAME does not exist!"
        exit 1
    fi

    # Does the group exist?
    if [ ! `getent group "$GROUP"` ]; then
        echo "The group $GROUP does not exist!"
        exit 1
    fi

    # Does the path exist?
    if [ ! -d "$MEDIA_DIRECTORY" ]; then
        echo "The path $MEDIA_DIRECTORY does not exist!"
        exit 1
    fi

    # Am I root?
    if [ "$(id -u)" != "0" ]; then
        echo "This script must be run as root!"
        echo "Trying sudo..."
        sudo sh "$0" "$USERNAME" "$GROUP" "$MEDIA_DIRECTORY"
        exit $?
    fi

}

function cleanup {

    # Cleanup any leftover acls / execute bits
    chmod -R a-x "$MEDIA_DIRECTORY"
    setfacl -R -bn "$MEDIA_DIRECTORY"

}

function ownership {

    # Set ownership and set gid
    chown -R "$USERNAME":"$GROUP" "$MEDIA_DIRECTORY"
    chmod -R g+s "$MEDIA_DIRECTORY"

}

function permissions {

    # Set conservative permissions
    chmod -R u+rwX "$MEDIA_DIRECTORY"
    chmod -R g+rwX "$MEDIA_DIRECTORY"
    chmod -R o+rX "$MEDIA_DIRECTORY"

}

function acls {

    # Enforce default permissions via acls
    setfacl -R -d -m u::rwX "$MEDIA_DIRECTORY"
    setfacl -R -d -m g::rwX "$MEDIA_DIRECTORY"
    setfacl -R -d -m o::r-X "$MEDIA_DIRECTORY"

}

tests && \
sleep 0.5 && \

cleanup >/dev/null 2>&1 && \
sleep 0.5 && \

ownership >/dev/null 2>&1 && \
sleep 0.5 && \

permissions >/dev/null 2>&1 && \
sleep 0.5 && \

acls >/dev/null 2>&1 && \
echo "Done."

I've also noted that a lot of people are using more permissive masks on their filesystems, which negates the need to do a lot of the above. I don't like that idea, the above is a fairly robust solution that I've been doing for a number of years.

Edited by dcrdev
  • Like 4
Link to comment
Share on other sites

  • 2 months later...

There must still be something wrong with how emby (or dotnet) handles permissions. If the emby user who is running emby is in the same group as my files and has sufficient permissions to read files, emby still reports "permission denied" on the folder. So either there is an additional permissions check in emby that is too agressive or in the dotnet framework. You can try it out: Remove permissions for other: chmod o-rx on the top "Media" folder and emby fails. If I become the emby user on that linux machine I can access the files though, and also run ffmpeg oder cat on them.

 

On the script above: chmod -R o+rX "$MEDIA_DIRECTORY" is definitely "necessary" although in my world (emby being in the media group) strange. 

Link to comment
Share on other sites

  • 4 months later...
dcrdev

There must still be something wrong with how emby (or dotnet) handles permissions. If the emby user who is running emby is in the same group as my files and has sufficient permissions to read files, emby still reports "permission denied" on the folder. So either there is an additional permissions check in emby that is too agressive or in the dotnet framework. You can try it out: Remove permissions for other: chmod o-rx on the top "Media" folder and emby fails. If I become the emby user on that linux machine I can access the files though, and also run ffmpeg oder cat on them.

 

On the script above: chmod -R o+rX "$MEDIA_DIRECTORY" is definitely "necessary" although in my world (emby being in the media group) strange. 

 

Think you must be doing something wrong, or have not restarted the emby service after making user/group changes.

[root@hell01-serv01 storage]# mv *.mp4 "Deadpool 2 (2018).mp4"
[root@hell01-serv01 storage]# ls
Audiobooks             Documents       Lossy Music  Recordings  Videos
Backup                 Downloads       Movies       Roms        WWW
Deadpool 2 (2018).mp4  Lossless Music  Pictures     TV Shows
[root@hell01-serv01 storage]# mkdir "Deadpool 2 (2018)"
[root@hell01-serv01 storage]# cd Dead*
[root@hell01-serv01 Deadpool 2 (2018)]# mv ../*.mp4 .
[root@hell01-serv01 Deadpool 2 (2018)]# chmod -R u+rwX .
[root@hell01-serv01 Deadpool 2 (2018)]# chmod -R g+rwX .
[root@hell01-serv01 Deadpool 2 (2018)]# chmod -R o-rwX .
[root@hell01-serv01 Deadpool 2 (2018)]# ls -hlpa .
total 868M
drwxrws---+  2 root    storage    3 May 20 10:43 ./
drwxrwsr-x+ 18 root    storage   18 May 20 10:43 ../
-rw-rw----.  1 dominic storage 869M Jun  7  2014 Deadpool 2 (2018).mp4
[root@hell01-serv01 Deadpool 2 (2018)]# groups emby
emby : emby video storage
[root@hell01-serv01 Deadpool 2 (2018)]# ls
Deadpool 2 (2018).mp4
# I ran a library scan at this point to demonstrate
# that emby can write to the folder.
[root@hell01-serv01 Deadpool 2 (2018)]# ls
Deadpool 2 (2018).mp4  Deadpool 2 (2018)-poster.jpg
Link to comment
Share on other sites

  • 1 year later...
Volfan6415

Just wanted to say a huge thank you to @@dcrdev!  I was about to pull my hair out with and NFS share that emby couldn't play movies from and running this script with the proper sharing user on my NFS server cleared everthing right up!

Link to comment
Share on other sites

  • 1 month later...
deltaag

This isn't working for you because you're assuming that read permissions are enough to browse that folder as other, in unix systems directories require the executable bit to list their contents. From reading your post, your folders need 775 and files 664, there's an easy way to do this using the capital "X" parameter of chmod; this will ensure that only directories are executable.

 

So:

chmod -R u+rwX /Movies
chmod -R g+rwX /Movies
chmod -R o+r-X /Movies

Contrary to above chmod -R g+s is not setting the sticky bit, but setting the gid, this ensures that all new files/folders inherit the parent group. Again setting the default permissions for new files, as noted above can be achieved with acls - which also support the capital "X" parameter:

setfacl -R -d -m u::rwX /Movies
setfacl -R -d -m g::rwX /Movies
setfacl -R -d -m o::r-X /Movies

It really all depends on how you want things set up, for me I wanted four things:

  • To have a common group that allowed write access on my folders.
  • For all new files within those folders to be owned by that common group automatically.
  • For all new files to be writable by that common group.
  • To still allow those permissions to be overridden on a case-by-case basis.

I wrote a small script for another user on the forum, a while ago that does all the above for you:

#!/bin/bash
# --------------------------------------------------
# Usage: script.sh <username> <group> <path>
# --------------------------------------------------

declare -r USERNAME="$1"
declare -r GROUP="$2"
declare -r MEDIA_DIRECTORY="$3"

function tests {

    local thisScript=`basename "$0"`

    # Check for arguments
    if [ -z "$USERNAME" ] || [ -z "$GROUP" ] || [ -z "$MEDIA_DIRECTORY" ]; then
        echo "Usage: $thisScript <username> <group> <directory>"
        exit 1
    fi

    # Does the user exist?
    if ! id "$USERNAME" >/dev/null 2>&1; then
        echo "The user $USERNAME does not exist!"
        exit 1
    fi

    # Does the group exist?
    if [ ! `getent group "$GROUP"` ]; then
        echo "The group $GROUP does not exist!"
        exit 1
    fi

    # Does the path exist?
    if [ ! -d "$MEDIA_DIRECTORY" ]; then
        echo "The path $MEDIA_DIRECTORY does not exist!"
        exit 1
    fi

    # Am I root?
    if [ "$(id -u)" != "0" ]; then
        echo "This script must be run as root!"
        echo "Trying sudo..."
        sudo sh "$0" "$USERNAME" "$GROUP" "$MEDIA_DIRECTORY"
        exit $?
    fi

}

function cleanup {

    # Cleanup any leftover acls / execute bits
    chmod -R a-x "$MEDIA_DIRECTORY"
    setfacl -R -bn "$MEDIA_DIRECTORY"

}

function ownership {

    # Set ownership and set gid
    chown -R "$USERNAME":"$GROUP" "$MEDIA_DIRECTORY"
    chmod -R g+s "$MEDIA_DIRECTORY"

}

function permissions {

    # Set conservative permissions
    chmod -R u+rwX "$MEDIA_DIRECTORY"
    chmod -R g+rwX "$MEDIA_DIRECTORY"
    chmod -R o+rX "$MEDIA_DIRECTORY"

}

function acls {

    # Enforce default permissions via acls
    setfacl -R -d -m u::rwX "$MEDIA_DIRECTORY"
    setfacl -R -d -m g::rwX "$MEDIA_DIRECTORY"
    setfacl -R -d -m o::r-X "$MEDIA_DIRECTORY"

}

tests && \
sleep 0.5 && \

cleanup >/dev/null 2>&1 && \
sleep 0.5 && \

ownership >/dev/null 2>&1 && \
sleep 0.5 && \

permissions >/dev/null 2>&1 && \
sleep 0.5 && \

acls >/dev/null 2>&1 && \
echo "Done."

I've also noted that a lot of people are using more permissive masks on their filesystems, which negates the need to do a lot of the above. I don't like that idea, the above is a fairly robust solution that I've been doing for a number of years.

 

Thanks @@dcrdev for the script.

 

I was trying your script on Raspbian 10 (buster) with bash version 5.0.3, running as non-root user needed line 42 to be `bash` rather than `sh` for the script to work.

Link to comment
Share on other sites

Cthalpa

I would not recommend setting write permissions anywhere near Emby!
It has been fatal in the past.
 

Also, you should be fine with setting 644 on your files. This gives any system user read/list rights, and set your folders to 755 so that any user can browser them.

Example, chown all your files to root so no other system user can "accidently" delete your files, and just set simple 644 and 755 permissions.

 

This is the linux way - the right way! Anyone else saying anything else is just asking for trouble!

Edited by Cthalpa
Link to comment
Share on other sites

  • 1 year later...
horstepipe
On 10/10/2017 at 11:48 AM, dcrdev said:

This isn't working for you because you're assuming that read permissions are enough to browse that folder as other, in unix systems directories require the executable bit to list their contents. From reading your post, your folders need 775 and files 664, there's an easy way to do this using the capital "X" parameter of chmod; this will ensure that only directories are executable.

 

So:


chmod -R u+rwX /Movies
chmod -R g+rwX /Movies
chmod -R o+r-X /Movies

Contrary to above chmod -R g+s is not setting the sticky bit, but setting the gid, this ensures that all new files/folders inherit the parent group. Again setting the default permissions for new files, as noted above can be achieved with acls - which also support the capital "X" parameter:


setfacl -R -d -m u::rwX /Movies
setfacl -R -d -m g::rwX /Movies
setfacl -R -d -m o::r-X /Movies

It really all depends on how you want things set up, for me I wanted four things:

  • To have a common group that allowed write access on my folders.
  • For all new files within those folders to be owned by that common group automatically.
  • For all new files to be writable by that common group.
  • To still allow those permissions to be overridden on a case-by-case basis.

I wrote a small script for another user on the forum, a while ago that does all the above for you:


#!/bin/bash
# --------------------------------------------------
# Usage: script.sh <username> <group> <path>
# --------------------------------------------------

declare -r USERNAME="$1"
declare -r GROUP="$2"
declare -r MEDIA_DIRECTORY="$3"

function tests {

    local thisScript=`basename "$0"`

    # Check for arguments
    if [ -z "$USERNAME" ] || [ -z "$GROUP" ] || [ -z "$MEDIA_DIRECTORY" ]; then
        echo "Usage: $thisScript <username> <group> <directory>"
        exit 1
    fi

    # Does the user exist?
    if ! id "$USERNAME" >/dev/null 2>&1; then
        echo "The user $USERNAME does not exist!"
        exit 1
    fi

    # Does the group exist?
    if [ ! `getent group "$GROUP"` ]; then
        echo "The group $GROUP does not exist!"
        exit 1
    fi

    # Does the path exist?
    if [ ! -d "$MEDIA_DIRECTORY" ]; then
        echo "The path $MEDIA_DIRECTORY does not exist!"
        exit 1
    fi

    # Am I root?
    if [ "$(id -u)" != "0" ]; then
        echo "This script must be run as root!"
        echo "Trying sudo..."
        sudo sh "$0" "$USERNAME" "$GROUP" "$MEDIA_DIRECTORY"
        exit $?
    fi

}

function cleanup {

    # Cleanup any leftover acls / execute bits
    chmod -R a-x "$MEDIA_DIRECTORY"
    setfacl -R -bn "$MEDIA_DIRECTORY"

}

function ownership {

    # Set ownership and set gid
    chown -R "$USERNAME":"$GROUP" "$MEDIA_DIRECTORY"
    chmod -R g+s "$MEDIA_DIRECTORY"

}

function permissions {

    # Set conservative permissions
    chmod -R u+rwX "$MEDIA_DIRECTORY"
    chmod -R g+rwX "$MEDIA_DIRECTORY"
    chmod -R o+rX "$MEDIA_DIRECTORY"

}

function acls {

    # Enforce default permissions via acls
    setfacl -R -d -m u::rwX "$MEDIA_DIRECTORY"
    setfacl -R -d -m g::rwX "$MEDIA_DIRECTORY"
    setfacl -R -d -m o::r-X "$MEDIA_DIRECTORY"

}

tests && \
sleep 0.5 && \

cleanup >/dev/null 2>&1 && \
sleep 0.5 && \

ownership >/dev/null 2>&1 && \
sleep 0.5 && \

permissions >/dev/null 2>&1 && \
sleep 0.5 && \

acls >/dev/null 2>&1 && \
echo "Done."

I've also noted that a lot of people are using more permissive masks on their filesystems, which negates the need to do a lot of the above. I don't like that idea, the above is a fairly robust solution that I've been doing for a number of years.

 

hmm I know I set this up successfully one my old server, but on my new one it doesn't work yet. I did the steps you provided. But if Emby creates files (fanarts) they're still owned by emby:emby .

This is ubuntu 20.04.

Can anybody please tell me how to fix this? I have all files within the media folder owned by another user because other apps have to be able to access them.

Link to comment
Share on other sites

Q-Droid

Are you using local or network storage? The approach can be different for each.  As far as permissions and ownership goes the advice from @dcrdev was the best in the forum.

The files and directories created by Emby will always be owned by the runtime process, default emby:emby, unless you change that which you shouldn't have to.

The link below is basically the same thing with a little more explanation but no script.

https://support.emby.media/support/solutions/articles/44001962818-linux-unix-permissions

 

 

Link to comment
Share on other sites

  • 11 months later...
On 10/10/2017 at 18:48, dcrdev said:

This isn't working for you because you're assuming that read permissions are enough to browse that folder as other, in unix systems directories require the executable bit to list their contents. From reading your post, your folders need 775 and files 664, there's an easy way to do this using the capital "X" parameter of chmod; this will ensure that only directories are executable.

 

So:

chmod -R u+rwX /Movies
chmod -R g+rwX /Movies
chmod -R o+r-X /Movies

Contrary to above chmod -R g+s is not setting the sticky bit, but setting the gid, this ensures that all new files/folders inherit the parent group. Again setting the default permissions for new files, as noted above can be achieved with acls - which also support the capital "X" parameter:

setfacl -R -d -m u::rwX /Movies
setfacl -R -d -m g::rwX /Movies
setfacl -R -d -m o::r-X /Movies

It really all depends on how you want things set up, for me I wanted four things:

  • To have a common group that allowed write access on my folders.
  • For all new files within those folders to be owned by that common group automatically.
  • For all new files to be writable by that common group.
  • To still allow those permissions to be overridden on a case-by-case basis.

I wrote a small script for another user on the forum, a while ago that does all the above for you:

#!/bin/bash
# --------------------------------------------------
# Usage: script.sh <username> <group> <path>
# --------------------------------------------------

declare -r USERNAME="$1"
declare -r GROUP="$2"
declare -r MEDIA_DIRECTORY="$3"

function tests {

    local thisScript=`basename "$0"`

    # Check for arguments
    if [ -z "$USERNAME" ] || [ -z "$GROUP" ] || [ -z "$MEDIA_DIRECTORY" ]; then
        echo "Usage: $thisScript <username> <group> <directory>"
        exit 1
    fi

    # Does the user exist?
    if ! id "$USERNAME" >/dev/null 2>&1; then
        echo "The user $USERNAME does not exist!"
        exit 1
    fi

    # Does the group exist?
    if [ ! `getent group "$GROUP"` ]; then
        echo "The group $GROUP does not exist!"
        exit 1
    fi

    # Does the path exist?
    if [ ! -d "$MEDIA_DIRECTORY" ]; then
        echo "The path $MEDIA_DIRECTORY does not exist!"
        exit 1
    fi

    # Am I root?
    if [ "$(id -u)" != "0" ]; then
        echo "This script must be run as root!"
        echo "Trying sudo..."
        sudo sh "$0" "$USERNAME" "$GROUP" "$MEDIA_DIRECTORY"
        exit $?
    fi

}

function cleanup {

    # Cleanup any leftover acls / execute bits
    chmod -R a-x "$MEDIA_DIRECTORY"
    setfacl -R -bn "$MEDIA_DIRECTORY"

}

function ownership {

    # Set ownership and set gid
    chown -R "$USERNAME":"$GROUP" "$MEDIA_DIRECTORY"
    chmod -R g+s "$MEDIA_DIRECTORY"

}

function permissions {

    # Set conservative permissions
    chmod -R u+rwX "$MEDIA_DIRECTORY"
    chmod -R g+rwX "$MEDIA_DIRECTORY"
    chmod -R o+rX "$MEDIA_DIRECTORY"

}

function acls {

    # Enforce default permissions via acls
    setfacl -R -d -m u::rwX "$MEDIA_DIRECTORY"
    setfacl -R -d -m g::rwX "$MEDIA_DIRECTORY"
    setfacl -R -d -m o::r-X "$MEDIA_DIRECTORY"

}

tests && \
sleep 0.5 && \

cleanup >/dev/null 2>&1 && \
sleep 0.5 && \

ownership >/dev/null 2>&1 && \
sleep 0.5 && \

permissions >/dev/null 2>&1 && \
sleep 0.5 && \

acls >/dev/null 2>&1 && \
echo "Done."

I've also noted that a lot of people are using more permissive masks on their filesystems, which negates the need to do a lot of the above. I don't like that idea, the above is a fairly robust solution that I've been doing for a number of years.

Great script. Thanks for sharing, @dcrdev

I am using Raspberry Pi 4 with Raspberry Pi OS that is based on Debian 11. On line 42 I had to change `sh` to `bash` to be:

`sudo bash "$0" "$USERNAME" "$GROUP" "$MEDIA_DIRECTORY"` for the script to work, otherwise I was getting `declare: not found` error message.

Also it seems my Debian version doesn't include `acl` package, requiring `sudo apt update && sudo apt install acl` for installation.

 

Hope this is helpful.

  • Thanks 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...