MergerFS no longer mounting after running without disks

  • I'm posting this for anyone else who might have a similar issue. I figured out the solution in the process of writing the post. It was simple but not at all intuitive.


    Original question:

    Quote

    I recently finished troubleshooting a powersupply issue on my server that was causing random reboots, and now my union filesystem won't mount. I did have to run the system on a different CPU/mobo combo (both ryzen systems, same ram, and put both cpus on both Mobo at various points), and ran for a short time with all data drives disconnected. However, now that the hardware issue is fixed, and all HDD returned to the same exact SATA port as before, with the original mobo/cpu/ram, my union file system refuses to mount.

    Each individual drive is properly mounting (using disk-by-label as before) and the system boots perfectly if I comment out the union file system line from /etc/fstab. at this point im not entirely sure how to proceed. If I try to regenerate the file system using the plug-in it makes the same line in fstab and then the system won't boot.

    Is there any sort of clean up that should be performed on the individual drives to repair this issue? What logs or files should I provide here to help with troubleshooting?

    Solution:

    While the system was running with the data drives removed (and thus the union file system unmounted) my docker containers had been running and one of them automatically generated folders in the /srv/[filesystem] mount point on my home drive. These folders were preventing the file system from mounting properly.

    hopefully this helps someone avoid 2 weeks of troubleshooting for such a simple fix.

  • Hello!


    I am in the same boat right now, but I do not really understand your solution. I ran my server without drives and after reinstalling the drives I am not able to mount my merged pool. I am also running docker containers pointing to the pool. I deleted the docker files in the mergerfs mount point, but that did not solve the issue. Would you mind to formulate further?


    Thanks in advance!

    Custom mini-ITX build
    Coolcube Mini, Intel Desktop Board DQ77KB, Intel Core i7-3770S, 8 GB DDR3 Ram, 64 GB Trascend mSata SSD (OS), X3 1TB HDD pooled + 1 TB HDD parity

    Dell Optiplex 960 sff (deprecated) - link


    Dell Optiplex FX160 (deprecated) - link


    Two points define a line. Three points define a plane. Four points define a Dorito.


  • […]

    Hello! Well yes I did, but my workaround was quite different. I have backups of my OMV installation. My solution was simply to nuke my OS drive and restore to it using one of the back ups. It was virtually impossible to know which docker container got corrupted after running the server without drives. I made the mistake of running some of the containers on a drive pool, hence the container files where spread across 3 different HDDs.


    So, long story short, if you have a back up of your OS I would recommend just restoring your installation. It was way easier and faster, at least in my case.


    PS: after you restore the OS, please oh please do not forget to connect the data drives before booting into your newly restored OMV. Don't ask me why I am telling you this.

    Custom mini-ITX build
    Coolcube Mini, Intel Desktop Board DQ77KB, Intel Core i7-3770S, 8 GB DDR3 Ram, 64 GB Trascend mSata SSD (OS), X3 1TB HDD pooled + 1 TB HDD parity

    Dell Optiplex 960 sff (deprecated) - link


    Dell Optiplex FX160 (deprecated) - link


    Two points define a line. Three points define a plane. Four points define a Dorito.


Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!