Squid

Settings - Global Share Settings Did you only include certain drives (usually no reason to either include or exclude any drives on that page)

Apps - Previous Apps and check the stuff off

Wow. I'm impressed that someone even looks at it.... Fixed. (Weird markdown syntax error)

Today's update brings forth 2 things. Stopping a forth-coming long-awaited and major plugin (Soon TM) from appearing on spotlight apps on incompatible systems A warning / reminder to adjust host ports when installing a plugin that has conflicting ports to a service / app already running on your system You may see something like this: This app wants to use certain ports that are already allocated by either a native Unraid OS service or another app running on the server, and is simply a "reminder" to look at and change the host ports on this app so that they don't conflict. Currently this should work against ~90% of the apps, and the remainder 10% either are not affected (run as host and can't be checked) or are v1 templates only which requires an overhaul to the appfeed to accomplish this. (soonish) With luck this will lessen the support load on the very talented template authors / maintainers that contribute their various apps. Any false positives etc please let me know.

There's a process involved Long thread, but find your controller in it

ECC buys you more time before having to replace a stick due to bad memory, but doesn't prevent bad ram from happening. Also, you're running the memory at an overclock (XMP/AMP). The maximum supported speed on Ryzen 3rd gen is 3200 (https://forums.unraid.net/topic/46802-faq-for-unraid-v6/page/2/?tab=comments#comment-819173) You're running it at 3600 and the native non-overclocked speed of the RAM is 2133 This doesn't help with memory issues.

Jan 1 21:21:48 EDITH kernel: BTRFS info (device dm-2): bdev /dev/mapper/sde1 errs: wr 0, rd 0, flush 0, corrupt 67, gen 0 Jan 1 21:21:48 EDITH kernel: BTRFS info (device dm-2): bdev /dev/mapper/sdc1 errs: wr 0, rd 0, flush 0, corrupt 98, gen 0 That's the start of this all. BTRFS is finding corruption. The easiest way for this to have happened is via bad RAM. Run a memtest for a couple of passes

Nothing relevant in the logs as it's nothing but Jan 1 22:24:16 mhions-storage smbd[16660]: [2022/01/01 22:24:16.254604, 0] ../../source3/lib/sysquotas.c:565(sys_get_quota) Jan 1 22:24:16 mhions-storage smbd[16660]: sys_path_to_bdev() failed for path [.]! over and over (and over) again. Not sure what that's about. But, so far as the disk is concerned, run the check filesystem against it

And unless you're having problems, perfectly safe to disable mover logging (settings - Scheduler, mover settings). It just takes up syslog space for no reason

Reboot will probably fix you up.

Look for BIOS updates, and verify the boot order (ideally hard drive boot as 1st priority with the USB as the first BBS priority).

Those are the encrypted devices in the array

Post your diagnostics

Close all browser tabs opened to the server (ideally close all browsers period)

Probably (hopefully) goes without saying, but do NOT hit format

Post in the unassigned devices support thread and include your diagnostics

Everything works fine for me on Yes, and ones which are set to "No" when update all is yes still update properly. Any connection problems to the internet? Is the server running at the schedule you've set?

you have to copy it to a place the container has access to (/mnt/user/appdata/gunbot)

It's on the boot menu. If it doesn't load, then temporarily switch your boot method to Legacy in the BIOS 20G is good enough for the vast majority of users Use Mover to get everything off of the cache drive (stop the docker service and set the appdata share to be useCache: yes Alternatively, back up the appdata with the appdata backup plugin (destination on the array) and when ready, restore it back to the cache drive

Add on sata controllers and forget about onboard ports

The docker image has issues probably due to the cache having some issues Jan 2 05:52:51 HunRAID01 kernel: BTRFS info (device sdl1): bdev /dev/sdl1 errs: wr 0, rd 0, flush 0, corrupt 9, gen 0 Not a BTRFS guy, so others (eg: @JorgeB) will help there. I'd still recreate the image though after the cache issue is fixed up. Also, why a 256G docker image?

Look at SWAG, and the various walkthroughs. There may even be a video. Can't remember VNC and a VM however is quite possible the easiest method although it is the least efficient. Personally, since I have another Windows system on 24/7, TeamViewer works fine for my use-case

Apps - Previous Apps

What about disk 7? Dec 29 13:57:02 Tartaros root: Fix Common Problems: Error: disk7 (ST31000528AS_9VP091TC) is disabled Your first step in the image filling up is to go to Docker, then hit Container Size which should help you see which app is filling it up, then peruse the contents of the Docker FAQ thread here which has multiple entries on the image filling up.