Hi - I have a new install (less than 2 days) of Plex 1.1.3 on TrueNas Electric Eel (24.10.0.2) and have created Storage for all storage options. On a 1TB mirror drive I have a dataset for Plex’s logs, and Plex’s configuration which based on Dataset statistics has the following allocated:
Plex Config: 1.35 GiB
Plex Logs 4.02 MiB
What is odd is that (along with the .ix-apps) is really the only thing on that drive – I got an alert to the drive being over 80% full about 24 hours later and a few hours after when I got around to checking it was 95% full. When I noticed how full it was I stopped the Plex app and thought I’d get back to it later to try to figure it out. 8 hours later I logged in to see the pool was down to 50% full and over the past few hours continues to shrink with no action other than stopping the app 8 hours prior.
I do not have snapshots configured for this 1TB mirror pool.
Any insights as to why this might happen or where I can look to maybe gain some understanding (or even better what configuration may be causing this to stop the pool from filling when nothing appears to be using the storage?)
I ran zfs list and got the following insights (it looks like docker is doing something odd)
Just because you don’t have snapshots configured doesn’t mean that TrueNAS hasn’t configured any (on the ix-apps dataset). You should probably check.
But yes, it does look like Docker is using the space.
I would start apps again and once disk space used starts to ramp up, I would do a directory listing ls -lR /mnt/AppBax/ix-apps/Docker/ and shapshot listing to see what is happening inside this dataset.
I have done a little more digging and have found it is growing in the overlay2 directory inside of docker. I have all storage configurating configured to mountpoints (not using ix-Apps) I’ll dig into the logs of Plex to see if I can learn anything there.
The reclaiming of space occurs as after stopping the overlay2 directory seems to recover (maybe a purge going on that I didn’t start?)
Plex is just writing to a directory in the virtualised file system that is NOT being mapped to a host path.
If you open a CLI inside the container you should be able to look at the virtual file system and see what it is and whether you only need to delete it and mount a host path there and Plex will recreate it or alternatively whether you need to mount a host path at a different location, copy the data into it, shutdown the app and delete the data in the ixVolume, then change the mount point to where the original was and restart Plex.
I would know how to do this in Dragonfish, but since I have not yet upgraded to EE (and probably won’t do so until .2 - I will review the .1 fixes and outstanding issues once it is released in a week or two) I don’t have personal experience with EE and cannot help with the details.
Thank you @Protopia – that is a great idea (and does seem like the right one). I do know how to get into the CLI for the virtualized system, however what is the best way to find the file(s) in the virtualized system that is opened / being written to? (Is there any better way than searching using ls -l and looking at timestamps?)
There is almost certainly a linux utility to list tree sizes. But it depends what O/S commands are available in the docker container. A lot are based on Alpine in order to keep the size down and that cut down Linux is short on such commands.
But you can probably run this as root against the files that are visible in the iX applications dataset for Plex.
Thanks again @Protopia --the du command does in fact do that, however what I see is inside of the container it does not differentiate the already mapped directories. I hope that is just a minor inconvenience – trying your idea.
I started watching the internal file system and the problem seems to have gone away.
I did add the “Apps” group access to the mount location where the transcode storage is set. (The “Apps” user already had access) - I will watch it over the next week and get back with the community.
It is entirely possible that if Plex finds it cannot e.g. write transcoding files in the normal location due to permissions it then writes them to an alternative location which is not a host path. This would create the symptoms you have reported.
Well it is holding steady on storage for ~a week, at about 2GB, no where near the near 1TB that it would grow. It does seem that the apps group access to the transcoding mount point was the fix for me (the only change I made) – I had the apps user, but not the group.
@Chris_Holzer its interesting that it would just fail for you, I would have preferred that. I did look at the logs while I was having the issues but I didn’t see anything that pointed me in the right direction. I just changed the access after reading about required permissions.
I had this problem a while back also and I never did find the issue. In my case merely looking for where the space was used with NCDU got me all my free space back too.
I don’t think I’m transcoding, the TV I’m playing on should be able to do the media I have just fine. But this is a interesting Idea.
In plex the transcoding directory for temp files is empty, as in there’s nothing in that setting entered at all.
But the only directory that’s mounted in the jail is where my media files are and I don’t think that is filling up. It shouldn’t even be possible because the plex mount is read only. So if it is filling up a temp directory it’s inside the jail.
My post from last year was on the old forum with subject “Plex jail filling up my drive”. I don’t think I can post links yet.
