itimpi

Why not do it he other way around? set up Unraid with the drive(s) you want to keep, and then put the removed drive into the external enclosure to copy its data back to Unraid.

Passing the extended tests is a MUST for assuming a disk is healthy. Other signs of potential problems even is extended tests complete successfully is reallocated sectors starting to increase or Pending sectors being non-zero

That means a flash drive with that GUID has previously been used to register Unraid. This can mean that the manufacturer is not giving each drive a unique GUID What brand was it?

Have you tried using https;//ip_address ?

The only other sensible alternative is the My Servers -login, but the really only gives the ability to remotely access the Unraid GUI. WireGuard is much more flexible and I and in most cases people manage to set it up without any problems. Chances are you have made a mistake in the WireGuard configuration that will be easy to rectify once it has been identified.

In which case I suggest you post in the WireGuard support thread. A screenshot of your WireGuard settings is likely to be of use, plus information on what client you are trying to access from and also what you want to do over the remote connection. Any error messages are also going to be relevant.

Are you trying to get remote access working using the My Servers plugin or by using the WireGuard VPN built into Unraid?

Normally CRC errors (which are connection related ones) are recovered automatically by retrying. Occasional ones are not really a cause for concern but if they are happening more frequently then they might need looking into. Commonest cause is cabling (power or SATA) but other possibilities exist. Note the value never gets reset to 0 so the aim is to stop it increasing.

Looks like disk1 is in a very sorry state with lots of reallocated sectors and pending sectors. You are also getting lots of I/O errors on the drive.

What you describe is not a standard part of Unraid. Mover makes the assumption that a file only exists in one place, and will not overwrite a file that already exists on the array when trying to move files off the cache. some people have written custom scripts to what you describe. They exploit the fact that if a file exists in 2 locations under Unraid then copies on pools take precedence over a copy on the array (and pools are used in alphabetical order). However it is then up to the end-user to manage any corner cases or unexpected behaviour.

Your appdata, system and domains shares exist on multiple array disks so if you run any docker containers or VMs these are probably keeping files open on the array. Normally you only want these shares on the cache to optimise performance and minimise array access.

The format is irrelevant other that reiserfs doesn’t not handle disks getting very full very well (as well as being deprecated for new drives).

I actually do something similar except I do a full shutdown rather than putting the server to sleep. I then have a setting in the BIOS to power the server on again in the morning. Is there any reason you want to do a sleep rather than a full shutdown?

I have never had bit rot in the 10 years or so that I have used Unraid as far as I can tell so I certainly do not think it is common. However, I HAVE installed the file integrity plugin so if it does occur it will hopefully be detected. I prefer to stick with XfS for the main array as being more robust and probably more performant.

Did you make sure that files did not already exist? The setting only applies to new files. Depending on the Unraid release you are running a bug may also need to stop/restart the array to activate the change.

Every feature added to Unraid adds cost from a development and testing prospective so a trade-off has to be made. Since btrfs is provided as standard and already includes bit rot protection that is probably deemed sufficient.

In my experience bit rot is very rare. If you are really concerned about bit rot then you can use btrfs as the file system on the array disks as btrfs has automatic built-in bit rot detection. The alternative is to use XFS (which I find more resilient) in conjunction with the file integrity plugin.

Not that I know off. The way to handle this will be: make sure you have notifications enabled so you can get an email if a drive fails set up secure remote access using either My Servers plugin or using WireGuard VPN built into Unraid. That gives you the ability to monitor and control the server remotely.

If you have Use Cache:Prefer then that indicates that you do NOT want it put on the array, but only on the ‘cache’ pool. If you want it initially on the cache and later moved to the array you need to use the Yes setting. With the Prefer setting it does not matter whether you use /mnt/user/appdata or /mnt/cache/appdata as they are just end up being different views of the same folders/files.

No symlink involved - it is all handled internally within the Unraid level using a Fuse file system overlaid onto the physical drives.

/mnt/user/sharename includes the ‘sharename’ folder regardless of the drive they exist on. They are therefore just different views of the same content.

There had to be something wrong in the steps you did as /mnt/user/appdata/sonarr will work regardless of the drives the ‘sonarr’ folder exists on. You should not have had to update the container settings if it referenced a ‘mnt/user’ type path.

If you go into the plugins settings (under Settings->Scheduler) there is an option to set the logging level. The most verbose one is Testing. The output of that is specifically designed to give the developer (me) lots of details of what is happening. Under the Testing level you can choose whether the plugins log entries should be written to syslog (in RAM), the flash drive, or both. I slightly prefer the output of the syslog option as it tells me more about anything else going on at the Unraid level, but the flash option is probably also sufficient. Note that you do not want to leave that option enabled permanently as being very verbose it can end up filling up available log space.

I managed to recreate what I thought was your issue and correct it. Sounds like there must be another edge case that I missed. if it is possible to have the plugins testing Level of logging enabled and recreate the issue at your end and then let me have the syslog (or diagnostics which includes syslog) to give me more detail on the exact sequence of events that is occurring that may help with pinning it down.

Did you take any action to move existing files to the new cache drive? Simply changing the user share settings is not sufficient as that only applies to new files, not existing ones. The existing ones for a user share will be found regardless of where they reside (array or any pool). my suspicion is when you renamed the folder on the old cache pool that caused a new (empty) Sonarr folder to be created on the new cache pool which is why Sonarr list it’s data. You should be able to get the settings for Sonarr back by moving the contents of the Sonarr1 folder on the old cache Pool to the Sonarr folder on the new cache pool.