I’m still periodically running into issues when playing files remotely and transcoding. I suspect it’s an issue with EAC encoded files.
I’ve seen a good number of historical posts about this either being a case of deleting the files from inside the Codecs folder and letting Plex redownload them fresh, but also quite a bit about it being the 8192 limit with Linux inotify tables jamming up EAC playback if that table fills up.
Specifically @ChuckPa wrote some (as usual) excellent directions a few years ago to increase this limit:
However, I’ve read some other posts more recently that suggest newer versions of the kernel shouldn’t have this issue?
Since I’m running DSM 7.2.2 on a DS920+ would this inotify issue still be a possible culprit and thus increasing the inotify limit as per @ChuckPa may still be relevant?
I was able to find a old TrueNAS post that pointed me to the issue. The TrueNAS Plex app was not able to rename the EAC3 codec folder after it unzipped it and had a “.tmp” at the end of the folder. Once I removed the “.tmp” EAC3 files were playable again. I am not focusing on why the Plex Docker app was not able to remove that.
Thanks! I THINK it’s a TrueNAS Docker app issue but I am not 100%.
I saw these in the logs and it pointed me down a hole to the solution.
Aug 08, 2025 05:29:05.768 [140000482679608] INFO - [Req#41c39/Transcode/e064eb4a2f6efa27-com-plexapp-android] CodecManager: obtaining EAE
Aug 08, 2025 05:29:06.255 [140000482679608] ERROR - [Req#41c39/Transcode/e064eb4a2f6efa27-com-plexapp-android] Unzip: could not set executable bit on output file
Aug 08, 2025 05:29:06.255 [140000482679608] ERROR - [Req#41c39/Transcode/e064eb4a2f6efa27-com-plexapp-android] CodecManager: failed to extract zip
If you can get into the filesystem and go to where Plex keeps its files,
you should be able to get into the Codecs directory and start cleaning out where it failed (junk / temp files).. or just delete everything in there and let it start over.
@ChuckPa I can yes, the config dir is mapped. I deleted the codecs folder and every time it recreates it, it has the .tmp and cannot change it but I can manually.
This is a TrueNAS app with all permission that are supposed to be setup already. There is a workload that sets permissions when the container is launched as shown here. I realized that it’s likely a permissions issue I am just not sure what or how. I am also not sure, if I change those, if the permission workload will change them back after.
In one of the links I posted they talked about creating a Plex user in TrueNAS, but again, not sure why that is not in the docs and not part of the permissions workload. Trying to reach out on their forums as well.
I did just notice that permissions for apps was “modify”, I changed it to “traverse”. I think that adds execute?
Edit. That did not allow the app to run
Edit 2! Changed permissions to that dataset for the Apps use to Full Control (to test). Still does not remove the .tmp from the codec (I renamed the folder to force Plex to recreate it). So for the Plex folder dataset the owner is apps and the apps user has full control. I will full admit Linux permissions confuse me, always have, but this seems like it should be able to rename that folder?
Edit3: I created the Plex user with 972 gave it full permission to the dataset recursively. Edited the app to run as that user and still cannot remove the .tmp from the codec. I am not going to deny that its permissions but I am out of ideas. I am not sure how the app can created the codec folder, when it’s deleted, but then be unable to rename a folder under it?
Directory permissions should resolve to the 0755.
Linux permissions mode for directories: Execute == Traverse.
(you don’t execute a directory, you traverse it).
0 = no super user privileges
7 = Owner has Read, Write, Execute
5 = Group has Read, Execute
5 = Other (world) has Read, Execute
@ChuckPa I was on the Git for the TrueNAS Apps and he told me this if it help
Permissions container will only apply changes if the directory is empty. ie set initial permissions.
But Plex specifically also handles some permissions itself. But in this case it seems that the unzip program have issues setting those permissions. The container has all the needed capabilities to do so.
So its either the ACL type blocking this operation, or plex launches unzip in a way that loses the capability to set permissions (in this case the executable bit)