itimpi

Never heard of the upgrade losing settings. Sounds as if you may have a flash drive problem if that is happening as that is where all the settings are stored. 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. No. Changing the file system type always involves copying the data elsewhere, reformatting the drive and then copying the data back.

Do you mean that you ran the xfs_repair without -n and it still showed as unmountable when you start the array in normal mode? That is very unusual! You really need to put in place a process for backing up important data that is not easily replaceable.

There is no reason the reboot process itself should disable a device, so it is likely something happened before the reboot. 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 the reboot. The mirror to flash option is the easiest to set up, but if you are worried about excessive wear on the flash drive you can put your server's address into the remote server field.

Are disk7 and disk10 meant to be present and have data on them?

Where are you based? For most users this downloads in less than a minute.

If you want to shutdown overnight and are going to use large drives so that operations like parity checks take a long time then you might want to consider installing the Parity Check Tuning plugin. This provides the option to restart such operations from the point previously reached when you next boot. Without this plugin installed these operations are always restarted from the beginning if they were active when the server shutdown.

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 start by uploading your system’s diagnostics so we can get an idea of your current setup.

Were you reinstalling the docker containers via Apps->Previous Apps->Docker? That should keep settings intact.

That shows you have two copies of the docker.img file on the cache drive again. You probably have it configured incorrectly at Settings->Docker. if it is not that you are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

Do you by any chance have the Docker Folder plugin installed? If so you should remove it (it has been replaced by Folder View). if it is not that you are likely to get better informed feedback if you attach your system’s diagnostics zip file to your next post in this thread.

Parity works at the raw sector level and has no understanding of the contents of sectors. Encryption is therefore irrelevant to parity.

You can plug in removable drives via USB. You probably want the Unassigned Devices plugin which can handle most common disk formats.

Really up to you. I personally prefer XFS on array drives as being the more robust and performant, but BTRFS is a good chance if you have reliable hardware and are worried about data integrity as unlike XFS it has built in check summing. BTRFS though is more likely to have issues if you have unreliable hardware (in particular RAM issues).

You will need to contact support to resolve this. Have you already used the 1 automated transfer allowed per year? When that is exceeded you always need to go via support.

No. Parity only works at the block level and does not understand file systems. You would have to copy the data elsewhere first before reformatting to avoid data loss.

You could try running the command du -h /var/log to see what is taking up the space.

I suspect you have something else configured to use the wrong case. You could try running the command: ls -l /mnt/*/?ystem and hopefully the output of that will show where the issue originates.

For this see if it can pass the Extended SMART test either on Unraid, or on another system. Failing that should be enough for a RMA>

Did not spot an obvious issue in the diagnostics, but I would suggest running check Filesystem on all of your drives as file system issues have been known to stop the User Shares from appearing.

The shares that say unprotected are ones that by default are configured to be for their files put on the cache drive for optimum performance. They are used to support Docker and VMs. If that is a single device it has no redundancy do they are then unprotected. The appdata backup plugin can be used to make regular backups to the array. Unraid is NOT Raid, and it tries to keep array drives spun down if at all possible.

A rebuild does not clear an 'unmountable' status as a rebuild gives you exactly what you can see before the rebuild. The process for handling 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.

Not sure what is going on because the flash drive cannot be emulated - may be a misleading error message.

Have you made sure you are up-to-date with the ‘connect’ plugin (if you are using it) as the last release was meant to clear an excessive logging issue.

The way to get better speeds for initial load is to not have any parity drive assigned at that point. However that does mean the data is not protected against drive failures until you DO get around to having a parity drive and building the initial parity. 50MBps seem slow if you are not doing any parity actions and also have Turbo Write enabled - I would expect more like 80-100MBps unless there is something else going on that is contending for the drives.