BRiT

Try: /usr/sbin/rclone copy /mnt/user/nextcloud GoogleDriveBackupCrypt:/unraid/nextcloud

No. Not to where the plugin is installed from, but where the rclone is installed to. From an unraid terminal, type in the following command to see where it's installed to, such as /usr/local/bin/ or /usr/local/sbin/ . which rclone For example, which mover, returns /usr/local/sbin/mover .

Rclone might not be in the default path, so try setting the path variable to include it before first calling rclone or try using absolute path to rclone on each line.

You should probably post in the specific docker support thread for the container, which is available from the docker menu. You may be using this one, but I wouldn't know, but it showed up in CA :

I think he gave you all the steps needed.

You have MFT of drive errors spamming your logs when trying to Spindown your drives.

No. That is a replacement variable used by Samba itself. It is not meant for you to set.

Randomly, no. But at a moment of our choosing...

Pretty much that's what's to be expected from IPv6 unless you're using your own DHCPv6 setup with static mappings based on static Client DUID. Also from what I've seen on WinOS, you have multiple IPV6 addresses, where it uses handful of temporary IPv6 addresses, nearly one unique one per connection between client and server for security.

Do not expose it to the internet at all, only trusted users can get on the internal network, not having any mapped drives to unraid from other pcs, all shares exposed only as readonly and have all major data files marked as immutable.

No. That is no proof.

No. Not Q.E.D. What you showed is entirely something else. You went through the situation where you control all the other variables in the algorithm and only change one of them. In reality, you can not control all of the variables and be certain that only 1 change was made.

That pretty much how it's done. Its very tedious and time consuming getting things just right. But once you're done and pushed those changes as an image, then anyone else can use it too. Docker has tutorials on creating images, such as using the dockerfile and docker commands and then pushing/committing the resulting image to its hub. For configuration ... In this situation you need to work out how to externalize the changes to a single file. If not a single file then maybe an entire directory. Deal with that with volumn mappings to externalize it. If that's not possible then you need to make your own script or program system to process from a single file or maybe docker environment variables/parameters. Then on every docker startup, your image processes the file and makes adjustments as needed inside the image.

See. Exactly as I said. Your post with the diagnostic file is being overlooked because it's in the middle of all the reactions.

Not to pile on, but had you even read the 6.8.3 release announcement thread you would have seen the bountiful number of users who have upgraded to 6.8.3 stable ages ago. Yes, you posted a serious problem for you, but not others, without doing the least bit of troubleshooting or investigation and screaming about it in all caps nonetheless. You over-reacted so expect others to over-react in kind. You have already been given sound advice on the first step to take -- post your Diagnostics file, and have done so ... but then you continued to carry on afterwards, so I'll be surprised if anyone even sees the post with the file required to assist in troubleshooting since it's now quite a few posts back. Here's some critical advice: Stop. Breathe. Relax. Wait. Wait for others to take time out of their own busy day and begin to look through your logs. Unraid 6.8.3 is perfectly fine and stable. I didn't upgrade immediately and still have 158 days of uptime on it without any issues.

That was covered in my list of functionality.

It comes down to being mathematically uncertain that you only have 1 unknown in an algorithm set of N variables. I do think it would be nice to have a better presentation of where or what Data Integrity issue (corruptions) your array has. Ideal world would have something like the following (massive amount of functionality required): UI display the list of corruptions detected For each corruption, a way to view the data stored there for each drive For each corruption, a way to possibly view the filename located there for each drive For each corruption, an indicator of likely which drive has the corruption if only one drive is corrupt (with huge warnings and caveats about dragons) For each corruption, a means of backing up current data values for each corruption for a designated drive For each corruption, a means of restoring the data from the previous backup for a designated drive For each corruption, a means of selecting a drive to attempt a rebuild of the data which then marks this corruption as possibly fixed and has yet to be verified by the user This doesn't do anything automatic, except generating the list of corruptions during the scan.

So you're backing away from your Cosmic Data Change example that simply was never possible. So that's a good sign.

Not with the algorithm unraid uses for dual parity.

And I will point you to the details of how hard drives work in reality, where the drives themselves will report CRC errors, and thus you know which drive is damaged.

The answer to this is "From your backup(s)". unraid does not remove the need of backups. If you value your data, have a backup plan to follow.

It's always running on behalf of "root" since that's the only user that exists for unRaid on the GUI or able to login.

It might still work if she never upgrades the versions of unraid and doesn't connect to internet during startup. Its best if you can somehow work something out or simply steal it back.

In the meantime, perhaps provide a LetMeGoogleThatForYou on the package name link?

Others have already brought up this point (here or elsewhere), so why are you ignoring it for your cosmic example? The drive itself will know what data is wrong since the hardware supports checksums of sectors, so if a data bit is flipped and it doesn't change the checksum information, the drive will report it. In addition to that, you may know what's wrong if the filesystem used supports checksums or you use a 3rd party plugin for checksums. Mathematically it is impossible to know which disk is wrong with the algorithms used by single and dual parity protections.