Beiträge von SonOfThor

    No, I did not get any explanation - and I am just as curious. My hypothesis is that my Docker container was given a wrong path, hence it made a path on / instead on the mount point in my MergerFS pool - this filled up my drive. When I deleted files/folders and removed the containers/Docker images as well as uninstalled Docker using the plugin - something was still occupied by a service and the data allocated to the disk was still occupied ...
    LSOF did not help me, so if there was a service keeping this "shadow" folder active I could not find it. Weird.

    I have managed to solve the problem. It seems that some hidden files and folders were present. I posted the problem on the Debian forum and got an answer. Wanted to post the solution here so that other user could troubleshoot "the same problem" using the same approach.


    You need to Mount bind the root ( /) to another mount point. First create the folder mnt:


    Code
    mkdir /mnt


    Then mount bind the root to /mnt


    Code
    mount --bind / /mnt

    Then perform:

    Code
    du -h --max-depth=1 /mnt


    I then found that there was another folder called sharedfolders with lot of files and folders, only visible upon doing a mount bind.
    After removing them on the new mount point i performed:

    Code
    umount /mnt


    Files and folders are now gone and space on the disk is back!


    Thanks to everyone who provided help and suggestions!

    I have added two more disks and the disk "names" have changed from the first post.


    sdg1 is now the SSD. I understand that was confusing.

    Code
    root@OMV:/# lsof +L1
    COMMAND     PID                  USER   FD   TYPE DEVICE SIZE/OFF NLINK   NODE NAME
    php-fpm7. 17624                  root    3u   REG   0,40        0     0 918917 /tmp/.ZendSem.mUQiM7 (deleted)
    php-fpm7. 17625              www-data    3u   REG   0,40        0     0 918917 /tmp/.ZendSem.mUQiM7 (deleted)
    php-fpm7. 17626              www-data    3u   REG   0,40        0     0 918917 /tmp/.ZendSem.mUQiM7 (deleted)

    Found some deleted files still being kept "open". These might be a problem. Not sure how I will tackle this further though. Have tried to perform kill -9 PID (e.g. kill -9 17624, but this did not help)

    The more likely scenario is something writing to a mount point with no drive mounted to that mountpoint. When the drive is eventually mounted, the contents of the drive will appear in the mount point directory and what was previously written in the directory will not be visible but is still present and taking up space on the rootfs.
    So, it is best to check by first unmounting the drive, then looking in the mount point directory. It should be empty.


    Reply being delayed because it is wrongly being held for moderation.

    This seems like a potential cause.
    I did see at some point thought my docker container Sabnzbd to store data on my OS-disk. This was caused by the data point being pointed erroneously in the docker container (to a mount point/folder in my MergerFS pool). I corrected the path but it did not make a difference. I did uninstall Docker and all the containers, but it did not make a difference. I though this was not the cause - maybe it was.
    Could it be that the data stored by the containers was not deleted on the disk and is therefore taking up space even though you can not identify that by du or ncdu command?


    If data from "ghost" containers still takes up space on the rootfs, how can it be removed?

    Code
    root@OMV:/# df -h /dev/sdg1
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sdg1        91G   49G   38G  57% /


    ncdu -x


    So, using ncdu, what is making up 49GB on my drive?

    I still have not managed to identify the files that are filling up my OS-disk.


    As a result I have had to boot to GParted and adjust my partitions twice now. If this continues I will run out of space on the disk.


    Does anyone have an idea of what I can do next? Would it be advisable to address this issue on the Debian forum, since OMV is based on Debian?

    See what you can find under /var/lib/docker The sub-dir /containers might have something interesting.

    I have un-installed docker, so there is no docker folder.



    As you've noted, Linux has hidden folders and files. While I don't think this will be productive, the following will list all hidden folders.
    find / -type d -iname ".*" -ls
    The following is for all hidden files.
    find / -type f -iname ".*" -ls


    After running the du -hxd1, which from my understanding will include hidden files, I still can not identify files or folders to occupy 39 GB of data. See my first post.


    Here is the suggested find command:



    Hi.
    I have not spent two days searching for an answer in this and other forums, but have not managed to find a solution. Now I am desperate. :S


    I have a system with a 120 GB SSD drive were OMV has allocated 40 GB space (/dev/sde1).
    The system also contain 6 drives in a Snapraid configuration.


    After installing dockers and setting up a few containers I got a notification a few days ago that the OS disk was getting full, 89%.
    To me it seems that one or a few of the containers filled up the OS drive.
    Also, it seems I might have set up one or more folders erroneously, not pointing to the Snapraid pool of disks, which might have contributed to the problem that data got stored on the OS drive.
    I decided to delete the containers, but this did not solve the problem. I deleted the shared folders that might have been set up erroneously with no changes in disk space.
    I followed up with uninstallation of Docker. Still no solution. Ran rm -r of the suspected folder, files removed, but still no solution. Restart of OMV did not help.


    So, I am stuck. Running df and du has not managed to help me to figure out which folder/file is taking up space on my OS drive after the previous efforts.


    My conclusion: I suspect that somehow containers did take up space, upon deletion of the containers and file/folder, the space on the drive is still occupied but is not visible for the system (or me)? Is this at all possible?


    I need help, please. Alternatively, I have to do a full re-installation of OMV, not a preferred solution.


    Here follows the du and df commands:






    Or this alternative du ...