Bind mount to "merge" dirs on two drives and share it via smb?

I have two drives mounted on OMV.

Drive 1. contains directory "a", Drive 2. contains directory "b".

I'd like to share these two directories as one smb share "c", so that

/c

/c/a

/c/b

I was thinking about:

• mkdir /srv/c
• mkdir /srv/c/a
• mkdir /srv/c/b

• fstab:
  • /a /srv/c/a none bind 0 0
  • /b /srv/c/b none bind 0 0
• mount -a
• in the GUI
  • create shared folder with "srv/c"
  • create smb share with "srv/c"

As I'm manually dealing with mounts, will this work our could it lead to problem with OMV? Anything to take special care of?

I'm aware with MergerFS the same result could be achieved aswell, however, I'd like to keep more control over the drives and I guess there is no need to introduce an additional filesystem layer for my case.

Quote from gderf

If you create mountpoints in fstab they will be unavailable for selection in the OMV WebGUI.

Thanks for your answer gderf

Would it work if I

• create a shared folder "c" in OMV pointing to /mnt/disk1
• mkdir -p /mnt/disk1/b
• mount --bind /mnt/disk2/b /mnt/disk1/b

This way, OMV shouldn't need to be aware of the bind mount?

I'll give it try. Just thought i ask in case you knew so i could avoid messing up my installation

Tbh, I generally prefer to keep the things as simple as possible. With bind mount Debian already offers all that is needed for a simple "merge", so there's no benefit from having the MergerFS layer on top of that. From this perspective the only "benefit" form using MergerFS in this situation is, the configuration becomes visible in OMV as OMV does not support to do bind mounts. And as the performance costs of MergerFS in my case are small, I decided to go with it.

Thanks guys for your input!

After implemting backup using restic to backup media data on the mergerFS, it seems MergerFS does has negative side effects.

restic is doing deduplication based on a set of criteria of which one is inode, meaning restic is usging inodes to track for changes. Now mergerFS does create dynamic inodes, meaning they can change and are not reflecting the static inodes of a physical storage device. This breaks restic's ability to correctly detect changes, in my case it even led restic to fail during backup.

As it run without failures for a certain time, i can not say what is triggering the changing inodes - it might be there is some caching of the dynamic inodes used by mergerFS.

However, I'd say bottom line is: Don't use mergerFS with backup software using dedup and inode surveillance. "Merging" physical disk with bind mount, even if not supported by OMV, might be the better choice.