Unraid 6.10, permission denied from docker containers


Recommended Posts

Hi!

 

I tried today the upgrade to unraid 6.10 from 6.9.2.

 

The first thing i noticed is that now it takes a world to start the array. A couple of minutes against 10s with 6.9.2. 

 

The second thing is write problems with a few containers. The cause is that containers  are not using the standard uid:99 and gid:100 so they can't write in the host folders. Containers like "nextcloudpi" and "poste.io"

 

It shouldn't be a problem because the shared folder uid and gid match the container. With 6.9.2 works fine, why not with 6.10?

 

I'm using syncthing to do remote backups. Syncthing uses the standard 99:100, but now, it has problems to access the folders of the containers above..

 

Of course, the uid:gid used by that containers were developer election, not mine.

 

Can it be fixed?

 

Thanks

Link to comment
Posted (edited)
On 5/18/2022 at 9:23 PM, ChuskyX said:

Hi!

 

I tried today the upgrade to unraid 6.10 from 6.9.2.

 

The first thing i noticed is that now it takes a world to start the array. A couple of minutes against 10s with 6.9.2.

 

The second thing is write problems with a few containers. The cause is that containers are not using the standard uid:99 and gid:100 so they can't write in the host folders. Containers like "nextcloudpi" and "poste.io"

 

It shouldn't be a problem because the shared folder uid and gid match the container. With 6.9.2 works fine, why not with 6.10?

 

I'm using syncthing to do remote backups. Syncthing uses the standard 99:100, but now, it has problems to access the folders of the containers above..

 

Of course, the uid:gid used by that containers were developer election, not mine.

 

Can it be fixed?

 

Thanks

I fixed it by running the New Permissions tool on the affected folders

 

You can also add this script to user scripts and run it to be more specific on folders instead of shares/disks.

Remember to add the path to your folder 

 

#!/bin/sh

for dir in "/mnt/user/!!you folder path here!!"
do
	echo $dir
	chmod -R ug+rw,ug+X,o-rwx $dir
        chown -R nobody:users $dir
done

 

Edited by mikl
  • Like 3
Link to comment

I was able to fix this by adding --user 99:100 to extra parameters. You can also fix it by setting the grafana appdata folders to 472:root, which is the user/group the grafana container tries to use (and creates these permission issues)

Link to comment

I tried fixing the permissions across a lot of my docker containers but I seem to be having issues across a number of them and I'm not sure what to do. Tried to use the script above, the tool in the OS (the non-docker safe one because obviously it wouldn't hit appdata where the issue is). All had logs in their respective dockers about permission issues. If i used the tools, then things like traefik wouldn't serve the correct ssl cert.

 

Authelia

Sonarr

Radarr

Emby

Traefik

etc.

 

I reverted back to 6.9.2 because I had no clue what else could be going wrong with my system.

The majority of those are linuxserver.io containers with 99/100 permissions and 002 umask but authelia and traefik both aren't.

 

Anyone have a surefire fix for this?

Link to comment

I have the same problems with a couple of my docker containers.

On 5/21/2022 at 8:02 PM, aeleos said:

I was able to fix this by adding --user 99:100 to extra parameters. You can also fix it by setting the grafana appdata folders to 472:root, which is the user/group the grafana container tries to use (and creates these permission issues)

Yes, but I'm not sure if this isn't only a temporary fix...?

Not sure if "--user 99:100 to extra parameters" will work with every container...

 

I tried to install another instance of grafana and it doesn't even start with default settings.

 

My grafana container (running):

root@FloBineDATA:/mnt/user/appdata/grafana# ls -la
total 13312
drwxrwxrwx 1 nobody users       76 May 24 19:51 .
drwxrwxrwx 1 nobody users      928 May 24 19:53 ..
drwxrwxr-x 1    472 root         2 Dec  2 01:02 alerting
drwxrwxr-x 1    472 root         0 Jun 14  2021 csv
-rw-r--r-- 1    472   472 13631488 May 24 19:51 grafana.db
drwxrwxr-x 1    472   472      276 Aug 22  2021 plugins
drwxrwxr-x 1    472   472        0 Sep 18  2020 png
drwxrwxr-x 1    472 root         0 Apr 10 23:34 storage

 

