Plex Permissions Issue [SOLVED]

[alienjon]

So this one has me a bit stumped. I had plex installed on a gentoo server and it was working just fine. Then I stupidly messed up a kernel upgrade and ended up doing a clean reinstall of my system. My media (movies, tv shows, music, and audio books) are all stored on separate drives and weren't touched. However, when I reinstalled gentoo and plex, plex could find and play my movies and while it could find my tv shows, it could not play them (came up with a strange error about the file not being found), and my audiobooks wouldn't even show up. After digging in the logs I found that it was a permissions issue.

At this point my files all had read permissions, but ownership and group membership varied (some were root or my user ownership and others had my user or users group membership). Changing to plex:plex and 774 ultimately fixed the issue, but I'm very curious as to why it worked before, but not now. Also, why read membership wasn't sufficient. Any thoughts?

[Hu]

I think we could offer better guidance if you showed the output of namei -l /full/path/to/affected/file, ideally both while it was broken and after you fixed it. Read permission on the file, and search permission on the traversed directories, is required. Execute permission on the file is not required.

[alienjon]

[Hu]

As I said, directories need search. They can have read, but unless the application insists on reading individual directory levels, read is not required for the directories. You could check a backup to see what permissions the directories had at backup time.

[alienjon]

So I think I misunderstood your first comment then. I hadn't realized 'search' was another permission type? I thought that would have fallen under the read category. How do the search permission of a directory?

As an example of namei -l:

[Hu]

Yes, search and read are separate. Read permission (+r) lets you list the contents of the directory. Search permission (+x) lets you open files in that directory, and traverse that directory when resolving a path. It is uncommon, but legal, to have a directory that can be read but not searched or searched but not read. In the first case, users with that level of access can know the files in the directory, but not open them. In the second case, users cannot learn the names of the files in the directory, but if the user knows the filename (perhaps because it is "well known", like we all know that /etc will have a file named passwd), then the file can be opened anyway.

[alienjon]

Of fascinating. Thanks for the time to give details. Way back when I learned +x as just 'execute' and thought it just pertained to actually executing a file in some way. I never really thought more about it, but I can see how that would apply here. Thanks! This is a big help.