itimpi

If the checks were non-correcting and you get the same number each time then you should run a correcting check (which will also give the same number), and after that subsequent checks should return 0; not possible at this stage to know the original cause.

Have you tried to contact support about this?

No idea why you cannot see that directory, but is there any reason you have not put it in the default location of the 'system' share? Relying on the 'addons' location means it will never work if you have booted in Safe Mode as that location would then not exist. The same applies to the 'appdata' folder which is normally the 'appdata' user share.

Do you know which drives(s) are parity drives? You will only lose data if you accidentally assign a data drive as a parity drive. If you are not sure then follow the procedure documented here in 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. Having said that you say the backups are on an unassigned drive? Even with nothing assigned to the array I think you can still download the Unassigned Devices plugin and then mount such a drive to get at your backups.

You have the Minimum Free Space setting for the 'domains' share at 195GB and none of your drives have that much free space.

Handling of unmountable disks is covered here in 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.

It is not a limitation - it is simply a report. If you run out of space within the image then docker will start misbehaving , although the default size of 20GB is more than enough for the vast majority of users. If while running containers the usage increases and you run out of space this typically means a misconfigured docker container. You can control the size allocated to the image file under Settings->Docker. You can also a directory rather than an image file at all although this is not recommended.

No idea I am afraid. I have never seen this behaviour myself. The command you gave is just reading the Unraid status information so no idea why it might not be correct.

Yes. The size is the amount of parity to be checked. With multiple parity drives they happen in parallel so the size is that of the largest parity drive (if they are different).

Just to emphasise the point many of your shares are set to Use Cache=only which means mover ignores them. That setting a-plies to any new files, not existing ones so any files for these shares that already exist on the array are left there.

I do not think we know too much about the implementation details at the moment. Limetech is talking in podcasts of this feature being targeted at the 7.0 release (the next one after the 6.13 release that is due to hit public beta soon) so going on past experience I would expect that release to appear sometimes towards the end of the year. No idea, however, is that is a realistic estimate as in the same time scale the intention is to remove the requirement to have at least one drive in the main Unraid array. As you say this has been a plan for quite a while so it is always possible that there has been internal rework going on towards this target in the current Unraid releases.

What address does your workstation have for its IP address and gateway? The Unraid server needs an address on the same subnet and should use the same gateway(s). If you cannot figure things out then deleting the network.cfg file; rebooting the Unraid server; and then taking and posting new diagnostics so we can see what happens in that circumstances might help.

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

You should post your system's diagnostics zip file in your next post in this thread to get more informed feedback. It is always a good idea to post this if your question might involve us seeing how you have things set up or to look at recent logs.

A gigabit LAN silently downgrading to 100Mbps normally means that there is at least one twisted pair not making connection in the cable between the router and the server. This can be either a broken wire within the cable or a pin not making contact at either end. I would suggest trying different cables and/or ports.

According to the diagnostics you still have a fixed address of 192.168.50.203 set in the network.cfg file which is strange as you say you deleted that file and the default should be DNS. You should either set go to setting->Network and make sure you have set the server to DNS or alternatively change the IP address there to one that is compatible with your router in your new home. You may also find the gateway addresses you have set are no longer valid or wrong. In particular you currently seem to have the first one point back to the Unraid server rather than to the router. Not sure what the other ones are currently pointing at?

As you said all the SATA drives appear to have dropped offline at about the same time. This has to be due to something they all share.

No. The whole purpose of the parity swap procedure is to replace a parity drive with a larger one and then rebuild the contents of the emulated drive onto the old parity drive that is replacing the disabled drive. It works in two phases which have to both run to completion without interruption if you do not want to have to restart again from the beginning. the first phase will copy the contents of the old parity drive onto the new (larger) parity drive. During this phase the array is never available.. when that completes the standard rebuild process starts running to rebuild the emulated drive onto the old parity drive. If you were doing this process in Normal mode the array is available but with reduced performance (as is standard with rebuilding). If running in Maintenance mode the array will become available only when the rebuild completes and you restart the array in normal mode.

The syslog in the diagnostics is the RAM version that starts afresh every time the system is booted. You should enable the syslog server (probably with the option to Mirror to Flash set) to get a syslog that survives a reboot so we can see what leads up to a crash. The mirror to flash option is the easiest to set up (and if used the file is then automatically included in any diagnostics), but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.

If you want to be able to see logs of what happened before the last reboot then you have to enable the syslog server to get logs that can survive a reboot.

Did you copy across the contents of the 'config' folder from the old flash? That should have gotten the plugins and docker templates back just as they were.

That is more frequent than most people go for. Monthly or even less frequently is far more common.

Yes. As long as they only happen occasionally they will be a non-issue.

From your description it will not have gotten far enough to be able to write a file. It might be worth rewriting all the bz* type files as described here in the online documentation to see if that helps just in case one of those files is failing to be read properly on the problem machine.

You should be able to do this using the Dynamix File Manager. You can also do it from the command line but if you are not familiar with it you could cause further problems.