ChuckPa/PlexDBRepair

ERROR: Cannot write to Databases directory. Insufficient privilege - lscr.io/linuxserver/plex container - After v1.0.13

Healzangels opened this issue · 6 comments

Greetings!

Wanted to start off saying thanks for the wonderful script!
I've found myself running into an issue recently when trying to run new versions of the script. I previous was running v1.0.12 which launched without issue

I've found any version after that starting with v1.0.13 I receive the error:
ERROR: Cannot write to Databases directory. Insufficient privilege

I am currently running the lscr.io/linuxserver/plex latest branch.
This including:
PUID: 99
PGID:100
UMASK: 022

Running ls -la on the config location shows the following.
ls -la config

Thanks and appreciate assistance in tracking down my problem. Cheers!

In the code,

# We might not be root but minimally make sure we have write access
if [ ! -w "$DBDIR" ]; then
  echo ERROR: Cannot write to Databases directory.  Insufficient privilege.
  exit 2
fi

where DBDIR is defined :


    # Docker (All main image variants except binhex and hotio)
    elif [ -d "/config/Library/Application Support" ]; then

      PLEX_SQLITE="/usr/lib/plexmediaserver/Plex SQLite"
      AppSuppDir="/config/Library/Application Support"
      PID_FILE="$AppSuppDir/Plex Media Server/plexmediaserver.pid"
      DBDIR="$AppSuppDir/Plex Media Server/Plug-in Support/Databases"
      LOGFILE="$DBDIR/DBRepair.log"
      LOG_TOOL="logger"

The -w test will confirm 'writable' status for all directories in the path (how the shell works)

Given I've had no reports of problems with this test since making the change (root no longer required),
it's important to know which UID/GID you're in the container as.

I recommend:

# id $(whoami)

From there, we start tracking the permissions as the /config maps into the host.
look at UID/GID (from the outside) and make sure 99/100 have permission. Something got dinged along the way.

Gotcha, I think!

I've run whoami from with the Plex container.
Root
Showing root.

I've also run checked on the owner/permission for the /config location from the host. They appear as the following:
LS

Running same commands from the Plex container console have the following results.
LS Container

While that all looks right, there's obviously something wrong with the container.

I see things in your existing server data which I don't recognize

  1. Diagnostics
  2. PIC Restore
  3. Plug-in
  4. Scripts

Next, notice your transcode directory has different permissions.

Now for big question.

  1. Is /mnt/user/pms a real mount point for another HDD ?
  2. If so, did you set permissions on the BASE directory before mounting?
    (if the base has Read-only for the UID/GID then having R/W after mount still won't work)
    Linux is really weird on this. The base directory for the mount must support (allow) the same or more permissions
    than the filesystem mounted on it has.

Lastly, if that doesn't apply, I'd like to suggest:

cd /mnt/user/pms 
find . -type d -exec chmod 755 {}\;
find . -type f -exec chmod 644 {} \;
chown -R 99.100  . 

Thanks for taking a peak!

The four directories Diagnostics, PIC Restore, Plug-in, Scripts I had used at different points, extra image cleanup (custom art work!)/attempting to setup plug-ins.

The transcode directory maybe it's late and I'm just missing it but looks the same as other such as the Media directory and a few others. Again I might be missing something obvious there. D'oh

Now the big question.

I'm not sure I fully understand it/maybe just missing an understanding of UID/GID + Linux Mounts but I'll do my best to answer!

/pms is a share/directory created on a separate SSD on my system that only holds my Plex config.
pms

Plex is what I've set to be the name of the SSD.

The container then has the /config container location mapped to host /mnt/plex/pms/
plex mapping

So if I'm understanding correctly I'll want to check that base /pms directory (since root folder on the drive) and confirm that UID/GID have R/W permission.

Or maybe I'm misunderstanding a bit and this doesn't apply to my setup in the fashion I've described in which case the commands above are my next step.

Thanks once again! My next step is also finding your buy me a coffee link!

So if I'm understanding correctly I'll want to check that base /pms directory (since root folder on the drive) and confirm that UID/GID have R/W permission.

Correct.

You're using /pms as the base directory. By default, non-privileged UIDs cannot WRITE in the root directory or any immediate directory under root -- e.g. /pms.

You need to umount /pms (the ssd's real mount point) and confirm there.
Once permission granted there, mount and confirm again.
(this is true of mounting any block device with a filesystem in Linux. (been this way forever)

Example:

I want to grant RW to group into the filesystem

umount /mydisk
chmod 775 /mydisk
mount /mydisk

At this point, 775 is underneath the filesystem's '755' at the top but that's ok. Deeper inside, I then grant 775 to whichever directories I want as I need to

Well I think I may have lead us down an endless rabbit hole. Also thanks for all your time and help on this!

Testing today I created a new plex docker container with same image and pointed it to my old /pms location with all contents still there. Launched and tested script and low and behold it launched!
So go and begin adding the extra paths, variables for hardware transcoding etc.

I also added back in variables back in for Theme-Park (DOCKER_MODS) and my TP_THEME and tested again and boom back to the ERROR: Cannot write to Databases directory. Insufficient privilege. Removed the DOCKER_MODS line and it runs again.

So something about that the script didn't like. I've since got both the Theme working again and the script also running by altering the DOCKER_MODS value to match https://docs.theme-park.dev/setup/#lsio-example

Apologies for what ended up being a bit of a wild goose chase and thanks once again for all your time and support on the issue!