itimpi

One thing I notice is the Media share is configured to Use Cache=Yes, but does not seem to have the pool to use for caching specified. Not sure if if it is the cause of the problem but that seems a bit strange to me.

Probably time to post new diagnostics so we can see the current state of things? A screenshot for the share settings of one you want on the pool might be a good idea as well. It is almost certainly going to be something very simple once we spot it

That is fine as long as you want the same settings for all media types. Many users want slightly different share settings for the different media types.

Not quite sure what you are asking.? If you are talking about the first option then BOTH parity disks need rebuilding so you are not protected again until that completes.

Stop Array, unassign parity2, restart array to commit change. Your steps would leave Unraid complaining about a missing parity2 drive

The easiest thing would be to edit the config/network.cfg file on the Unraid flash drive to change the static IP to one in the new range

Edit the title of the first post in the thread to add SOLVED.

That would be what I would recommend as the easiest way to proceed. You can check that the old disk mounts OK and you can see all its contents ready to be copied. Only if that is not possible would I consider doing anything else.

It is probably worth: taking new diagnostics in case anyone wants to see the current state reboot the system from the array stopped state to see if you can now avoid the unclean shutdown

You cannot change the file system type during a rebuild process. This would format the emulated drive to an empty XFS files system and updated parity to reflect this. The rebuild then makes the physical disk match the emulate one so you end up with the empty XFS file system. This. You could also mount it under Unassigned Devices on the Unraid server. You could also probably recover most of the data by running reiserfsck against the rebuilt drive but this does not seem necessary in this case.

You can download a UEFI compatible version of memtest from memtest86.com.

This is what I would expect. Just because a drive is unmountable it does not stop its contents being included in the parity calculation and thus read for rebuild purposes. it is a bit concerning that either drive is still being flagged as unmountable. If a disk is showing as unmountable before starting the rebuild then it will still be unmountable afterwards as all the rebuild does is make the physical disk match the emulated one. That is why we normally recommend fixing the unmountable state on the emulated drive before attempting the rebuild.

To get the syslog server to log locally you need to set the Remote Server to be the IP of the Unraid server so that it acts as both client and server.

Have you tried restarting the array in normal mode?

Not sure I understand? I would expect each share to be restricted to a specific array?

If you have multiple array licences then you could get multiple arrays now by running additional instances of Unraid in VM's and passing through the disk drives to these additional VMs. This is the technique I use to run multiple test instances of Unraid hosted on one production machine but see no reason why it could not be multiple production instances.

If it is marked as failing in the FAILEd column then the drive should be considered as having a fatal error. A failed extended SMART test is also considered fatal. If it is highlighted in the Unraid GUI then can just mean it is one being monitored by Unraid and you need to look carefully at this attribute - especially if it keeps getting worse.

du is known to often not give correct results on multi-drive btrfs format arrays.

Technically this is not a fatal error so those attributes being non-zero is not listed as failed in the attributes, but they are an extremely bad sign. As a general rule if SMART marks anything as failing then the drive should be changed ASAP, but the converse does not necessarily mean there is no problem.

That is the wrong command if working with the /dev/sdX type devices then you need to include the partition number (e.g. /dev/sdl1). However using the /dev/sdX devices is not recommended for array drives as it invalidates parity. You need to use /dev/mdX (where X is the disk number on the Main tab) (e.g. /dev/md5) to keep parity valid. In addition the mdX devices do not need the partition number.

Unless specified otherwise this will be what is wanted.

I am afraid I have no idea then The symptoms point to it being hardware related but not clear what hardware it could be if not the power supply.

I suspect the instructions are no longer accurate as in the last few Unraid releases security has been tightened so that files on the flash drive are not allowed to have execute permission. instead of using a link as suggested you need to copy the files elsewhere (such as /user/local/bin) and give them execute permission.

You should post your system’s diagnostics to get better informed feedback. it sounds as if you may have an issue with the Ethernet link between Unraid and the router? This could be the port or the Ethernet cabling.

Exactly what power supply are you using - I would think this is the most likely culprit as a parity check is one time all drives are being used putting maximum load on the system.