itimpi

Please attach the complete diagnostics zip file rather than the files individually. It is too much hassle to download them individually.

I would suggest it is worth downloading the zip file for the release from the Limetech site and then extract all the bz* type files overwriting the copies on the flash drive. This would fix any of those files if they got corrupted for some reason by the power loss. It might be worth considering investing in a UPS for the Unraid server if power-loss regularly causes problems. Do you have a backup of the USB drive? If not you can easily get a zip of the contents by clicking on the flash drive on the Main tab and selecting the backup option. It is a good idea to redo this any time you make a significant configuration change.

If it is not part of the array then it is perfectly acceptable to have a NTFS drive managed by the Unassigned Devices plugin. This is one of the standard Use Cases where you want to be able to easily transfer files to/from Windows systems.

I am afraid that Unraid is never free any more so if you read that it is talking about an old version. The closest is the trial version which is free but time limited to 30 days (with one 30 day extension allowed) for you to confirm that Unraid meets your needs, runs on your hardware, and is worth paying for.

What IP address is it getting? If it is one starting with 169 then that means it is a 'made up' address because Unraid cannot find a DHCP server (or the network is not found).

If this happens then it means the drive dropped offline temporarily and then came back online (which causes a new /dev/sdX type id to to be assigned at the Linux level) so it is no longer mounted at /boot. Quite why this is happening for you is unknown without more to go on. Is there any chance the USB stick is not firmly in the port, or could something have slightly dislodged it?

It is not at unusual to only get something like 30% (or less) of the headline quoted speed in throughput terms when using WiFi

The symptoms you are describing are not typical. There has to be something going on at your end that is causing them.

Ad blockers are known to cause issues with various part of the Unraid UI. You want to whitelist the Unraid server in the ad blocking software to avoid this.

I would suggest waiting a while to give the issue a chance to manifest itself and then try downloading the diagnostics before the log actually gets full.

The way that Unraid spreads data across drives depends on the settings you have set up for specific shares. if you do not need all drives at the moment I would recommend that you do not even add them to the array, but keep it available for when you actually need it. That could be as an additional drive if you need the space or as a replacement for a failed drive. Each additional drive is a potential additional point of failure so why not avoid even that small chance at this point.

In a case where the current release does not have support for the users hardware it is not an unreasonable recommendation. You can argue this both ways. Many users are using the current beta successfully on live systems without any major issues. Also as well as providing support for newer hardware the beta does fix some significant known issues that are present in the 6.8.3 release. It is likely the next 6.9.0 release will be a rc one so it is not as though we are early in the beta release cycle.

No, you are not bypassing parity. Once you have parity installed then all the /mnt/diskX and /mnt/user/? type paths are protected by parity. If you get parity errors then it is due to something else going on. BTW: you do not need to use sudo as you are already the root user when logged into the command line.

I would say it should NOT be your parity disk. If a disk fails then Unraid relies on being able to reliably read ALL the other drives plus parity to recreate the contents of the failed drive. Therefore if you put your unreliable disk in as parity you have no confidence you can recover a failed array disk with its contents uncorrupted.

The username for the GUI is always ‘root’. Initially there is no password until you set one via the Users tab in the GUI.

For any particular device the devices IP address and gateway need to be on the same subnet or you will not be able to navigate to devices on any other subnet. As was said this raises the question as to why you have two subnets in the first place - this is not normal on a home network unless you explicitly set it up. Perhaps one subnet is the one given out by DHCP and the other one where you have set static addresses?

You would probably have been OK if you went with the 6.9.0 beta release. It has a more recent Linux kernel and drivers for some of the newer NIC chipsets.

Yes, but if you want to avoid having to reconfigure things then you need a backup of the old stick. This is easily obtained by slicking on the flash device on the Main tab and selecting the option to download a backup as a zip file.

This means that parity is no longer valid. There have been quite a few cases where users have assumed that they can do a format in Unraid and then rebuild to get back the contents. This is despite the big pop-up warning you this is not the case as the format updates parity.

To be able to see disks over the network then you need to enable disk shares under Settings -> Global Share Settings

In principle switching to new hardware is as simple as plugging in the drives and booting of your existing USB stick. Everything should come up just as it was on the old hardware. The exception is if you are running VMs with hardware pass-through as the pass-through settings will need to be changed to match the new hardware before such VMs will run successfully. You should ensure you have a backup of the contents of the USB stick and that it is updated any time you make a significant change. You can download a zip of the contents by clicking on the flash drive in the Unraid GUI and selecting the backup option frim there.

Have you also installed the Unassigned Devices Plus plugin? I believe this is required to get support for exfat.

Not that it is likely to be of any use to you, but my investigations suggest that sbsynced2 is a timestamp for the last completed sync, and the mdResyncAction value says that the action (last one if not one currently running) was checking both parity1 and parity2. I did not notice anything obvious to explain the slowdown. It might be worth installing the DiskSpeed docker to see if that shows any specific disk showing slowdown symptoms.

I hope it ends up really being that simple but I am still not convinced The commonest case of parity needing to be corrected is after unclean shutdowns and in such a case there must be a significand chance of more than one drive being wrong. I would suggest that if anything along these lines is done the first step would be to simply report in the syslog which drive seems to be the culprit but keep current behaviour otherwise. That would allow for collecting some real-world evidence on how reliable doing any sort of auto-correct based on the detection algorithm might be.

That would explain why you do not get an IP as there will almost certainly not be any drivers for your NIC in that release.