No space left on device

1. offizieller Beitrag

    I'm getting this error on OMV 5.6.10-1 on a Raspberry Pi 4. Everything works fine when I first install the system but over time I start getting these errors. I believe the problem is due to the Plex Metadata file which is 9 GB in size and is stored in the /var/lib/plexmediaserver/Library/Application Support/Plex Media Service folder. What I don't understand is why it works initially and then starts getting errors even if I haven't added anything to my Plex library. I'm guessing that this file is consuming most available space so that there is no room for updates. To test this theory, I'd like to move this file to my NAS drive but I'm not sure how to do it. Can anyone give me some guidance? (Please keep it simple - I'm still new at this).


    P.S. I'm also using Docker and Portainer if that is pertinent.

    You need to change the volume bind mount location for the Plex /config. Put it on a data drive, not in /var.


    You can stop the Plex docker and copy the library from the old location to the new location, but it's probably easier to just let Plex regenerate it.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    Are you referring to the /config path in the Docker container? Mine is set to /srv/dev-disk-by-label-NAS/Config/Plex. I don't see where anything is set up to go into /var.

    Then why did you say this:


    " I believe the problem is due to the Plex Metadata file which is 9 GB in size and is stored in the /var/lib/plexmediaserver/Library/Application Support/Plex Media Service folder."

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    I thought it might be the Metadata file since it was the largest file I found. I thought that the location for that file might be defined somewhere other than the plex container that I was looking at (remember I'm a beginner). How is that Metadata file being directed to the /var folder?


    I'm assuming the device that is running out of space is the SD card since my NAS and all of my other drives have plenty of space. I'll check the above link for the OS files and try running the df command.

    • Offizieller Beitrag
    Zitat von gabe817

    I thought it might be the Metadata file since it was the largest file I found. I thought that the location for that file might be defined somewhere other than the plex container that I was looking at (remember I'm a beginner). How is that Metadata file being directed to the /var folder?


    I'm assuming the device that is running out of space is the SD card since my NAS and all of my other drives have plenty of space. I'll check the above link for the OS files and try running the df command.

    It's a common misconception that metadata is stored somewhere in /config... it's not. The same issue pops up with Emby and Jellyfin. Metadata is stored somewhere in the container that is not traditionally recommended to be mapped elsewhere (I'm not sure exactly where)... thus why if your container folder is still on your OS drive... it's going to fill your OS drive.


    Your best bet is to remap your container folder.

    Zitat von KM0201

    It's a common misconception that metadata is stored somewhere in /config... it's not. The same issue pops up with Emby and Jellyfin. Metadata is stored somewhere in the container that is not traditionally recommended to be mapped elsewhere (I'm not sure exactly where)... thus why if your container folder is still on your OS drive... it's going to fill your OS drive.

    This is absolutely not the case.


    For the Plex dockers, the /config Path in container points to some directory on the system, the Host volume. This directory holds the entirety of the metadata in a subdirectory named /Library/Application Support/Plex Media Server/


    If you do not define such a bind, or the drive the bind is pointed to is missing or not mounted, then /config might wind up relocated inside the container, or the container might refuse to start.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    • Offizieller Beitrag
    Zitat von gderf

    This is absolutely not the case.


    For the Plex dockers, the /config Path in container points to some directory on the system, the Host volume. This directory holds the entirety of the metadata in a subdirectory named /Library/Application Support/Plex Media Server/


    If you do not define such a bind, or the drive the bind is pointed to is missing or not mounted, then /config might wind up relocated inside the container, or the container might refuse to start.

    I've seen this multiple times where people have properly mapped a config directory and still end up with a full OS drive due to plex (and emby and jellyfin)


    Read post #3.. it appears he properly mapped his /config directory


    OP, can you post the output of this command (note, the below assumes your plex container is named plex... if it's not, substitute the name there)

    Code
    docker inspect plex | grep /config

    Then separately post the output of this command...

    Code
    docker info | grep Root

    Properly mapping the /config directory isn't enough. The drive being mapped to must be mounted and the container must be running as a user that has read/write/execute permissions to that directory.


    It's also possible that /var/lib/plexmediaserver/Library/Application Support/Plex Media Server/ is populated with leftovers from a previous direct install of Plex that should have been erased.


    But unless and until the OP decides to post enough information, it's all guesswork. And I'm not going to continue that.


    Stating that docker and Portainer are being used is inadequate.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    KM0201 - I know how to execute those commands in Putty but I can't seem to be able to copy the output and I don't know how to redirect the output to a file I can access through Windows (my beginner status is showing).


    gderf - It's not that I'm deciding to not post enough information - I just don't know what information is helpful. I do think you may be on to something when you state that the Metadata file might be a leftover from a previous installation. As a newbie, it did take a couple of attempts to get the system to where I felt it was running properly. What would happen if I just delete that file? If it was necessary, would Plex just recreate it?


    One other thing I need to point out - when I got the out of space error, my system stopped working so I replaced the SD card with my backup. I'm not currently getting the error but it's only a matter of time before I do because I've been thru this cycle a couple of times already.

    We don't know if you have a properly running and configured Plex docker because you haven't showed us how you deployed it. But I can say two things:


    Don't use Portainer to build docker containers. Using it is difficult, prone to error, and very difficult to show others how you built the container. The best way is to look at the image documentation, copy the docker run example command and edit it to agree with your use case. Once you have done that you can try running it in the shell and sharing it with others if it doesn't work you need help. They can ask questions about it and other related matters and suggest corrections.


    There is no way that the docker is writing its Library into /var/lib/..... unless you explicitly told it to do so because a docker can't write anywhere outside the running container unless it's explicitly told to do so. This is basically the entire point of docker. I suggest that you recursively delete the /plexmediaserver/Library/Application Support/Plex Media Server folder in /var/lib. Do not delete anything else in /var/lib. Then restart the container and see what happens. Don't expect much though.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    Okay, here are the outputs requested -


    df

    Filesystem 1K-blocks Used Available Use% Mounted on

    /dev/root 30483740 24634616 4587128 85% /

    devtmpfs 823564 0 823564 0% /dev

    tmpfs 955660 128 955532 1% /dev/shm

    tmpfs 955660 26996 928664 3% /run

    tmpfs 5120 4 5116 1% /run/lock

    tmpfs 955660 0 955660 0% /sys/fs/cgroup

    tmpfs 955660 32 955628 1% /tmp

    /dev/mmcblk0p1 258095 48790 209306 19% /boot

    folder2ram 955660 8072 947588 1% /var/log

    folder2ram 955660 0 955660 0% /var/tmp

    folder2ram 955660 816 954844 1% /var/lib/openmediavault/rrd

    folder2ram 955660 732 954928 1% /var/spool

    folder2ram 955660 15788 939872 2% /var/lib/rrdcached

    folder2ram 955660 8 955652 1% /var/lib/monit

    folder2ram 955660 1604 954056 1% /var/cache/samba

    /dev/sda2 3857712760 795668584 2866680644 22% /srv/dev-disk-by-label-NASDATA

    overlay 30483740 24634616 4587128 85% /Config/overlay2/20cda455074c21fa219041c9e7bfb4b1dcdda07f822aaa22dd54faf219bff1bb/merged

    overlay 30483740 24634616 4587128 85% /Config/overlay2/c2d302db13bdf96ed243cc41d238b17e0762edc778ca6c2b8b74c27d5fad636f/merged

    tmpfs 191132 0 191132 0% /run/user/1000



    docker inspect plex | grep /config

    "/srv/dev-disk-by-label-NASDATA/Config/Plex:/config",

    "Destination": "/config",

    "PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR=/config/Library/Application Support",

    "/config": {}



    docker info | grep Root

    WARNING: No memory limit support

    WARNING: No swap limit support

    WARNING: No kernel memory TCP limit support

    WARNING: No oom kill disable support

    Docker Root Dir: /Config



    My plex container is named plex.

    gderf - as is pretty obvious by now I'm not well versed in Docker, Portainer or even Linux in general. I put together this system by following a YouTube video. I don't know how to build a container without using Portainer (maybe there's a YouTube video for that?). I'm not sure what image documentation you are referring to and what you mean by running it in the shell. I will say that when the system is running, it is great - does everything I needed and is very responsive. I just need to solve this out of space problem. I think I will try just deleting the Metadata file on the assumption that it was a leftover from a previous failed installation. The worst that can happen is that I have to burn another SD card from my backup.


    Thanks for all of the help you and everyone else has given me.

    The problems with mentioning that you watched a YouTube video are that few if any who are willing to help you are going to watch that video, and even if they did, it would tell them what the video author did, not what you did. Not helpful.


    Every decent docker image comes with documentation. That documentation is in 99% of cases all you need to turn up a container in a few seconds. And it will just work.


    One of the underlying assumptions with OMV is that its users have some minimal knowledge of Linux concepts, and they know how to locate and read documentation.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    KM0201 - I completely ran out of space on the setup I posted earlier. When that happens I'm no longer able to log into the OMV GUI so I installed my backup SD card and started over. Here are the outputs you requested with the new card.

    df

    Filesystem 1K-blocks Used Available Use% Mounted on

    /dev/root 29951132 27227200 1486316 95% /

    devtmpfs 823564 0 823564 0% /dev

    tmpfs 955660 4 955656 1% /dev/shm

    tmpfs 955660 26860 928800 3% /run

    tmpfs 5120 4 5116 1% /run/lock

    tmpfs 955660 0 955660 0% /sys/fs/cgroup

    tmpfs 955660 120 955540 1% /tmp

    /dev/mmcblk0p1 258095 48790 209306 19% /boot

    folder2ram 955660 9320 946340 1% /var/log

    folder2ram 955660 0 955660 0% /var/tmp

    folder2ram 955660 808 954852 1% /var/lib/openmediavault/rrd

    folder2ram 955660 732 954928 1% /var/spool

    folder2ram 955660 15156 940504 2% /var/lib/rrdcached

    folder2ram 955660 4 955656 1% /var/lib/monit

    folder2ram 955660 1604 954056 1% /var/cache/samba

    /dev/sda2 3857712760 826237280 2836111948 23% /srv/dev-disk-by-label-NASDATA

    overlay 29951132 27227200 1486316 95% /Config/overlay2/386987b76069a7008ec9d46507268d37d96c4b1953ac9e23144fa2518581ce79/merged

    overlay 29951132 27227200 1486316 95% /Config/overlay2/4bffc4a6a16785d23732d69ca963bb7d254a4d76686c1bccb680fa5167e38c78/merged

    tmpfs 191132 0 191132 0% /run/user/0

    tmpfs 191132 0 191132 0% /run/user/1000


    sudo docker inspect plex | grep /config

    "/srv/dev-disk-by-label-NASDATA/Config/Plex:/config"

    "Destination": "/config",

    "PLEX_MEDIA_SERVER_APPLICATION_SUPPORT_DIR=/config/Library/Application Support",

    "/config": {}


    sudo docker info | grep Root

    WARNING: No memory limit support

    WARNING: No swap limit support

    WARNING: No kernel memory TCP limit support

    WARNING: No oom kill disable support

    Docker Root Dir: /Config


    The /Config/overlay2 folder seems to be the culprit. I ran the df command immediately after inserting the new card and it was down to 58%. As you can see it is now up to 95%.


    Here's the content of ?Config/overlay2


    sudo ls

    1722e8915fb83ee510a04358e1f07c6c9e3efeb9842b7a745fc87c2faaee1a99

    1c6b35df5fd11f1bfab8b58712bce600e4093c52cfbeb2e9824a7c4d2149b9a5

    386987b76069a7008ec9d46507268d37d96c4b1953ac9e23144fa2518581ce79

    386987b76069a7008ec9d46507268d37d96c4b1953ac9e23144fa2518581ce79-init

    3ca0eea86cf4f46f25f2422a243cc1be14876418df0675d64c06b3c1f94b6006

    45dc44c82f99be9de8bcea122df7a832ff5fd6ae049f8ebc58533743043f1dbe

    4bffc4a6a16785d23732d69ca963bb7d254a4d76686c1bccb680fa5167e38c78

    4bffc4a6a16785d23732d69ca963bb7d254a4d76686c1bccb680fa5167e38c78-init

    5ceec86fcfb507260713552a05f4039ecd7f1792d1c2142ea3d03c1ecbabb9d9

    67696d3239af350965de9abf6924a97a6529d8abac2d618761b029c04bb5badb

    6fdd17001654d1f24ab385ff513e6bfbac1392b937f9447d485349b7f29f4498

    86cde3b6697da672d4801479756b44553a156c1ca92c309ba94915a059b3ce95

    9ff8c7b78c938d1f8e4d9c648cd0111a6a1a0b59242502001998b664f9d56f63

    a006849de02f2386e6d90fcf1a823177f8281ce328483cbb1f7afac608d1257e

    e7afe0fe53f9d302c472c1d0b77df91bf005554eb876b74e1e4f80d0dfeb6c33

    f68330d92a5eee2f940f22a72f568de82b3ba2c1d73089d5356db1538bdca704


    The df output only references two of these folders and they seem to be the two ending in -init above. The 38698xxx folder has a change date of 7-1-21 and the 4bffc4xxxx folder has a change date of 7-4-21. All of the other folders have a 7-1-21 or 6-29-21 date.


    So my question is "Are all of the folders not referenced in the df output obsolete and should've been deleted to recover the space?"

    I just noticed in the output of the docker inspect plex command that the path shows a colon at the end of Plex. I just checked my shared folder setup and the volumes in the container and I never used a colon at the end of Plex. Is that some kind of error?

    The display of that colon in that location is correct and nothing to worry about.

    --
    Google is your friend and Bob's your uncle!


    OMV AMD64 7.x on headless Chenbro NR12000 1U 1x 8m Quad Core E3-1220 3.1GHz 32GB ECC RAM.

    Any ideas on why I'm running out of space? Specifically, are all those folders dated 6-26 and 7-1 needed or are they leftovers that can be deleted? (see post #16).

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden