Paste here your current podman run command.
docker run
-d
–name plex
–network=host
-e TZ=“Australia/Brisbane”
-e PLEX_UID=1001
-e PLEX_GID=1001
-e PLEX_CLAIM=“”
-v /drives/NVME/plex/database:/config
-v /drives/NVME/transcode/temp:/transcode
-v /drives/NVME/media:/data
plexinc/pms-docker
Do you have a local user that has UID/GID 1001. If not then use your current user instead. Which I would guess is 1000.
Then set the owner of the directory to said user. chown -R username:groupname /drives/NVME/plex
Either way even if the directory is world writeable the user with ID 1001 must still exist in the system unless changed.
no… the user account i log in with is 1001.
i have set the plex owner of /drives/NVME/ -R to bbe my 1001 account
i dont know what is going on
I assume that /drives/NVME/plex/database exists on your CentOS 9 system. I assume you can do ls -l /drives/NVME/plex/database and see the files are owned by 1001.
Have you tried looking at it from the Docker side (Luke, come to the dark side!
). Try docker exec -u 1001 -it plex bash and then do something like ls -l /config. What we are looking for is that, from the Docker side, the files under /config are still owned by 1001.
su to the root account and then run your command. It will still run as the user specified in the UID/GID. I’m not sure how running it as a regular user works as I run everything from the root account. So lets try that first.
I imagine it has something to do with SELinux blocking. Thats always the case for permission errors even when the directory has the correct local permissions.
I also noticed your command is docker instead of podman. Why? Did you install podman or Docker? Should be podman on CentOS. It’s a drop-in replacement for Docker. It’s the same command wise verbatim. If you’re using Docker instead of podman I am positive it’s a SELinux issue.
If SELinux is the problem here then to test the theory you could set SELinux to permissive by running the command: sudo setenforce permissive
You can check SELinux status with: getenforce or sestatus
To change it back to enforcing once everything is figured out you can do: sudo setenforce enforcing
ALSO I notice your command “-v /drives/NVME/plex/database:/config” SHOULD ACTUALLY be “-v /drives/NVME/plex/database:/config:z” This matters ESPECIALLY with SELinux. You need the :z so podman labels the directory correctly with SELinux. Especially if you intend to install Tautulli later or anything else that would need access to the Plex configuration. In-fact your other directories should end with :z too. “-v /drives/NVME/transcode/temp:/transcode:z” and “-v /drives/NVME/media:/data:z”.
The reason my media directories don’t end in :z in the sample command I use is because they are shared drives via NFS. Local drives should end with :z though.
So much for a simple one liner huh. lol… at least we’re learning!
In my setup (Synology, Docker (not Podman)) I have no “:z” on any of my volume mounts and I have no issues with permissions. I think it might be good to verify from the Docker side, that the correct volume is mapped and the permissions look OK. It’d also be curious to see what touch /config/file returns.
Does Synology use SELinux? I don’t think it does and that’s the point here. CentOS however, does use SELinux. :z and :Z respectively are directives for setting SELinux labels from podman/Docker.
Also, the permissions are automatically set with PLEX_UID and PLEX_GID inside the container so the mount inside the container will match those directives no matter what. His issue is the OS is blocking write access even when the permissions are correct on the host or world writeable eg: 777. Therefore since it’s CentOS and not Synology the issue is most likely SELinux blocking.
i am launching docker from root. or did you mean set the uid and the gid to 0 so docker runs plex as root?
yes thet exists. ut i created them while “su root”
the directories are definately mapped correctly.
the first time i tried to run the docker it complained that it couldnt create the directories with out write permissions. so i made them manually and now it complains it cant write files to the locations and needs write permissions
no i just tried that and it still is complaining about read/write access
Read the rest of what I said. SELinux is probably blocking.
Also, why are you using Docker on CentOS. You should be using podman.
Run “sudo setenforce permissive” and then try. Keep UID/GID to 1001 not 0. Let me know what the logs say afterwards.
I don’t know if Synology uses SELinux. I guess the question is do you use SELinux meaning do you have any reason to use it. I’ve used all kinds of Unix/Linux machines including Synology, Ubuntu (all my home machines run Ubuntu), CentOS 7, 8, Alma Linux, RHel, FreeBSD, Solaris and HP-UX. Most if not all of them have SELinux. I’ve actually used SELinux on none of them. Never experienced any permissions problems due to SELinux in any of them for some 45 years now. Never used nor cared about any “:z” nor “:Z” directives.
I don’t understand that sentence. Permissions are not “set” in a container because somebody merely sets an env var. Permissions of files and directories are “set” on the file/directory itself. The setting of an env var tells the OS what user you are so it can determine whether or not you are permitted to access that file or directory. If you say touch a file and then set the owner to root and perms such that only root can write. Then go into a simple Docker container that mounts that file, set PLEX_UID/GUI to some plain user and you will not be able to write to that file, regardless of the SELinux setting.
I’m saying let’s first test plain ole Linux filesystem permissions first before suspecting SELinux by doing docker exec -it plex bash, checking the ownership and perms on the files in question first to rule out that the problem isn’t simply that.
I’d think you might be able to do that setenforce command inside the Docker container too to see if that’s the issue.
If you created them while su root then they are owned by root and not writable by 1001. Change the to be owned by 1001.
He already said he changed the permissions to world writeable. Go back and re-read. Therefore if it’s still complaining about permission issues then it is SELinux blocking. There’s no need to test plain old filesystem permissions when he’s already done that.
Also, setting PLEX_UID/GID does set the permissions inside the container. It uses them for all file/folder creation. My statement is correct. Of course the folder needs to be writeable by the specified UID/GID on the host system OR world writeable like he set it. The statement doesn’t imply that it doesn’t.
Synology and Ubuntu do not use SELinux. They use apparmor. SELinux is enabled by default on CentOS/RHEL. But you say you haven’t used SELinux on any of them so how do you even know.
setenforce will NOT work inside the docker container. That’s for the host machine. The container does NOT use SELinux. The container does NOT have it’s own kernel therefore trying to set SELinux paramaters inside the container will NOT work. You have no idea what you’re talking about.
Since you have never used SELinux as you’ve said of course you havent used :z and :Z directives. They tell podman/Docker to set SELinux naming on the files and folders stated which is needed when actually using SELinux ON CENTOS.
Please stop making this more confusing for the OP by contradicting correct information. The amount of wrong and improper information on this forum is mind boggling.
It would have taken but seconds to check but hey if you want to argue… I’m out. Enjoy your “winnings”.
seems all i had to do was add :z on my volume lines
thanks for the advice everyone
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.
