Mover deleted all shares (but not data)?

[sonofdbn]

I'm setting up my second server (6.11.5), and haven't used Mover before. I had set up the share "domains" to "Prefer: vm_nvme" and has set up two VMs. But although there's a ton of spare space on the Nvme SSD, I found the two VM "vdisk1.img" files under "domains" on Disk1 instead of on the SSD.

 

I thought that somehow Mover had run and moved "domains", perhaps before I set up "Prefer: vm_nvme", but it's unlikely because I set up the second VM very recently and way before the scheduled Mover default time of 3:40. Anyway, whatever the cause, I wanted to move the VMs back to the SSD.

 

Doing some reading, I got the impression that Mover would "honour" the Prefer setting and actually move files back from the array to the SSD. (This is contrary to what I had previously thought, which was that Mover only ever moved files in one direction: off the cache pool to the array.) Anyway, I thought no harm in trying - worst that could happen was that Mover did nothing.....

 

So I manually invoked Mover from Settings/Scheduler and nothing seemed to happen. I checked the Main page on the GUI and there wasn't much disk activity (the VMs in total are over 300GB, so any moving wasn't going to be instantaneous). But when I looked at Shares they had all disappeared!

 

 

I should have had at least appdata, domains and isos. Fortunately it looks like the files are where they were previously. Unfortunately I didn't set up the Mover log.

 

What happened and did I do something wrong?

 

 

t2-diagnostics-20230617-2223.zip

[itimpi]

Looking at the syslog in those diagnostics I see this:

Jun 17 22:18:50 T2  emhttpd: shcmd (2956): /usr/local/sbin/mover &> /dev/null &
Jun 17 22:18:50 T2 kernel: shfs[29898]: segfault at 0 ip 000055d7967cb59c sp 0000151246774810 error 4 in shfs[55d7967c9000+c000]
Jun 17 22:18:50 T2 kernel: Code: 48 8b 45 f0 c9 c3 55 48 89 e5 48 83 ec 20 48 89 7d e8 48 89 75 e0 c7 45 fc 00 00 00 00 8b 45 fc 48 63 d0 48 8b 45 e0 48 01 d0 <0f> b6 00 3c 2f 74 4d 8b 05 67 dd 00 00 85 c0 78 39 e8 9e da ff ff

which indicates that the shfs process used to support User Shares immediately crashed when mover started - no idea why.

 

The good news is that restarting the server will get all your shares back as they were.

 

You could manually move the files from the drive on the array on to the pool to bypass mover if needed.

[sonofdbn]

Thankfully, yes, restarting the server got all the shares back.

 

One thing I noticed after rebooting was that although I had shut down the VMs before running Mover, I hadn't stopped the VM service. Could this have caused the shfs crash?

 

I'm a little concerned that something is causing a problem with Mover if I'm going to incorporate it into regular use.

[itimpi]

1 hour ago, sonofdbn said:

One thing I noticed after rebooting was that although I had shut down the VMs before running Mover, I hadn't stopped the VM service. Could this have caused the shfs crash?

It should not as Mover is meant to ignore any files that are open.