Hi All,

Today I used mergerfs to create a pool with two drives, and I created new shares pointing to folders which were already existing.

Everything works quite well except that I receive a constant stream of emails like the one below

The Samba 'panic action' script, /usr/share/samba/panic-action,
was called for PID 48241 ().

This means there was a problem with the program, such as a segfault.
However, the executable could not be found for process 48241.
It may have died unexpectedly, or you may not have permission to debug
the process.

This only happens is a file is deleted via SAMBA.

I used the reset permissions plugin to ensure that the share are 2775 and all existing ACLs are deleted.

unfortunately no success, I'm still receiving the same email.

To me it sounds like a SAMBA vs mergerfs permissions fight but I can't identify the cause.

Any help would be much appreciated.

Regards,

FT

...just an update....

it looks like a permission issues. I update/checked the permissions of my user and the problem seems to have been resolved if I access the SAMBA share from my desktop (KDE/Dolphin)

if I access the same share from my phone - same account-, upon deleting a file I get the same error. so it looks like I managed to fix it from a desktop access but not from a phone access...

unfortunately it didn't work

in the extra options I used the "force user =" option from the SAMBA manual but the behaviour is still the same.

I also tried the options to inherit permissions and ACLs, also that didn't work

I tried forcing the protocol to SMB3 just in case but no success either

I need to investigate this a little bit more. The solutions proposed so far do not work so I want to check if there's something wrong with my configuration. During the weekend I should have some time to try.

Just to emphasize that in my case the problem happened as I deployed mergerfs.

Before this, Samba was working just fine from windows/linux/android.

As I said something may be wrong with my file permissions and ownership.. I need to dig a little deeper.

ok, some more interesting results.

I created two files, both using a SMB client. The first one from an ANDROID phone and the second from my Laptop running Linux accessing the SMB share via Dolphin (I called them Android and Laptop, very original, I know ).

accessing the NAS via CLI I run a STAT command:

stat android.txt
  File: android.txt
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 0,39    Inode: 1319411178793694951  Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/francesco)   Gid: (  100/   users)
Access: 2024-05-18 10:02:14.214778075 +0100
Modify: 2024-05-18 10:02:14.214778075 +0100
Change: 2024-05-18 10:02:14.214778075 +0100
 Birth: -
$ stat laptop.txt
  File: laptop.txt
  Size: 2               Blocks: 8          IO Block: 4096   regular file
Device: 0,39    Inode: 13820027614752166011  Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/francesco)   Gid: (  100/   users)
Access: 2024-05-18 10:02:52.183273757 +0100
Modify: 2024-05-18 10:02:52.232403600 +0100
Change: 2024-05-18 10:02:52.227274332 +0100
 Birth: -

Hence both files are created with the same permissions and ownership

Now, if the files are deleted from the laptop SMB client, or via CLI, no issues. If the files are deleted from the phone we have the panic message.

Next I created a new shared folder outside the mergerfs pool on the system drive.

Same exercise, the two files are created with the same permissions however the problem here is not replicated and everything works as expected.

To me this means that the problem exists on SMB shares created in the mergerfs pool and something between the SMB client, the share and mergerfs is not working right.....

any ideas?

FT

Hi chente,

yes, the shares were created with the method you just described.

I think I just found a workaround which may help identifying the root cause.

I enabled the recycle bin for the shares in the pool. Now it works perfectly again and if I delete the content of the bin form OMV GUI no error messages (so I set it up with an automatic deletion after 24h)

I can only guess that the delete command passed by the android client is somehow different from the delete command from a linux computer.

I have no idea how these could be different but it could be a peculiar configuration of the android client (BTW I tried other 3 apps with the same results but in general the APIs could be the same so....go figure!)

I hope this thread can help other people if they have the same issues (@ Birdybird)

Ok give it a go. Check the options for the smb shares, it's in the same place where you enable the recycle bin.