itimpi

Getting a 169.254.x.x address indicates a networking problem of some sort.

It is documented here in the official documentation.

Do NOT format it unless you want to lose its contents. You might want to read this section of the official documentation. If a disk shows as unmountable before doing a rebuild then it will always show the same after a rebuild. The way to clear an ‘unmountable’ status is to run the appropriate file system repair tool.

Assuming the laptop is in the same location as it was the previous night then the fact you have remotely connected to it should not affect what you can do on the laptop.

Regarding the USB flash drive, then you do not need a high-speed drive. In fact USB 2 drives are recommended as they tend to be more reliable. Every time Unraid boots it installs itself into RAM from the archives kept on the flash drive (in this sense it is rather like firmware) so a faster drive might gain a few seconds during the boot but nothing measurable after that. The flash drive also stores your licence and your configuration information but these files are very small so again speed is irrelevant.

That is an app that is known to create all the target folders at the start of the copy which can result in exactly this sort of issue if your split level is too restrictive so that files are forced to the disk whish has their containing folder.

After doing the New Config and returning to the Main tab to unassign disk 2 did you then start the array to commit the change and start rebuilding parity? Simply removing the disk is not sufficient as Unraid would just treat this as a missing/failed disk scenario.

The problem is almost certainly the Split Level setting. In the event of there being contention between the different setting on the share about which disk to select for a file then Split Level always wins. also, how are you copying the files. Some methods will create all the folders first.

You should provide your system diagnostics zip file (obtained via Tools >> Diagnostics) attached to your next post do we can get a better idea of your setup. my guess is that you have a value for the Split Level setting for a share that has existing content on Disk 2 that is forcing Unraid to continue trying to use the drive, but without the diagnostics and the path for the files you do not want to go to disk 2 that is pure speculation. In the event of contention between the various share settings for selecting a drive then Split Level always wins.

You also want to check the Split Level setting for the shares in question. If there is contention between the various share settings for choosing a disk for a new file then the Split Level setting always wins. Having a too restrictive value can make Unraid try to write a new file to a disk that does not have enough space for it.

If you want any useful feedback you need to provide your system’s diagnostics zip file (obtained via Tools >> Diagnostics) attached to your next post in this thread.

Many motherboards are more likely to have RAM errors if all the slots are populated. The only acceptable result from memtest is 0 errors reported.

This is due to a ‘feature’ of the underlying Linux where if it thinks source and target of a ‘mv’ operation are on the same mount point it first tries a ‘rename’ (for speed) and only if that fails does a copy/delete operation.

Unraid can use either and defaults to http but this can be changed in the Unraid settings. Setting Unraid up to use https requires some additional steps as you have to acquire a SSL certificate to allow https to be used (not difficult, but extra setup work). Whether you bother depends on how secure you think the environment where the UnRAID server is located actually is. If it is only ever accessed on your home LAN then http may be sufficient.

Assigning the GPU to a VM DOES make it unavailable for any other use while the VM is running as the VM will have dedicated use of the GPU. As a general principle any resource assigned to a VM is not available for any other use while the VM is actively running.

Did you ever try to enable mover logging to see what files were being moved?

You should post you site diagnostics zip file (obtained via Tools >> Diagnostics) so we can get a better idea of what is going on. my initial thought would be to remove all existing partitions from the drives before trying to use them with Unraid. Unraid wants a very specific partition layout and it sounds as if for some unknown reason it is having trouble partitioning the drives as it wants them.

That is expected behaviour with the High-Water allocation method set on the share. You might find this link useful in clarifying how that works.

If using a vdisk then the Pass thru option should NOT be checked. You only use that option when the VM has complete control of the whole physical drive.

FYI: You can attach the diagnostics directly to you forum posts. Many people will not look at them if they are posted to an external site. You say 2 disks were giving errors - if so which ones? Nothing sprung out to me to say which ones from the posted diagnostics.

Not a direct answer to your question, but have you tried using the WireGuard VPN capability that is built into 6.8.3 or later? It has the advantage that it can access Unraid even when the array is not started as it runs as a system level service. i actually have both WireGuard and the OpenVPN-as docker container installed on my server so that if I make a change remotely that breaks one of them I can then get in via the other option to fix it. Regarding your openvpn setup which version are you using when you run it on Unraid? A plugin version or one of the Docker container versions? IT is very strange, though, that with the router running it you cannot access Unraid when other devices on the Lan are reachable.

The Minimum free space setting applies to individual files, not the total size of the content of a folder. in your example the folder contents would end up spilt across two drives as Unraid would switch to using the other drive for further files once the free space dropped below the minimum free space.

Those are not the normal permissions for an Unraid system. You normally expect to see the user/group to be nobody/users and not root/root. It sounds as if you copied the files/folders using a tool local to the Unraid server that has not set the standard permissions. Having them set to root/root will stop any access via the network working correctly. The permissions can be corrected by running Tools>>New permissions against the share in question.

No.

It might be worth enabling mover logging? If mover is getting involved then the filenames are likely to give you a clue as to what is causing this. Most people only run mover once a day overnight in a quiet period (which is the default setting) I assume you had a reason to change the frequency?