itimpi

You probably want to use the process documented here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

No idea why the files on the cache should be read only - it is not normal. Are you sure that some application does not have them open You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

Please post your system's diagnostics zip file so we can see what other settings you have that may be relevant.

Not seen those ‘syslog time’ entries before - I wonder what causes them.

you can definitely access SMB shares via WireGuard - I do it all the time. I have, however, configured my router to not use the default subnet so that I am almost certainly on a different subnet when I try and connect remotely. Not sure if this explains why I do not have problems as I would have thought using the server WireGuard ip address should work.

You should provide the log created by the syslog server so we can see if there is any clue in what lead up to the shutdowns.

You are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

No, that is not the way to proceed. Disk4 has the data from what you say (it is NOT being emulated. As long as you are happy to lose any files that are currently on disk5, then get disk5 out of the array you need to do: Tools->New Config and select the option to keep all current assignments (the New Config tool is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page). Return to the Main tab and unassigned disk5 if you want to you can reorder other array drives at this point Start the array to rebuild parity based on the new drive set

Disk5 was getting write errors which is why it was disabled. Are you prepared to lose the contents of disk5?

I would suggest you enable the syslog server with the option to mirror to flash set. Hopefully then if it happens again you may have a syslog file in the ‘logs’ folder on the flash drive that shows what happened leading up to the crash.

Just in case even after the upgrade to latest some plugins are incompatible with 6.12 I would suggest you do your first boot after the Unraid upgrade in Safe Mode to eliminate any plugin issues. If that works fine then see if you can boot in normal mode.

Not quite true. A speed of 30-40 MBs is not abnormal if you do not have Turbo Write enabled.

Looks to me like it is working correctly ? Are you sure you know how high-water works? It is described here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page. the high water mark is based on the largest drive (13.8 GB). That drive will therefore be used until next high water point of 6.9GB is used) and then disks are used in turn until they drop below that. Next high water mark is 3.45 GB and disks are used in turn until that point reached. At the moment that phase has only got as far as disk4.

The confusing thing is there appears to be no data in that share, so what disk does it physically reside on? The reason for asking is to confirm that you do not have anything creating that folder under /mnt/user other than the User Share process.

Do you mean it is the name of one of your shares?

According to the diagnostics the dtive dropped offline. You may need to power-cycle the server to get it back online. You should also check cabling (power and SATA) as this is the commonest cause of such issues. To get the drive to no longer be marked as disabled you will need to rebuild its contents as covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

If you have an emulated drive it will be one of the data drives.

All correct except that at this point there will be no parity (I.e. it is not emulated).

For file Management purposes it is easiest to use the Dynamix File Manager plugin so you can do it from the Unraid GUI.

You get a read check if your data is not protected because you have as many drives disabled as you have parity drives (as seems to be the case here). You are not currently protected against another drive failing until you clear the disabled state on disk5. The system will currently be emulating the contents of disk5 using the combination of parity plus the other data drives.

Your syslog shows: Aug 3 11:36:08 AttilaServer emhttpd: Unregistered - flash device blacklisted (EBLACKLISTED) That suggests the flash drive you are using does not actually have a unique GUID. The new release will have an updated blacklist which is why it is now getting detected. To get it working you will have to do a licence transfer to one that does.

I would suggest downloading the zip file for the release and then extracting all the bz* type files overwriting those in the root of the flash drive. This often seems to work for some reason that is not obvious.

If you use the option to keep all current assignments, then when you return to the Main tab then they are all set as before running the tool so it should be obvious which is your pool devices, but you can now make changes before starting the array. FYI: Using the New Config tool is covered here in the online documentation accessible via the ‘Manual’ link at the bottom of the GUI or the DOCS link at the top of each forum page.

What you did would work but is a bit error prone. A better process is something like Use Tools->New Config and select the option to keep all assignments return to the Main tab and change the drive assigned to cache if you parity, check the Parity is Valid checkbox to avoid rebuilding parity. You can then ignore the warning about overwriting parity as it does not take into account you checked this option. start the array and then format (if needed) the new cache drive.

Just worth pointing out that you would expect the error count for a correcting sync to be the same as the previous non-correcting one as Unraid does not distinguish between errors detected and those corrected.