Posts by 2devnull

    Wanted to update this. It appears omv-mkconf backup backup had made a backup underneath the mount point. Not sure how and and why it did that or was allowed to write to the root area instead of the mount point of sde1. Anyway, it is solved now. Will keep a eye on it. Perhaps sde1 got unmounted at some point and when omv-mkconf backup backup ran it wrote to the root disk. Bazaar!

    Try unmounting each of your storage disks and then look in their mount point directories.

    These look suspicious:

    /dev/disk/by-uuid/bcb 7.8G 7.8G 0 100% /var/folder2ram/var/tmp
    /dev/disk/by-uuid/bcb 7.8G 7.8G 0 100% /var/folder2ram/var/spool

    I did the one for Docker and it didn't show anything different after unmounting that filesystem. I too am beginning to suspect something is up with the flash memory plug in (those that show with folder2ram).

    Login via console or ssh and cd /

    Then as root run: du -sh *

    Examine the directory sizes to see which one got filled up.

    This is what I am getting. It doesn't really help me pinpoint the problematic files:

    I am on Stoneburner for my main media system. Long story of why I cannot yet upgrade this one including need for TFTP server, iSCSI targets etc.

    Anyway, this system has been going great and has been rock solid for quite a number of years. However, within the last few months the root filesystem has become 100% filled and I cannot seem be able to locate what is causing it.

    I run Docker with three containers including MythTV and Emby and false media plugin. It has NFS exports also.

    Anyway, as mentioned earlier, it has been running all this great for quite some time but it appears something (perhaps a package update) may have caused this.

    If you can help suggest what I can try next, please let me know.

    Thank you.

    So, before I attempt an upgrade from one version of OMV to the next, I make an exact copy of my current disk, and I do the upgrade on the copy. Also, make sure you (on the copy) uninstall any plugins that do not have a corresponding plugin on the later version version of OMV. Then perform the upgrade on the stripped down copy. If something goes wrong, you can try again on by making another copy of your current install, then attempt the upgrade again on the copy.

    I assume you use 'dd' for this (or clonezilla)? If so, can you provide your command just so I'm not overlooking any extra attributes/properties for it. Thanks.

    Any good docker version alternative that can be used instead? What about something like this guy has done, is it sufficient?

    EDIT: Actually, wouldn't this suffice in OMV 4.x until a plugin is ready?

    I'm happy to stay on Stoneburner as mentioned before, but now that my other OMVs are on 4.x and working well, I would consider upgrading if LIO would be as simple as shown in the last link above.

    I am seeing these:

    root 31958 1272 0 19:46 ? 00:00:00 [mountpoint] <defunct>
    root 31959 1272 0 19:46 ? 00:00:00 [mountpoint] <defunct>
    root 31960 1272 0 19:46 ? 00:00:00 [mountpoint] <defunct>
    root 31961 1272 0 19:46 ? 00:00:00 [mountpoint] <defunct>
    root 31962 1272 0 19:46 ? 00:00:00 [mountpoint] <defunct>
    root 31963 1272 0 19:46 ? 00:00:00 [mountpoint] <defunct>
    root 31964 1272 0 19:46 ? 00:00:00 [mountpoint] <defunct>

    pid 1272 is: /usr/bin/monit -c /etc/monit/monitrc

    which seems to point to this monit file:

    Any ideas why this is happening and how to resolve?