Squid

Do the advanced replacement. Basically they overnight you a replacement right away, put a pre-auth on your CC, and when the old drive get's received by them they clear the pre-auth.

# stopping_svcs # Occurs during cmdStop execution. # About to stop network services. IE: array is still running. IIRC, all events are executed prior to the services stopping / array stopping, but docker / VMs are stopped

https://forums.unraid.net/topic/57181-docker-faq/#comment-566084 or https://forums.unraid.net/topic/32276-docker-requests/ Depending upon what you're asking about

The one gotcha (kinda) is where did you set the static IP addresses? If on each device, then you've got to redo every one of them. When using static IPs, its far easier to set each device to be DHCP and instead assign the IP within the router so that everything is all done in one place.

Look in the flash drive's share in the logs folder. Hopefully the diagnostics showed up there.

I misread the OP AMD Ryzen 5 1600 Six-Core Processor Have you looked at this yet? https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-819173

The parity drive isn't even being detected. Actually shutting off *implies* power supply issues or over heating issues. What you'd want to do (if you can't figure it out) is mirror the syslog to flash and then post the resulting file (logs folder) after it shuts off again.

Yeah, disk 1 is corrupted and won't mount. Best to wait for @jonathanm or @JorgeB since it's btrfs

dynamix.cache.dirs.plg - 2020.08.03 There's something in the support thread about not having it scan user shares (only disk shares) to prevent disk spinups incurring.

Unraid does not update anything out of the box. To keep things up to date, install the Auto Update plugin. Which is why you should

Yeah, because you're not touching the appdata (I do it ~1/month to verify it works) Only if you've got custom networks created via the command line then you have to recreate them by hand

Tools - Diagnostics

Tools - Diagnostics

It's nothing to redownload them. Takes a couple of seconds of your time, computer time limited by your modem speed. Apps - Previous Apps. Within that section you can also delete whatever you no longer wish to ever use again.

Post your diagnostics Make sure that it's up to date. After that, post within the UD support thread.

Only thing fundamentally changed was that the system necessitates a re-download of the icons for the containers when first hitting either the Docker or Dashboard tab. If it's unable to do that, then it's going to keep on trying every time you hit it.

Doesn't matter where they go, so long as you're consistent across the arr containers in the path mappings. https://forums.unraid.net/topic/57181-docker-faq/?tab=comments#comment-566086 and also

Do the shares exist when you explore the disks via the GUI?

use https://IP-address and it won't redirect (just acknowledge the certificate errors that will appear) Once you're in, change the DNS server (settings - Network) to addresses other than the router (208.67.222.222 / 208.67.220.220) and go from there.

The drive didn't drop offline, but it does appear to have a bad sector. I'd run a full chkdsk on it in a Windows box.

Writes are always limited by the speed of the slowest drive in the array (in reconstruct mode), or the slowest parity drive (and data drive being written to) in read/modify/write The latter mode (Unraid default) is ~4x slower than the former, but only the drives involved need to be spun up while in reconstruct mode all drives must be spinning. IE: if you've got spinners as the parity drives you will not see any write performance increases at all.

https://www.manualslib.com/manual/1168585/Super-Micro-General-X11ssm.html?page=112

Don't use PiHole, but your DNS probably isn't being set to that IP via your phone.

May 30 16:09:09 Ferrum kernel: mdcmd (36): check correct May 30 16:09:09 Ferrum kernel: md: recovery thread: recon P ... May 30 16:09:05 Ferrum emhttpd: shcmd (53): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker.img' /var/lib/docker 10 # Share exists on disk1 Perfect storm. The system share (which is holding the docker image) only exists on the array (parity protected), and you're currently running a parity check. Ideally, you want the docker.img file to be on the cache drive. The share is set to be cache prefer, but the system can't move any file that's in use, and additionally you have the share set to use "cache" pool, but the drive is part of the "nvme" pool. Set the cache pool it's using to be "nvme". Disable the docker service (Settings, Docker), then run mover. When it's done re-enable. Alternatively instead of running mover, just delete the image and reinstall via Apps - Previous apps.

Do not format A format is never part of the process Wouldn't have been the cause. May 30 12:31:19 Tower kernel: XFS (md1): Unmount and run xfs_repair Run the File system check against disk 1