2nd Union FS not visible in Shared Folders

  • I'm in the middle of migration to OMV and stuck with the following problem.
    1st Union FS was created earlier and works properly.
    2nd Union FS was just created with 2 new disks, it looks the same as the 1st one, however I cannot create a Shared Folder on the 2nd FS: "Device" in "Add shared folder" dialog shows the 1st FS twice and 2nd FS is not visible at all. Desperately need help ;)

    Edit: if I will create a sample share using the 2nd (duplicate) device name, this new share will be created with the correct absolute path (associated with the 2nd UnionFS instance) but it will be displayed with the wrong device name.
    I need to proceed with the file restoration but this situation is holding me.

  • I tried to reproduce this, but couldn't. As the screen capture below indicates, there are 2 Union drives with individual shares set on each. They were set up in a normal order, with Union1 and the share Documents1 being created before moving onto the second Union drive and second (Documents2) share.

    The drop down for shared folders show both Union drives with their correct device names.
    This was done in OMV 4.1.17-1 with the UnionFS plugin 4.0.2

  • Odd things happen.

    I'd give thought to deleting the 2nd UnionFS mount point, wiping drives /dev/sdc and /dev/sdd, reformatting them (I'm assuming that you're using something like EXT4) and try it again. (Be patient - wait for the yellow confirmation banner before moving on to the next "create" step.)

  • Wiping those disks is problematic for me as they keep the primary copy of my backup.
    What I tried:
    - deleted the 1st UnionFS instance ("transfer")
    - unmounted both disks
    - rebooted
    - mounted disks
    - created UnionFS under different name ("union2")

    Now I see that the another old name - "vol1" - is duplicated and "union2" is not visible in the Shared Folder at all.
    Since I already managed to restore my files to a larger UnionFS ("vol1") I can now completely get rid of the 2nd UnionFS instance and smaller disks.
    However I suppose that this is a bug which needs to be further investigated and fixed. Thanks!

  • I suppose that this is a bug which needs to be further investigated and fixed.

    To be a bug, the issue would have to be reproduceable. That doesn't appear to be the case. While this may not be the best news, something may be going on with your install. (Maybe the UnionFS plugin?)

    Would I worry about it? Not necessarily. If you're running a single UnionFS mount point, whatever is going on doesn't seem to affect it. But, if you're not doing it currently, you might consider OS backup. If/when odd issues like this crop up, it's nice to a fallback option.

  • To keep the sequence as close as possible to real world, I deleted the second shared folder and the 2nd UnionFS mount point.Then I updated all packages to the latest, which included mergerfs 2.27.1 (the UnionFS plugin is based on mergerfs) - with a reboot to insure the updates are in effect.

    When creating the 2nd UnionFS mount (Union2) and the Documents share (Documents2), everything is still the same as it was in the screen capture above.

  • Solved!
    Somehow my issue was related to 2 disks /dev/sdc1 & /dev/sdd1 initially included into 'transfer' UnionFS. Replaced them with 2 other disks, created new UnionFS and no more problems. Have no idea what was wrong with them.
    Many thanks to @crashtest for looking into the issue.

  • I was having this exact problem. For me this may have had something to do with my disk labels?

    sdba -> disk1
    sdbb -> disk2
    sdbc -> another1
    sdbd -> another2

    $ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sde1        55G  3.7G   49G   8% /
    1:2             3.6T  2.0T  1.7T  55% /srv/4225

    Once I updated c and d disk labels the unionfs showed up in shared and I could see the union in df

    sdbc -> anotherA
    sdbd -> anotherB

    $ df -h
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/sde1        55G  3.7G   49G   8% /
    1:2             3.6T  2.0T  1.7T  55% /srv/4225
    A:B              19T  1.7T   17T  10% /srv/132a

    Concatenated the df output but hopefully you get the picture. It also could have just been because I recreated the filesystems, etc on the 2nd go around

Participate now!

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