itimpi

I am not familiar with vaultwarden and t is possible everything is stored under the /data location within the container, but this is slightly unusual as for mist containers there is a separate location where configuration information is stored. You might want to check as otherwise this information is being stored internally within the container inside the docker.img file whereas you really want it stored externally on the host.

The SMART entries in the syslog occur when Unraid thinks the drive has been spun up having previously been spun down.

I am not sure that anyone has managed to reproduce your symptoms. I know that it does not cause what you describe on my systems. Not saying you do not have a problem, but hard to troubleshoot or fix if it cannot be reproduced.

Yes - anything that shows up as /data inside the container is in the appdata/vaultwarden folder. Normally I would expect there to be another mapping for vaultwarden configuration data.

Normally only the binaries for a container are stored in the docker.img file. If correctly configured any working files should be mapped to a location on the host, and by convention this is normally a location under the 'appdata' share. Since it is very easy to restore the binaries and their associated settings via Apps->Previous Apps it is the appdata location files you need to have backed up. Yes - they are all different views of the same file and no symlink is involved. You might want to read up on how User Shares work in the the online documentation accessible via the Manual link at the bottom of the Unraid GUI. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. The Unraid OS->Manual section covers most aspects of the current Unraid release.

I would suggest posting your system's diagnostics zip file so we can see what is going on as the system loads.

New config is when you want to unset all current assignments and then redo them. Not what you are doing in this case.

This topic is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

The diagnostics certainly suggest that all the array drives are empty. Unfortunately we cannot see what happened before you rebooted as the logs start over on every boot unless you have the syslog server enabled to get persistent logs. Do you have your server exposed to the internet? There have been past instances of what appear to be malicious actors breaking into servers and erasing data. The best chance of recovering data from those drives is to use disk recovery software such as UFS Explorer on Windows which can often recover deleted data.

That is basically the standard procedure for shrinking the array as defined here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. The Unraid OS->Manual section in particular covers most features of the current Unraid release.

The standard is to run the built-in mover on a schedule defined under Settings->Scheduler.

For future reference you might want to enable the syslog server if you want to capture a persistent log that survives a reboot so you can see what was leading up to an unexpected shutdown.

The manual method seems to be far more reliable than the USB Creator tool.

My guess is you have the Dynamix File Manager plugin installed on one server and not the other?

I never succeeded in getting Unraid to run under Hyper-V as I could never find a way to pass the flash drive through to the VM as is needed for Unraid to boot successfully and recognize a licence key. if I now need to run Unraid in a VM on my Windows system I use VirtualBox.

You should read this section of the online documentation accessible via the Manual link at the bottom of the Unraid GUI which has the process for moving files between array and pools. In addition every forum page has a DOCS link at the top and a Documentation link at the bottom. The Unraid OS->Manual section covers most aspects of the current Unraid release.

That is because special action is taken for that case. I think that the /boot location is linked to the /root one as part of the Unraid boot process so they are effectively the same. You should store your own files on the flash drive under the /boot location. Exactly where under there is up to you.

Yes - the shares unexpectedly showing as protected have all their files on disk1 and appdata also has some files there. Note that simply changing the primary storage to a pool and removing the secondary storage does NOT automatically transfer files onto the pool. To get the files into the right location you will need to: stop docker and vm services under settings as these will stop any files they have open from being moved. for the shares you want to only be on a pool set the pool as primary storage and the array as secondary storage. set the mover direction to be array->pool manually run mover from the Main tab to get files moved onto the pool. when mover finishes you can remove the secondary storage=array as it is no longer needed re-enable docker and/or vm services (optional) enable the option to use Exclusive mode shares under Settings->Global share settings. This gives better performance for shares with all files on a pool by by-passing Unraid’s fuse layer for such shares.

they would only show as unprotected if they currently have files/folders on the unprotected storage. My guess is that if you look carefully the ones shown as protected currently have their files on the main array. If you post your system’s diagnostics zip file we would be able to confirm this.

There is a lot to be said for adding data before the parity drive as writes to the array are faster at that point. You are, however, without protection against data drive failure without the parity drive.

You should be able to copy the syslog files without shutting down the syslog server.

Strange - I can see the format attempts in the syslog in the diagnostics. Only thing I can think of is (once all array activity has stopped) have you tried rebooting and then trying the format again in case that is needed? New diagnostics taken after that might show something useful if that does not work.

I think you need to reboot after removing that plugin to reset everything back to standard settings.

Is that splitter a molex->SATA or a SATA->sata? If the latter then that will definitely be a problem,

That shows something is actively configured to issue the shutdown command, so it is not a crash. Have you checked that you have nothing configured to run at that time? Feels like it could be a User Script. One small clue is that is using the ‘powerdown’ command to do this rather than the ‘shutdown’ command. Have you tried looking at something like /etc/cron.d/root to see if it contains an entry for that specific time?