The new test grafana container does not start:

root@FloBineDATA:/mnt/user/appdata/grafana-1# ls -la
total 0
drwxr-xr-x 1 nobody users   0 May 24 19:53 .
drwxrwxrwx 1 nobody users 928 May 24 19:53 ..

The Container log:

GF_PATHS_DATA='/var/lib/grafana' is not writable.
You may have issues with file permissions, more information here: http://docs.grafana.org/installation/docker/#migrate-to-v51-or-later
mkdir: can't create directory '/var/lib/grafana/plugins': Permission denied

** Press ANY KEY to close this window ** 

 

You must add "--user 99:100" to extra parameters OR create the grafana appdata folder with permissions "472:root" before starting the container.

This can't be a final solution....

 

Did anybody open a bug report or is it a docker container (maintainer) problem (maintainers must use "--user 99:100" to get the conainter running in Unraid >= 6.10.0)?? 

Link to comment
Posted (edited)

Having similar issues this end. Duplicacy won't backup and generates a 'permission denied' error. Back to 6.9.2 for me.

 

EDIT: Ran the New Safe Permissions (including the one for Docker containers) but this didn't fix the issue.

Edited by t34wrj
Link to comment
57 minutes ago, t34wrj said:

Duplicacy won't backup and generates a 'permission denied' error.

@t34wrj which container are you using?

