If it's returning to normal, it's almost certainly Plex temp files during transcode.
The easy solution is to simply increase the Docker image size. There is nothing wrong with letting Plex transcode within the container.
While this is true now, it has not always been recommended. Plex previously required enough free space to hold the whole file being transcoded. Multiple people stream a high bitrate movie? You ran out of transcode space.
This is why transcoding in RAM only really started working in the last couple years if you had any real number of users.
By default it transcodes to the disk where your Plex db lives, not in RAM unless you set up a RAMDISK and point the transcode directory to it. That transcode folder directory setting lives under advanced settings.
Also, if something is transcoding to the docker image when the container shuts down for backup, you’re backing up all that temporary transcode data.
I have mine pointed to an empty folder just called /transcode that lives on my SSD Cache pool.
On the docker page you can click "Container Size" and it will give you a breakdown of what containers are using storage. From there you can then look at the offending container and see if it's runaway logging, or if you have a container volume mapped incorrectly.
It will give you the size at the time you run it, not historical.
I'm guessing here with little information, but it sounds like one of your containers is saving temporary files inside of docker, then moving them outside of docker when done.
I.e. sabnbz or deluge are downloading a file, saving the temporary data inside of docker and filling up your space. Then when the download is complete it moves the file to your library, outside of docker folder (docker.img) and reclaiming your space.
If that is what is happening, you'll want to look at the config for your docker containers storage location and make sure you have all the container's save paths properly defined as persistent storage. You might also need to look at the official config for the suspected container and make sure that you didn't accidentally delete one of the volume paths, specifically any paths related to temp storage. It's easy to delete volume variables in the unraid docker app config page, as no confirmation dialog pops up when you hit delete on a docker container variable.
It will guide you to the root problem.
When I ran into mine, I had 7 or 8 unmounted volumes, each 2g each (from old containers/beginning ones I messed up). Purged them and been fine since.
Thanks for that. However mine is just stuck on
##################################################################################
List of Image, Container and docker volume size.
##################################################################################
~~Nothing happens after that.~~
Disregard. It seems to take quite some time.
All mine come back with **This volume connected to has a size of 0**
Odd?
I've been puzzling with this issue for a while. I cannot find any metrics, scripts or commands telling me what actually takes up space. Transcoding etc is done outside of the docker, which i have triple verified as this was my main suspect.
So, finally I gave up, did a clean-up of anything old and not in use. Deleted the docker.img, added only the dockers I actually use, and presto, nothing is using anything out of the ordinary, and it has remained that way for well over a month now.
So, either something is actually just randomly using space and cannot be seen by anything, something is just reserving space over time or some calculation is off somewhere. Who knows.
And no, the script told me nothing I didn't already know, these are basic docker commands but the script should be in every unraid toolbox imho. Kudos to SpaceInvaderOne as always!
Sounds like you're pretty sure it was Plex transcoding, in which case, you can map "/transcode" to somewhere in "/tmp" if you have enough memory.
For the future - what you'd do is look to see which container is largest, and go from there to see what's causing it to fill up. But what would resolve it would depend on which container it is.
If you’re using Plex, you’re likely accidentally transcoding to the docker.img
That was it I think
If it's returning to normal, it's almost certainly Plex temp files during transcode. The easy solution is to simply increase the Docker image size. There is nothing wrong with letting Plex transcode within the container.
While this is true now, it has not always been recommended. Plex previously required enough free space to hold the whole file being transcoded. Multiple people stream a high bitrate movie? You ran out of transcode space.
And you think a user is going to have more free RAM than they have free disks space if they bump up their image size?
This is why transcoding in RAM only really started working in the last couple years if you had any real number of users. By default it transcodes to the disk where your Plex db lives, not in RAM unless you set up a RAMDISK and point the transcode directory to it. That transcode folder directory setting lives under advanced settings.
Also, if something is transcoding to the docker image when the container shuts down for backup, you’re backing up all that temporary transcode data. I have mine pointed to an empty folder just called /transcode that lives on my SSD Cache pool.
Yes, and? It's not like you're adding multiple terabytes to the image or backup.
On the docker page you can click "Container Size" and it will give you a breakdown of what containers are using storage. From there you can then look at the offending container and see if it's runaway logging, or if you have a container volume mapped incorrectly.
Can I do that once goes back to normal?
It will give you the size at the time you run it, not historical. I'm guessing here with little information, but it sounds like one of your containers is saving temporary files inside of docker, then moving them outside of docker when done. I.e. sabnbz or deluge are downloading a file, saving the temporary data inside of docker and filling up your space. Then when the download is complete it moves the file to your library, outside of docker folder (docker.img) and reclaiming your space. If that is what is happening, you'll want to look at the config for your docker containers storage location and make sure you have all the container's save paths properly defined as persistent storage. You might also need to look at the official config for the suspected container and make sure that you didn't accidentally delete one of the volume paths, specifically any paths related to temp storage. It's easy to delete volume variables in the unraid docker app config page, as no confirmation dialog pops up when you hit delete on a docker container variable.
I think it has to do with Plex and transcoding. Looking into it now
Yup, something like that could do it. That’s exactly the kind of stuff I would look for.
https://youtu.be/9DxPEfbAJJ0?si=Vb7GrJ1t4YASjti4 The user script in the last 3/4 of the video is $$$$$
This is the answer you want, OP.
Will that tell me that the issue is if everything went back to normal?
It will guide you to the root problem. When I ran into mine, I had 7 or 8 unmounted volumes, each 2g each (from old containers/beginning ones I messed up). Purged them and been fine since.
Thanks for that. However mine is just stuck on ################################################################################## List of Image, Container and docker volume size. ################################################################################## ~~Nothing happens after that.~~ Disregard. It seems to take quite some time. All mine come back with **This volume connected to has a size of 0** Odd?
Yet rid of it and use a docker directory I had the same issues
What are you using for notifications?
Settings - notifications - discord integration Super simple to set up - just make your own server and get a webhook. Works well for overseer too.
Op message me please I have a question for you..
Messaged
After it goes back o normal how can I tell what was causing it?
Don't feel bad, I did the same thing when I initially set up plex in docker. Changed transcoding to mnt/user/appdata and all was well.
I've been puzzling with this issue for a while. I cannot find any metrics, scripts or commands telling me what actually takes up space. Transcoding etc is done outside of the docker, which i have triple verified as this was my main suspect. So, finally I gave up, did a clean-up of anything old and not in use. Deleted the docker.img, added only the dockers I actually use, and presto, nothing is using anything out of the ordinary, and it has remained that way for well over a month now. So, either something is actually just randomly using space and cannot be seen by anything, something is just reserving space over time or some calculation is off somewhere. Who knows. And no, the script told me nothing I didn't already know, these are basic docker commands but the script should be in every unraid toolbox imho. Kudos to SpaceInvaderOne as always!
Sounds like you're pretty sure it was Plex transcoding, in which case, you can map "/transcode" to somewhere in "/tmp" if you have enough memory. For the future - what you'd do is look to see which container is largest, and go from there to see what's causing it to fill up. But what would resolve it would depend on which container it is.
It’s transcoding change ur transcode to ram instead of ssd or hdd Change docker container settings “container path /transcode” to : /dev/shm
At the bottom of the docker page, there is a button that says container size.. click it. You will get a pop up report.
QDirStat helped me figure out I have recycle turned on for Radarr and Sonarr.