Permission Problem

[Hatchtek]

 

 

I need some help. My server last week had a power failure and now my dockers keep on getting permission denied errors every time they try to move files.  (example Radarr and Sonarr.)

 

 

tower-diagnostics-20190305-0611.zip

[Hatchtek]

No one?

Sent from my SM-N960U using Tapatalk

[JoeUnraidUser]

I made this script called "perms.sh" to fix my permissions:

Edit: You must run the script as root.

#!/bin/sh

for dir in $(ls -1vd /mnt/cache /mnt/disk[0-9]*)
do
    echo $dir
    chown -cR nobody:users $dir
    chmod -cR ug+rw,ug+X,o-rwx $dir
done

If you want to exclude the appdata directory then use this script:

#!/bin/sh

for dir in $(ls -1vd /mnt/cache/* /mnt/disk[0-9]*/*|grep -v "appdata")
do
    echo $dir
    chown -cR nobody:users $dir
    chmod -cR ug+rw,ug+X,o-rwx $dir
done

perms.sh

[itimpi]

Any reason you are not using the built-in (Docker Safe) New Permissions tool (or the 'newperms' command from the CLI?

[JoeUnraidUser]

17 hours ago, itimpi said:

Any reason you are not using the built-in (Docker Safe) New Permissions tool (or the 'newperms' command from the CLI?

 

I have been running my script from a cron job every night for several years.  I didn't know that at some point a "newperms" script was made.

 

edit:  I looked at the "newperms" script and noticed some things I don't like.  It sets other and group to the same permissions as user.  If user is not set properly, then group and other do not get set properly.  Mine clears other which makes it docker safe and for security reasons not world readable, writable, or executable.

 

edit:  I did a chmod 111, 117, and 177 to some files and then ran "newperms".  All three files were changed to 000 and all the other files on my system were set to world readable and writable.  Also, it did not output what changed so I couldn't save the changes to a log file.

 

edit:  I just found another problem.  MariaDB was not processing "custom.cnf".  The log contained the following:

     Warning: World-writable config file '/etc/mysql/conf.d/custom.cnf' is ignored

"newperms" had set "/mnt/cache/appdata/mariadb/custom.cnf" to 666 so "custom.cnf" was not getting processed.  So I ran my script and restarted MariaDB.  MariaDb processed "custom.cnf" and ran without errors.

 

edit:  Should I make a bug report for "newperms" or are these bugs already known?

[Hatchtek]

On 3/5/2019 at 9:10 PM, JoeUnraidUser said:

I made this script called "perms.sh" to fix my permissions:

Edit: You must run the script as root.

#!/bin/sh

for dir in $(ls -1vd /mnt/cache /mnt/disk[0-9]*)
do
    echo $dir
    chown -cR nobody:users $dir
    chmod -cR ug+rw,ug+X,o-rwx $dir
done

If you want to exclude the appdata directory then use this script:

#!/bin/sh

for dir in $(ls -1vd /mnt/cache/* /mnt/disk[0-9]*/*|grep -v "appdata")
do
    echo $dir
    chown -cR nobody:users $dir
    chmod -cR ug+rw,ug+X,o-rwx $dir
done

 

Thank you for the script 🙂 I will try it. Which one would you use? the one that excludes appdata or not?

[John_M]

18 hours ago, JoeUnraidUser said:

I looked at the "newperms" script and noticed some things I don't like.  It sets other and group to the same permissions as user.  If user is not set properly, then group and other do not get set properly.  Mine clears other which makes it docker safe and for security reasons not world readable, writable, or executable.

 

I agree. The default permissions within Unraid shares are unnecessarily lax. I think there's a fear that unless everything has a mode of 777 then something will break. I prefer permissions that are more or less in line with the ones you use.

 

18 hours ago, JoeUnraidUser said:

I did a chmod 111, 117, and 177 to some files and then ran "newperms".  All three files were changed to 000 and all the other files on my system were set to world readable and writable.

 

The change of mode to 000 is a problem. The change to world readable and writable is expected (though IMO undesirable).

 

18 hours ago, JoeUnraidUser said:

I just found another problem.  MariaDB was not processing "custom.cnf".  The log contained the following:

     Warning: World-writable config file '/etc/mysql/conf.d/custom.cnf' is ignored

"newperms" had set "/mnt/cache/appdata/mariadb/custom.cnf" to 666 so "custom.cnf" was not getting processed.  So I ran my script and restarted MariaDB.  MariaDb processed "custom.cnf" and ran without errors.

 

Applications are beginning to get smarter. It's a good thing that MariaDB reduces the risk of its config file being tampered with.

 

18 hours ago, JoeUnraidUser said:

Should I make a bug report for "newperms" or are these bugs already known?

 

I think newperms was written the way it was because there were more people complaining of problems caused by insufficient permissions than there were of people complaining of security problems caused by having too many permissions. I think we're now at the point where this policy needs to be reviewed. I, for one, would use a tool based on your script in preference to the current newperms for this reason.

 

[JoeUnraidUser]

5 hours ago, Hatchtek said:

Thank you for the script 🙂 I will try it. Which one would you use? the one that excludes appdata or not?

I would use the first one.