I installed "saspus/duplicacy-web" (Docker Hub URL: https://hub.docker.com/r/saspus/duplicacy-web) and this one "survived" the upgrade to 6.10...

 

I think because I have those variable set:

   User ID: 99 (Container Variable: USR_ID)
   Group ID: 100 (Container Variable: GRP_ID)

(It's like using "--user 99:100" in extra parameters)

 

Thes are the file/directory permissions (all ok):

root@FloBineDATA:/mnt/user/appdata/duplicacy# ls -la
drwxrwxrwx 1 root   root      46 Sep 13  2020 .
drwxrwxrwx 1 nobody users    974 May 26 15:39 ..
drwxr-xr-x 1 nobody users     18 Sep 13  2020 cache
drwxrwxrwx 1 nobody users    170 May 27 12:06 config
drwxrwxrwx 1 nobody users 378432 May 27 15:35 logs

root@FloBineDATA:/mnt/user/appdata/duplicacy# cd config/

root@FloBineDATA:/mnt/user/appdata/duplicacy/config# ls -la
drwxrwxrwx 1 nobody users   170 May 27 12:06 .
drwxrwxrwx 1 root   root     46 Sep 13  2020 ..
drwx------ 1 nobody users   210 Dec 21  2020 bin
-rw------- 1 nobody users 31103 May 27 12:06 duplicacy.json
-rw------- 1 nobody users 12209 Jan 13  2020 duplicacy.json_bkp-1
drwx------ 1 nobody users    18 Jan 12  2020 filters
-rw------- 1 nobody users  2971 May 10 02:00 licenses.json
-rw-r--r-- 1 nobody users    33 Jan  2  2020 machine-id
-rw-r--r-- 1 nobody users   144 Jan  2  2020 settings.json
drwx------ 1 nobody users    34 Sep 13  2020 stats

 

Link to comment
4 minutes ago, vakilando said:

@t34wrj which container are you using?

I installed "saspus/duplicacy-web" (Docker Hub URL: https://hub.docker.com/r/saspus/duplicacy-web) and this one "survived" the upgrade to 6.10...

 

I think because I have those variable set:

   User ID: 99 (Container Variable: USR_ID)
   Group ID: 100 (Container Variable: GRP_ID)

(It's like using "--user 99:100" in extra parameters)

 

Thes are the file/directory permissions (all ok):

root@FloBineDATA:/mnt/user/appdata/duplicacy# ls -la
drwxrwxrwx 1 root   root      46 Sep 13  2020 .
drwxrwxrwx 1 nobody users    974 May 26 15:39 ..
drwxr-xr-x 1 nobody users     18 Sep 13  2020 cache
drwxrwxrwx 1 nobody users    170 May 27 12:06 config
drwxrwxrwx 1 nobody users 378432 May 27 15:35 logs

root@FloBineDATA:/mnt/user/appdata/duplicacy# cd config/

root@FloBineDATA:/mnt/user/appdata/duplicacy/config# ls -la
drwxrwxrwx 1 nobody users   170 May 27 12:06 .
drwxrwxrwx 1 root   root     46 Sep 13  2020 ..
drwx------ 1 nobody users   210 Dec 21  2020 bin
-rw------- 1 nobody users 31103 May 27 12:06 duplicacy.json
-rw------- 1 nobody users 12209 Jan 13  2020 duplicacy.json_bkp-1
drwx------ 1 nobody users    18 Jan 12  2020 filters
-rw------- 1 nobody users  2971 May 10 02:00 licenses.json
-rw-r--r-- 1 nobody users    33 Jan  2  2020 machine-id
-rw-r--r-- 1 nobody users   144 Jan  2  2020 settings.json
drwx------ 1 nobody users    34 Sep 13  2020 stats

 

I'm using the same one. The error persisted after I downgraded to 6.9.2 but I managed to fix it by running a CHMOD command on the executable that was referred to in the error message that I found by Googling:

 

chmod u+x /home/duplicacy/.duplicacy-web/bin/duplicacy_linux_x64_2.7.2

Link to comment
2022-05-27 22:20:58.116 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.126 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.136 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.147 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.157 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.167 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.177 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.187 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.197 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.207 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.217 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.227 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.237 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.247 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.257 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.268 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.278 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.288 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.298 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.308 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.318 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.328 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.338 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.348 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.358 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.368 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.378 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.389 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.399 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.409 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.419 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.429 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.439 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.449 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.459 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.469 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.479 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:20:58.489 CST [30] LOG:  using stale statistics instead of current ones because stats collector is not responding
2022-05-27 22:20:58.489 CST [30] WARNING:  could not open statistics file "pg_stat_tmp/global.stat": Permission denied
2022-05-27 22:21:49.221 CST [1] LOG:  could not open file "postmaster.pid": Permission denied; continuing anyway

when i run the postgresq 14 it will shows this.

i have to restart it, make it normal.

i am pretty sure the permission is fine.

Link to comment

@t34wrj mine still has the executable bit:

-rwx------ 1 nobody users 32383675 Dec 21  2020 duplicacy_linux_x64_2.7.2

 

@xenoblade how do the file permissions look like in your postgres appdata folder?

These are mine:

root@FloBineDATA:/mnt/user/appdata/postgres-13.3# ls -la
total 56
drwx------ 1    999 users   530 May 23 04:11 .
drwxrwxrwx 1 nobody users   974 May 26 15:39 ..
-rw------- 1    999   999     3 Jul 31  2021 PG_VERSION
drwxrwxr-x 1    999  1000     0 May  4 21:31 _BACKUPS_
drwx------ 1    999   999    60 May  5 21:24 base
drwx------ 1    999   999   606 May 25 05:00 global
drwx------ 1    999   999     0 Jul 31  2021 pg_commit_ts
drwx------ 1    999   999     0 Jul 31  2021 pg_dynshmem
-rw------- 1    999   999  4782 Jul 31  2021 pg_hba.conf
-rw------- 1    999   999  1636 Jul 31  2021 pg_ident.conf
drwx------ 1    999   999    76 May 27 16:23 pg_logical
drwx------ 1    999   999    28 Jul 31  2021 pg_multixact
drwx------ 1    999   999     0 Jul 31  2021 pg_notify
drwx------ 1    999   999     0 Jul 31  2021 pg_replslot
drwx------ 1    999   999     0 Jul 31  2021 pg_serial
drwx------ 1    999   999     0 Jul 31  2021 pg_snapshots
drwx------ 1    999   999     0 May 23 04:11 pg_stat
drwx------ 1    999   999   118 May 27 16:28 pg_stat_tmp
drwx------ 1    999   999     8 May 10 23:04 pg_subtrans
drwx------ 1    999   999     0 Jul 31  2021 pg_tblspc
drwx------ 1    999   999     0 Jul 31  2021 pg_twophase
drwx------ 1    999   999   268 May 27 02:13 pg_wal
drwx------ 1    999   999     8 Jul 31  2021 pg_xact
-rw------- 1    999   999    88 Jul 31  2021 postgresql.auto.conf
-rw------- 1    999   999 28097 Jul 31  2021 postgresql.conf
-rw------- 1    999   999    36 May 23 04:11 postmaster.opts
-rw------- 1    999   999    94 May 23 04:11 postmaster.pid

 

Link to comment
Posted (edited)
19 minutes ago, vakilando said:

@t34wrj mine still has the executable bit:

-rwx------ 1 nobody users 32383675 Dec 21  2020 duplicacy_linux_x64_2.7.2

 

@xenoblade how do the file permissions look like in your postgres appdata folder?

These are mine:

root@FloBineDATA:/mnt/user/appdata/postgres-13.3# ls -la
total 56
drwx------ 1    999 users   530 May 23 04:11 .
drwxrwxrwx 1 nobody users   974 May 26 15:39 ..
-rw------- 1    999   999     3 Jul 31  2021 PG_VERSION
drwxrwxr-x 1    999  1000     0 May  4 21:31 _BACKUPS_
drwx------ 1    999   999    60 May  5 21:24 base
drwx------ 1    999   999   606 May 25 05:00 global
drwx------ 1    999   999     0 Jul 31  2021 pg_commit_ts
drwx------ 1    999   999     0 Jul 31  2021 pg_dynshmem
-rw------- 1    999   999  4782 Jul 31  2021 pg_hba.conf
-rw------- 1    999   999  1636 Jul 31  2021 pg_ident.conf
drwx------ 1    999   999    76 May 27 16:23 pg_logical
drwx------ 1    999   999    28 Jul 31  2021 pg_multixact
drwx------ 1    999   999     0 Jul 31  2021 pg_notify
drwx------ 1    999   999     0 Jul 31  2021 pg_replslot
drwx------ 1    999   999     0 Jul 31  2021 pg_serial
drwx------ 1    999   999     0 Jul 31  2021 pg_snapshots
drwx------ 1    999   999     0 May 23 04:11 pg_stat
drwx------ 1    999   999   118 May 27 16:28 pg_stat_tmp
drwx------ 1    999   999     8 May 10 23:04 pg_subtrans
drwx------ 1    999   999     0 Jul 31  2021 pg_tblspc
drwx------ 1    999   999     0 Jul 31  2021 pg_twophase
drwx------ 1    999   999   268 May 27 02:13 pg_wal
drwx------ 1    999   999     8 Jul 31  2021 pg_xact
-rw------- 1    999   999    88 Jul 31  2021 postgresql.auto.conf
-rw------- 1    999   999 28097 Jul 31  2021 postgresql.conf
-rw------- 1    999   999    36 May 23 04:11 postmaster.opts
-rw------- 1    999   999    94 May 23 04:11 postmaster.pid

 

thank you

this is mine

root@Tower:/mnt/user/appdata/postgresql14# ls -la
total 64
drwx------ 1    999 users    70 May 27 22:27 ./
drwxrwxrwx 1 nobody users   632 May 10 12:45 ../
-rw-rw-rw- 1    999 users     3 Apr  1 16:29 PG_VERSION
drwxrwxrwx 1    999 users    74 Apr  1 16:29 base/
drwxrwxrwx 1    999 users  4096 May 27 22:28 global/
drwxrwxrwx 1    999 users    10 Apr  1 16:29 pg_commit_ts/
drwxrwxrwx 1    999 users    10 Apr  1 16:29 pg_dynshmem/
-rw-rw-rw- 1    999 users  4821 Apr  1 16:29 pg_hba.conf
-rw-rw-rw- 1    999 users  1636 Apr  1 16:29 pg_ident.conf
drwxrwxrwx 1    999 users    42 May 27 22:28 pg_logical/
drwxrwxrwx 1    999 users    48 Apr  1 16:29 pg_multixact/
drwxrwxrwx 1    999 users    10 Apr  1 16:29 pg_notify/
drwxrwxrwx 1    999 users    10 Apr  1 16:29 pg_replslot/
drwxrwxrwx 1    999 users    10 Apr  1 16:29 pg_serial/
drwxrwxrwx 1    999 users    10 Apr  1 16:29 pg_snapshots/
drwxrwxrwx 1    999 users    10 May 27 20:58 pg_stat/
drwxrwxrwx 1    999 users    22 May 27 22:44 pg_stat_tmp/
drwxrwxrwx 1    999 users    26 May 26 17:00 pg_subtrans/
drwxrwxrwx 1    999 users    10 Apr  1 16:29 pg_tblspc/
drwxrwxrwx 1    999 users    10 Apr  1 16:29 pg_twophase/
drwxrwxrwx 1    999 users   108 May 27 10:00 pg_wal/
drwxrwxrwx 1    999 users    42 Apr 26 05:52 pg_xact/
-rw-rw-rw- 1    999 users    88 Apr  1 16:29 postgresql.auto.conf
-rw-rw-rw- 1    999 users 28847 Apr  1 16:29 postgresql.conf
-rw-rw-rw- 1    999 users    36 May 27 22:27 postmaster.opts
-rw------- 1    999   999    94 May 27 22:28 postmaster.pid

 

Edited by xenoblade
Link to comment
Just now, vakilando said:

@xenoblade strange, nearly same permissions and I had no problems with postgres. also pretty sure they are ok....

yes, it worked well on 6.9.2,but when i upgraded to the version 6.10.0 or 6.10.1

it got error on the first start when the system boot.i have to restart it to make it normal

Very strange

Link to comment
Posted (edited)

I have the same issue.  Lots of containers stopped working.  I went back to 6.9.2 as well.

 

EDIT:  As a glutton for punishment, I tried again.  I ran fixed permissions tool and reinstalled 6.10.2.  Mariadb and NPM had some issues in their logs despite still working.  I deleted the NPM log folder and manually changed maria's custom.cnf permissions to 644.  Plex would no longer transcode audio, so I deleted the codec folder.  So far everything seems to be ok.

Edited by VideoVibrations
Link to comment

Same issue. Tried docker new perms tool and it didn't fix it. I later realized that the containers were complaining about things in /appdata and I don't know how to fix that so I'm reverting to 6.9

Link to comment

I'm having the same issue with Lidarr, however I've been running 6.10.2 for a week and it was fine, it just wont run now as of last night. Any solutions to this? So far its giving permission errors for the config and db file. 

Link to comment

Had the same issue, mostly Plex completely broken. Looked like permissions problems in the log. Tried to migrate from Plex-Media-Server to a fresh binhex-plex but error persisted. Appdata folders didn't look like they had been taken over by root but the whole lot was a giant mess.

 

I'm in the process of rolling back to 6.9.2 now and will keep an eye on the progress since I don't have enough time to spend mucking around with it right now.

Link to comment
On 6/13/2022 at 2:06 PM, spyd4r said:

issue with grafana here, won't start. tried fixing permissions.

 

I just fixed my grafana with brute force:

  • chmod -R 775 /mnt/user/appdata/grafana
  • Add --user 99:100 to Extra Parameters in the container settings
  • Like 1
Link to comment
  • 1 month later...

Had this error on Plex:
 

Quote

Starting Plex Media Server.
Error: Unable to set up server: sqlite3_statement_backend::loadOne: attempt to write a readonly database (N4soci10soci_errorE)

 

It got fixed by using the "New Permissions" tool on "appdata".

 


But I kept getting errors about a corrupted databse, so I used Krusader and this:
https://support.plex.tv/articles/repair-a-corrupted-database/

To restore to a database that works. I think it was my 3rd try before it worked again.

 

Maybe someone can use this.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.