JonathanM

Not saying this is best or right, but it works for me as a network check. However, this is NOT in my go file. #!/bin/bash printf "%s" "waiting for IP ..." while ! ping -c 1 -n -w 1 192.168.X.X &> /dev/null do printf "%c" "." done printf "\n%s\n" "IP is online" Obviously change the IP to what you need to monitor, and add any actions you wish to happen at the end. This script just prints ...... until the ping returns successfully, so if the ip is never reachable, this will stall. There is no automatic escape. Think carefully about what could happen if your remote server is offline, you may want to change the logic. Perhaps a for next instead of while do.

Keep in mind that parity is calculated and maintained for every bit, not just the bits actively used by files. If you change bits in an "unused" area with the drive offline, that parity address will be wrong when you put the drive back in.

Diagnostics? Sounds like the flash drive may have errors.

Start reading here. https://forums.unraid.net/topic/48383-support-linuxserverio-nextcloud/?do=findComment&comment=755742

Yes, yes it is. Thank you for your support.

Works fine for me. What browser/OS/etc? Nevermind. I see the same exact behaviour after applying the latest CA update. Firefox 67.0.4 Linux Mint

This is an ongoing issue, recently it's become a bigger issue. Simplest fix would be to set up a cache drive, make sure the appdata is on said cache drive, and change the docker appdata mapping to /mnt/cache/... instead of /mnt/user/...

Not sure how to answer that. If you have a memory chip error, non-ECC silently corrupts the data, leaving it up to the program logic to catch and correct it. With ECC, the error is trapped, corrected if possible, if not, the system is halted to avoid further corruption. Unraid doesn't need or benefit from ECC any differently than any other OS. It pretty much comes down to risk tolerance and backup strategy. If you have full backups with checksums and don't mind dealing with possible silent corruption, then ECC is probably a convenience instead of a necessity.

Yes, stop the array, change the format type for the specific drive that you wish to erase, start the array, ensure only one drive (the one you changed) shows as unmountable, check the yes I'm sure, select format. As long as you follow directions, no parity rebuild is necessary. Parity operates on the whole disk, regardless of format.

https://lmgtfy.com/?q=spaceinvader+one+krusader

You need to enable NAT loopback, hairpinning, or whatever your router calls it. It's controlled by your router.

What you are seeing is the file table of contents listing, which is good. Whether or not the files themselves transferred properly is another question. The only way to know for sure is compare the checksums done before the corruption to what was recovered, or compare the files to your backups.

That's because the destination IS still available, according to the system. When the drive is unmounted, the files will be created anyway, only instead of going to the drive, they are going to RAM. That's because Unraid runs entirely from a RAM disk created during boot time. This is a sticky situation, and without extra scripted steps is not easily solvable. Something I have not tried, but may work, is to set the UD stick to be shared on the network, and point the backup to the network location instead of the local disk mount point. That way when the disk is unmounted, the network share is gone as well.

Then it's not the same issue.

Unattended updates will always have that problem. Delaying the update won't change that. If you don't check the forum for reported issues before updating, that's on the user. Never apply updates without looking at the changes and checking for reported issues. 35+ years in computer experience talking. I always let updates simmer for a few days, if there is an issue, the guinea pigs will always squeal and alert me. I've never been hit with an issue that could have been avoided by updating right away vs. waiting a week. Granted, there are some situations on public facing machines where securing against an imminent threat is required, but I don't run any machines that can't be temporarily firewalled until the situation is more thoroughly investigated.

Have you seen it reboot with only the basic file sharing services? No dockers, no vm's, no plugins?

Already included. https://forums.unraid.net/topic/49212-how-do-i-edit-text-files/?do=findComment&comment=744671

Yep. And I'm betting it's read just as often as any EULA. You can't fix some people.

Add a path mapping to the docker.

I'm not saying it's on you to make it clearer. I just tried out a test workflow. I went to the apps tab, typed in nvidia, installed the plugin, which says "unraid nvidia", and installed the build. At no time in the process were there any warnings that limetech wasn't involved, in fact, it says unraid right on the plugin. Yes, it also says LSIO, but from a new user perspective, that's not a warning. There was no requirement to go to the support thread to see all the big warnings. The apps tab makes it very easy to install mindlessly. That's a good thing when you know what you are doing, and are active in the community forums. Not so good if you are a mindless newbie following some random reddit post. I don't know if there is a solution, without crippling unraid. We either get to play and possibly break things, or it's locked down to keep people from hurting themselves. Maybe the CA installer needs to have another level of protection for some apps, like maybe an install code in the first post of the support thread. I'm just trying to see things from a new user perspective, just diving in and getting full access to all these wonderful toys. Do we tell the kid the stove could be hot before they touch it? We know they will touch it anyway, so why bother? Chances are, they won't get burned, the stove is only hot occasionally.

I can see a situation where someone has the false impression that plugins are curated by limetech, like the apple ecosystem, instead of user managed, like android. Perhaps make the warning more prominent that you are stepping off the limetech reservation when you install plugins?

There is an entry listed in the picture you posted. It is checked as active. Click the remove at the bottom right of the picture.

Try removing the existing entry and add a new one instead of editing the existing one.

Grab the very bottom edge of the window and see if it will pull down.

It sounds like you skipped the last part of this step, or moved on and tried to complete it out of order. Since you started docker before you completed this step properly, you now have duplicate files on one of your array disks and the cache disk. The mover won't be able to resolve duplicates, you will have to do it manually. Disable the docker service again, and use mc at the console or ssh command line to move the appdata folder from /mnt/disk1 or whichever disk number it's currently on to /mnt/cache. You will get warnings that the files exist, do you want to overwrite, yes to all.