itimpi

The process is covered here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

The stop file is called after the array has been stopped so should satisfy the requirement.

If the repair has been completely successful then you do not end up with a lost+foundfolder. have you tried stopping the array and restarting in normal mode. I would expect that you will now get a successful mount.

Strange - it is for me. Not sure what is different I would suggest for you using the Krusader docker container is probably the easiest way to go - that should always be fast.

It should not if the source and target are both on the same drive. For me such moves are almost instantaneous. What is the OS on the client doing the move - maybe it does not support server side moves? You could also use Midnight Commander (mc) or the Krusade.r docker running directly on the server.

Why not set up Games, Videos and Software shares with Use Cache set to Yes. This means that initially all files are on the cache and then get moved to the correct drive on the array when mover runs overnight.

The licence is tied to the USB drive, not the server hardware, so you can simply boot the new server off your existing USB drive and then go through the standard process for upgrading the licence.

Lets hope it works as planned It will be nice to get some confirmations that it works OK outside my test environments.

Maybe it should be Buttons (plural)?

Mover will only move files from cache to array if you have Use Cache:Yes set. It ignores shares with Use Cache:No (or Only). Turn on the help in the GUI to get more information on this setting.

Looks like you have the mapping of the config folder wrong? I would expect to see something like: -v /home/amule/.aMuleI:/mnt/appdata/amule as the mapping of the configuration folder internal to the container to a folder at the Unraid level that is external to the container.

Technically you can use any option as long as you end up with the desired assignments before starting the array. My normal recommendation is to start by preserving all, and then making any necessary changes before attempting to start the array as that is least prone to user error.

It is not normally recommended to have USB disks in the main array as if they disconnect for any reason and then reconnect with a different Id then Unraid will not handle this. If this is only happening for you on a spindown/spinup sequence then you may get away with having it in the array if you disable spindown for that drive.

The chances are that if you start multiple array operations at the same time you will get contention for the drives which slows them down and that the elapsed time could easily be more than doing them one at a time.

If you want to get in as early as possible during startup and as late as possible during shutdown then the best place for this would be the config/go and config/stop script files (the latter does not exist by default and would need creating) on the flash drive. Slightly easier (but needing more of Unraid running) is via the User Scripts plugin.

It looks as if disk15 was reformatted at some point as it appears to be basically empty. The diagnostics appear to be just after booting so cannot tell much else from them. Was there any chance that when you added the new disk23 that disk15 was showing as unmountable (due to file system level corruption) so when you tired to format disk23 you did not check that was showing as the only disk to be formatted so you also accidentally formatted disk15 as well? It is possible a disk recovery such as UFS Explorer on Windows could recover much of the deleted data. You have to decide if this is worthwhile or if it is easier to recover the data from your backups or via some other method.

You need 4GB to get Unraid to load and run properly. If you run docker containers and/or VMs under Unraid then add their requirements on top of this.

It is quite normal form the device name to change if a drive disconnects and then reconnects as the sdX type names are assigned dynamically at the Linux level, so you can never assume they stay constant (this is one of the reasons Unraid identifies drives by their serial number and not the sdX type device Id). This will cause problems if the USB drive is used in the array as the core Unraid system is not hot-plug compatible but if the disk is being used as a Unassigned Devices then the UD plugin should handle this OK.

I hope you mean Apps -> Previous Apps to avoid having to reconfigure the containers?

Just tried it myself and got same results so I can look at why. Well timed report as I was just about to make a new release with (amongst other changes) fixes to make the plugin compatible with changes at the core Unraid level I have been told about that will affect the plugin and that are coming in 6.10.0 rc3. EDIT: Found the bug (a misnamed variable in my code). Effect was that the Settings would always display "No", but rest of plugin would always act as if it was set to "Yes".

As far as I know there will be no way to recover the data without the encryption key. One of the downsides of using encryption.

It 9s really up to you. As you are using a new drive the good thing is that you will still have the old drive available just in case anything goes wrong with the rebuild, so keep it intact until you are happy the rebuild worked as expected. Preclear is NEVER required with Unraid. The only real reason to use it is to act as a stress test of the drive before adding it to the array.

FYI: the diagnostics includes the syslog so it does not need posting separately.

Yes for disk19. As @trurl mentioned you need to work out if you have any residual hardware problems. The process for recovering disabled disks is covered here in the online documentations accessible via the ‘Manual’ link at the bottom of the GUI.

You get entries in the lost+found folder when the repair process cannot find a directory entry to give the correct name. Since the sub-folders have recognisable names you should be able to sort out the original path.