How does Union Filesystem work with SnapRaid and Samba exactly? Why am I not able to copy on commandline to Union sharedfolder?

I have a setup with snapraid and union filesystems, the latter beeing mergerfs by default as far as I know.

I have three disks in my snapraid, one beeing parity. With the two data disks I set up a union filesystem.

I set up a shared folder pointing to the union filesystem.

This results in an entry /sharedfolders/Union. However, if I copy something to this folder with midnight commander it is not copied to the union filesystem but to the mountpoint on the system SSD. It does work when copying over samba, though. On the other hand I have other entries in /sharedfolders which are also samba shares and those are mountpoints which I also can use on the command line.

If I copy something to the /sharedfolders/Union folder it will be copied to the local system disk because there is nothing mounted at this mountpoint. But if I access this via samba from a client it works as expected, copying the stuff to the union filesystem.

If I want to use the union over the terminal I have to copy to /srv/333d269a-8fbc-4994-b2d0-af41e84909b2/Union. It then seems to work as expected, putting the files on the drive with the most free space.

On the other hand I see the file snapraid.parity with 10TB of size in /srv/333d269a-8fbc-4994-b2d0-af41e84909b2 (the union mount) which is odd, because this parity file is located on the parity disk which I did NOT include in the union filesystem. How does it go there? Does snapraid automatically put a link to it on every disk?

Can someone please explain this behaviur?

Well my system is working fine apart from this issue. But you might be right that I might have manually edited the /etc/fstab before. It is already good to know that your think that the mountpoint should normally work the way I expeced it to.

Well, but you probably have a samba share related to it, no? If so, you might check if you are able to copy something via the command line to that share's mountpoint or if it is just possible to copy it to /srv/... Would be interesting.

Zitat

Except locally. Then I might use either the /srv/nfs/someshare path or the /svr/crazypath/someshare path.

That's my point. Maybe it is natural, that on the server itself it is not possible to access the mergerfs filesystem via the /sharedfolders/Union path.

No, that was a mistake, sorry. Changed it to 4.x.

I also had the wrong disk in the Union, which explaines the error the parity file. Sorry for the confusion, which arose from the fact that in SnapRaid I had set up the parity in the first disk which was odd for me.

I double-checked it again:

/sharedfolder/Union does not show any content (because it seems not to be mounted to the actual UnionFS) from the command line.

But the samba share that uses this exact shared folder Union [on Union, Union/] works as expected, shows content and is mounted when accessed from a client.

Maybe someone can at least confirm this.

Zitat von gderf

Try removing the Union sharedfolder (but not the content) and create it again. Use the name of Union and the directory of the unionfs mount point.

That worked! Thanks a lot!

gderf

After shutdown by autoshutdown, the /sharedfolders/Union is again not mounted.

My /etc/fstab looks like this:

# >>> [openmediavault]
/dev/disk/by-label/Barac /srv/dev-disk-by-label-Barac ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/dev/disk/by-label/Barac2 /srv/dev-disk-by-label-Barac2 ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/dev/disk/by-label/3TB01 /srv/dev-disk-by-label-3TB01 ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
/dev/disk/by-label/BenRAID6 /srv/dev-disk-by-label-BenRAID6 ext4 defaults,nofail,user_xattr,noexec,usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,acl 0 2
//192.168.100.90/hgst/HGST /srv/6e1d9c6a-b7fa-4008-9b27-bc1c5f07bf49 cifs credentials=/root/.cifscredentials-f103d6d5-714a-46ea-8638-d4729bc532a7,_netdev,iocharset=utf8,vers=2.0,nofail 0 0
/srv/dev-disk-by-label-3TB01:/srv/dev-disk-by-label-Barac2 /srv/333d269a-8fbc-4994-b2d0-af41e84909b2 fuse.mergerfs defaults,allow_other,direct_io,use_ino,category.create=mfs,minfreespace=4G 0 0
# <<< [openmediavault]

The share is in config.xml:

<sharedfolder>
<uuid>2ce306c6-18a4-42c5-8aa9-0a39dcbdcfe2</uuid>
<name>Union</name>
<comment></comment>
<mntentref>0f4544d6-0edc-4c36-bd96-d493e9bc1f5d</mntentref>
<reldirpath>Union/</reldirpath>
<privileges></privileges>
</sharedfolder>
</shares>

Maybe it is not mounted on startup because some other mount takes too long?

Found a thread relating to this: MergerFS folders not mounted in /sharedfolders

I solved the problem with a workaround that seems to be standard in higher versions of OMV than mine:

Adding x-systemd.requires to the options for the union filesystem from the plugin window. So for my union of two disks the options are

defaults,allow_other,use_ino,category.search=newest,x-systemd.requires=/srv/dev-disk-by-label-HDD1,x-systemd.requires=/srv/dev-disk-by-label-HDD2

The only thing I now have to remember is to add this for each new disc of the union. I suggest putting a comment into /etc/fstab to remember this.