itimpi

Your description makes it sound as if it could be the NVME after all that is limiting speed. Have you done local speed tests on it?

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread. It is always a good idea to do this to allow us to see the current state of your system and so we can see logs and configuration information.

Something strange going on as the times in the syslog file in the diagnostics precede those in the syslog_previous file which should not be possible. I suggest you reboot the server and then post new diagnostics if the problem is still occurring.

It can as mentioned in the link by using the ‘diagnostics’ command.

If you can ssh in then you can both reset the GUI and initiate a powerdown. You can then (probably more important) also collect the diagnostics to help with identifying you had the problem in the first place. The powerdown can be initiated via the 'powerdown' command. I do not have the command to reset the GUI to hand but you should be able to find it by googling or someone else could answer here. You can normally also initiate a shutdown by a quick press on the power button.

Never heard of a problem like that using the built-in file manager. Difficult to see how it happened as source files should not be removed until destination file has successfully been created. Having said that your syslog is full of hundreds of messages of the form: Jun 27 13:26:15 NAS nginx: 2026/06/27 13:26:15 [alert] 13542#13542: worker process 160061 exited on signal 6 Jun 27 13:26:15 NAS nginx: 2026/06/27 13:26:15 [alert] 13542#13542: worker process 160121 exited on signal 6 Jun 27 13:26:16 NAS nginx: 2026/06/27 13:26:16 [alert] 13542#13542: worker process 160122 exited on signal 6 Jun 27 13:26:17 NAS nginx: 2026/06/27 13:26:17 [alert] 13542#13542: worker process 160129 exited on signal 6 which I assume must relate to the issue you saw, but I am not sure how.

Looks like it is having trouble reading the flash drive. I suggest you try putting the flash drive into a PC and see if it can be read there. If it can then I suggest downloading a zip copy of the Unraid release and extract all the bz* type files overwriting the ones in the root of the las drive as this sometimes fixes the type of issues you are seeing.

No setting as far as I am aware. Unraid is not hot-plug aware so cannot handle drives dropping offline that are part of the main array or a pool. Only Unassigned Devices can be handled like that.

They will as long as they were installed via the Unraid Apps tab. When you install containers in that way the settings are stored in an XML template on the flash drive and that is used by the Apps->Previous Apps option. If you install containers in another way then you have to remember the settings used.

Recreating the docker.img file is normally quite trivial as you can use Apps->Previous apps to reinstall containers using their previous settings.

I seem to remember it being possible to get to this state if the second stage of the boot process where the flash drive is mounted at /boot does not succeed? The output from the ‘df’ command after logging in at the prompt would make it clear if this is the case.

The syslog in the diagnostics definitely shows that Unraid thought an unclean shutdown had occurred and as a result a parity check was initiated. Note that you will get an unclean shutdown if the timers controlling disk unmounting expires, or if for any reason Unraid is unable to write to the flash drive the fact that it has been able to do a clean shutdown. The syslog-previous in the diagnostics shows that it was the disk timeout expiring before the array could be tidily stopped that caused the unclean shutdown: Jun 25 02:01:32 Corellia emhttpd: shcmd (55137): umount /mnt/cache Jun 25 02:01:32 Corellia root: umount: /mnt/cache: target is busy. Jun 25 02:01:32 Corellia emhttpd: shcmd (55137): exit status: 32 Jun 25 02:01:32 Corellia emhttpd: Retry unmounting disk share(s)... Jun 25 02:01:34 Corellia rc.local_shutdown: Forcing shutdown...

Ok. I interpreted the original question from OP as implying he thought that Unraid had a standard location for the encryption key which is not the case. Historically one has added something to the config/go file that got the encryption key from somewhere.

That is a plugin so any questions regarding it should be asked in the plugins support thread.

Not quite sure what you mean? If you are talking about the encryption key then Unraid has no built-in location for it regardless of whether internal boot is being used or not.

This implies you forgot to hit the Apply button during the New Config. After doing that all drives should end up with blue icons.

When you replace an emulated disk and it is rebuilt then whatever was showing on the emulated disk before the rebuild is what will appear on the physical disk after the rebuild. No need, therefore, to copy the existing contents elsewhere first unless you want to protect against the rebuild failing for some reason.

The one you are using is based on an ASM1061/1062 chip so it is using port multipliers to give you 4 ports.. Ones with a similar description and based on the ASM1064 chip do not used port multipliers so maybe that was not made clear when you were researching.

It still works for me. I have 2 docker instances set up - one for music and one for audiobooks. I do think it is a shame that they never improved the audiobook support as I find too many quirks to use it regularly. The music side is better although it could also be improved. Not quite sure what that error message means, but I think it may be something to do with connecting to your Amazon account.

It looks like the cache_nvme pool is not being seen. Have you tried power-cycling the server (rather than just rebooting) to see if it is then seen?

It should not be necessary as the mirror to flash option was set and with that the syslog-previous is automatically included in the diagnostics. Having said that the 'mirror to flash' option does put some extra wear on the flash drive so it is best not to leave it set if you are not investigating a current problem.

That is the correct file. It is probably worth disabling bonding under Settings->Network as you only seem to have a single NIC, although I do not believe that explains your issue. I see your server is using a 10.33.x.x subnet - is that the same subnet your router uses? You might want to check that the gateway address is set correctly to point to your router using the command ip route show default from the command line.

You cannot change the file system used by an array drive using a rebuild - the rebuild always rebuilds the original file system. You first have to empty a drive of any data you want to keep after which you can then reformat the drive to a different file system (which only take a few minutes). You may then need to copy the data back. Parity stays valid throughout so only having a single parity drive is not an issue. This is akin to the process used to migrate from reiserfs to xfs in the array, but it is very time consuming. Whether you want to do this is up to you. As you said having zfs is not recommended in the array as zfs format in the main array does not perform well and the normal zfs recovery mechanisms available to redundant zfs pools are not available due to each arrays drive being a free-standing file system. Normally you only want zfs in the main array (if at all) to make a drive capable of receiving zfs snapshots.

You are likely to get more informed feedback if you attach your system's diagnostics zip file to your next post in this thread. It is always a good idea to do this to allow us to see the current state of your system and so we can see logs and configuration information.

That seems a reasonable time. I normally expect it to take something between 1 and 1.5 hours per TB (these operations on modern large disks take a long time😃). Good indication of disk health that it completed without errors.