Squid

Google is your friend https://unix.stackexchange.com/questions/7412/how-to-reconnect-a-logically-disconnected-usb-device But, you would have to be very careful to not detach the boot flash drive, as then you'll run into other problems.

Yup. Extended tests

The trace *should* be harmless

It appears to be a ryzen issue and the speed of your memory https://forums.unraid.net/topic/85671-machine-check-events-error/?tab=comments#comment-794266 Impressions can be misleading. I'm an ass

Normal because with any OS transferring tons of small files, the overhead starts to become noticeable.

Or even simpler, do it from the Network Share on the server "flash" if it's exported

Post diagnostics

Have you formatted disk1 yet? Is there data supposed to be on it? Also, going forward always attach the zip file, not individual ones

Post your diagnostics

Because you have a root password set and have logged out / restarted the server / cleared cookies on your browser Having a root password shouldn't affect anything

Nope. It's somewhere on your end / isp / whatnot. You are unable to hit either the primary or backup server

227802

I can almost guarantee that your flash drive dropped offline or has problems. Use it in a different port, ideally USB2. A reboot is going to be necessary

You need a copy of the flash drive backup. If you had a copy of the appdata backup, you may have also configured CA to do a flash drive backup to the array. You need to grab a copy of the folder /config/plugins/dockerMan/templates-user from the back up and put it on the flash drive. If that doesn't exist, then ultimately what you're going to have to do is take a screen shot of the docker tab, with all the ports / paths all showing, then delete the containers and re-add them via Apps and re-enter in the appropriate values. (ie: configure from scratch). You won't lose your appdata though...

But the whole thing is a joke anyways. The capacity is always the total capacity of your data drives. unRaid always uses the full capacity of the data drives, unlike a RAID solution where mismatched drives will result in less capacity than the total. (Not to mention that the calculator doesn't take into consideration if you're running dual parity drives, or a cache pool)

Actually, it's fine. It's expecting you to enter in drive sizes in GB. And if you have a 14GB hard drive I'd be really surprised. (IE: You should be entering in 14000) Secondly, it is confusing the issue between GiB and GB since it's referring to manufacturer capacity and actual storage space using the same units when they aren't (manufacturer is GB and "actual" is GiB) Both units are valid, but you can't refer to "actual storage space" in terms of GB since the implication is that this is what Windows reports. Windows has it wrong by consistently using the wrong units.

The next release of CA will look for that circumstance and automatically change the reference to be a drive that is installed in the system.

Because there is no VNC available once you're using GPU passthrough. It is expected that you will be using a monitor. If you need VNC with passthrough, then after you have the VM all set up, you would install VNC, TeamViewer, etc on the VM.

The errors are all normal kernel start up stuff and nothing to worry about. The screenshot shows the rclone plugin updating itself at boot time and is normal for it

Settings - Docker - Stop The Service. Advanced View, delete the image Re-enable docker Apps Tab - Previous Apps - Check off whatever you want and hit the install button. Grab a beer I'm talking within sab and deluge UIs Should be both set to /Downloads (and the incompletes also) Case matters

It's hard to put that into context, but it does point the finger at sab downloading directly into the docker.img file due to a misconfiguration that you've made in Sab's settings in its GUI. And because of that, you've trashed the docker.img file and need to recreate it which is an easy and painless procedure (and this also explains why everything else is happening) https://forums.unraid.net/topic/57181-docker-faq/#comment-564309 The answer is that this does not happen regularly, and is almost invariably either user error or hardware

It may be less secure if the drive being written to fails before parity gets updated, but it would be a complete disaster if any other drive happens to fail in the meantime (that may contain files that aren't irreplaceable), as you will be virtually guaranteed that the file(s) contained would get corrupted since the parity wouldn't be valid.

What you've done is the exact same thing as enabling disk shares and not exporting SMB shares except for the cache drive.

You can't without creating your own custom bridge network via appropriate commands. As soon as you assign a static IP address to a container all port mappings are ignored under the default bridge.

In order to know how to update parity in real time the system needs to know either 1 The current contents of the sector on the parity drive and the data drive so that it can then rewrite the appropriate updated parity info into the parity sector and the update to the sector on the data drive. (Involves and extra read I/O and associated latency on both drives). No other drives need to be spun up. or 2. The current status of the sectors on all data drives not being written to so that it can recalculate the parity information to the parity drive and do the write to the data drive in question. No extra read I/O or latency involved. All drives will spin up. https://wiki.unraid.net/UnRAID_6/Storage_Management#Array_Write_Modes