Server shares unresponsive after running Mover

[jsteinm1]

I've been trying to use Mover to move some shares off my cache drive so I could upgrade it. I ended up with some duplicate files in both the share and cache drive, so I was manually trying to remove duplicates from the cache drive. I enabled mover logging to see what file it was getting stuck on, and my workflow was like this:

 

Start mover from GUI and watch logs until it stops

terminal: mover stop

terminal: rm /mnt/cache/[file that is stuck]

Start mover from GUI and watch log

 

Not sure if it's relevant, but the share I was working through is docker and the files I was removing were called either fifo or control. Docker is currently disabled.

 

This was working for a while, but after stopping and removing a file, mover wouldn't start from the GUI. I rebooted the server which came back normally, but mover still wouldn't start. Digging more, I've noticed I cannot access /mnt/user in the terminal, but I can access /mnt/diskX or /mnt/cache and see files. I tried to run a parity check but get the same issue as mover - it won't start. The GUI just hangs after clicking the button.

 

I tried to grab a diagnostics zip file, but that has been running for about 30-45 mins and hasn't completed (it did start and show progress, not sure if it takes that long to run or not).

 

I'm a bit out of my depth here with recovery and don't want to make the situation worse. Currently running version 6.12.3

[Squid]

Diagnostics shouldn't take that long.   Pretty much if any request in the GUI doesn't complete with 120 seconds it will never look like it did complete.

 

But diagnostics will have completed and a zip file would have been stored within the logs folder on the flash drive.   Reply back with that file

[jsteinm1]

1 hour ago, Squid said:

Diagnostics shouldn't take that long.   Pretty much if any request in the GUI doesn't complete with 120 seconds it will never look like it did complete.

 

But diagnostics will have completed and a zip file would have been stored within the logs folder on the flash drive.   Reply back with that file

 

ah good deal, here it is

 

edit: looking at it closer this is yesterdays, I had an unclean shutdown that generated a log file (the issue occured after using the server for a while after the unclean shutdown, it was normal for a bit so I don't think this was the cause). I'm running diagnostics from the cli and will try to get a current one

 

edit2: cli just sits on Starting diagnostics collection...., I grabbed var/log/syslog which is attached. If there's anything else I can grab manually that might help let me know where to looksyslog-20230707.txt

unraid1-diagnostics-20230906-2038.zip

syslog-20230707.zip

Edited September 8, 2023 by jsteinm1