itimpi

It is not normal for that file to survive a reboot as the ‘root location is in RAM. Are you sure you have not added an entry to the ‘go’ file or User Scripts Plugin to copy that file to that location.

… and the 6.9 rc1 release (which should be soon) will switch back to a 5.x series kernel.

It is not necessary to preclear a drive to be used for a rebuild (and does not speed up the rebuild) - it merely checks the drive appears Ok. A rebuild tends to take something like 2-3 hours per TB of the drive being used for the rebuild.

This almost invariably turns out to be the disk is continually resetting for some reason. It is often a cabling issue but since it recovered when left alone there my just be a dodgy area on the drive. It might be worth running an extended SMART test on the drive to see what that reports.

Probably the most important difference is that cache is part of the User Share system whereas unassigned devices are not

You can switch manually to any release by downloading the zip file for the release you want from the Limetech site and then extract all the bz* type files overwriting those on the USB stick. If you want to create a new USB stick then the Manual method is worth trying - I do not know if Catalina stops this working.

Just to expand on this the reason that Unraid needs to format the device is that Unraid wants a very specific partitioning scheme and if the disk does not already conform to this Unraid will first repartition the disk (thus erasing its contents) before doing the actual format.

If you get prompted to add -L to the xfs_repair run then repeat the run with this option added.

An Unraid shutdown process will start by stopping the array if it is currently started

There is no such feature in Unraid the commonest need along these lines is to back up appdata files from the cache to the array. You can use the CA Backup plugin to automate this. There is also a plugin that can do a similar thing for VM vdisks. Anything beyond that you will have to do for yourself.

The Safe Mode boot option only stops plugins from being installed (since they can de-stabilize the system ) It will not stop dockers from being started.

It is expected that those shares will get high traffic if running VMs or dockers which is one of the reasons having them on the cache is recommended (as well as overall performance of VMs and docker containers). The 'appdata' share will be where all the docker containers that are running are writing their variable data. The 'domains' share will be where the vdisk for your unifi VM is located. The 'system' share will be where the docker.img file is located that contains all docker containers. As to whether the figures you are seeing are appropriate for your workload I have no idea.

You need to rerun the repair with the -L option added.

I could see there potentially being locale dependent issues with £/# and “/@

You should post your system diagnostics zip file (obtained via Tools->Diagnostics) to your NEXT post so we can see what is going on. If you have added the disk to the Unraid array then try clicking on the drive on the Main tab anb selecting the option to run a File System check. Post the results of such a check.

You need to click on the icon (not the name) to get the drop-down menu.

I believe that is the case unless the BIOS on the motherboard has an option to disable the EEC capability.

The enhanced security for the flash drive will not let you do it over the network! If you do it from the command prompt then the files are located under /boot/config/shares The other possibility is to plug the flash drive into a PC/Mac and remove/rename the files from there. If it is not the USB stick corrupting the files then the only other thing that occurs to me is a RAM stick going bad.

One option is to simply delete the .cfg file for any given share and then reboot to get a new one generated with default settings. If one of those regenerated files then gets corrupted I would suspect that you have a problem with your flash drive.

It is not just the serial number that must match. The drive must also report itself as holding exactly the same number of bytes and the USB enclosure may have massaged that in some way.

I think the array needs to be stopped before you can change the network settings.

How are you running this script? The tightening of the security on the flash drive means files located there can no longer have execute permission. the simplest way to handle this is to use: bash scriptname rather than simply the script name

Your network settings do not seen to make sense! # Generated network settings USE_DHCP="no" IPADDR="192.168.0.197" NETMASK="255.255.255.0" GATEWAY="173.72.132.1" BONDING="yes" BRIDGING="yes" DNS_SERVER1="1.1.1.1" The gateway is on a different subnet to the Unraid server 🙂 With that setting the server will never be able to reach the gateway and thus access anything outside it's own subnet. I would have expected the gateway to be set to your router's address (probably 192.168.0.1). You also seem to be getting read errors on your parity drive so you might want to check it's cabling.

I would think that the most likely one could (indirectly) end up being NerdPack. It would not be the plugin itself that is the problem but one of the packages you have selected for it to install from the many that are available. If you put that plugin back I would recommend keeping careful track of which packages you have told it to install so we can identify which ones might need updating for 6.8.0 compatibility.

Is there any chance the CPU you have was an 'Engineering' sample as these often do not have all the virtualisation features present?