Squid

Press the "?" icon at the top right for help within any GUI page

On my system using smb shares mounted with UD, that means that I restarted the computer with the shares. But, your probably best off posting the the UD support thread

Post your diagnostics

And although you do imply you did this, have you explicitly set DNS addresses within Settings - Network Settings? Same result?

As stated, you do not need to use the cache drive as a "cache" drive. That's all dependent upon whether the shares are all set to use the cache or not. The usual method of using unRaid and a cache drive is to enable the cache drive, and then disable the shares from using it. If nothing else, it's far far less confusing for everyone (you as why you can't create a cache only share), and us when looking at diagnostics and seeing that /mnt/user exists, but /mnt/user0 doesn't.

Use cache has been disabled. My 6.8.3 system doesn't have a cache drive, and the 6.9 system works differently, but it's either going to be under Settings - Global Share Settings, or Settings - Disk Settings, or Main, Cache, click on cache.

@SidereusAquila, I've moved your post to as it's a general support issue and not CA related per se. (Although I did release a CA update to test a partial resolution to at least one of your issues)

@bonienl. Any thoughts regarding the OP?

TBH, hard not to as it certainly appears to be that That's where it's very interesting. Every download request in CA has a connection timeout of 15 seconds, and a total download time (including connection) of 45 seconds. The docker icon system also uses identical timeouts. Reasoning on this is that if the system can't connect in 10 seconds, then why bother waiting the entire 45 seconds as it'll probably fail anyways But, I just issued a release of CA that has the connection timeout removed to see if it helps alleviate some of these issues, specifically if this improves

Remove the -n flag from the command options and re-run

You need to post your diagnostics then, ideally after doing all of the above

Take this for what it is, as it's not necessarily the problem. You're attempting to use hardware passthrough with a CPU that was released in 2012. Hardware passthrough is highly dependent upon proper support of IOMMU from the cpu, chipset, and BIOS. Historically, this support while being technically available on consumer level products has been present, it has not worked very well until the later generations of cpus / chipsets. This is especially true with regards to AMD instead of Intel. No software can overcome hardware limitations, and unRaid is no different in that respect. What you need to do is see if the restarts happen without the VM service even being enabled. If they don't, then the passthrough support from AMD on that generation is entirely to blame. If they do continue, then it's something else.

Do all of your docker containers have icons or are a bunch the question mark?

You would make the appropriate changes via a script in the /config/go file on the flash drive

Do a scan with fix common problems. As I recall your diagnostics didn't show that it had any problems with internet

Do you already have another container using the same repository (debian?). If so, then under 6.8 the icons will always be identical between the two. 6.9 supports different icons for multiple containers using the same repository.

Painless. Apps previous apps. 5 min later you wont be able to tell that you ever did it

It's painless

Oh and maybe clear your browser cache. I seem to recall that on 6.9 I put in some code changes to handle browser caching in this circumstance

What unRaid version?

Correct. After the image is downloaded, Unraid serves the icon from it's locally stored copy (within the docker.img). Your workaround is to simply change the URL to anything else. Apply it. (Can't remember OTOH if you have to go to the docker / dashboard tab to attempt a new download). Then change the URL back and it'll re-download the image with the adjusted dimensions

Expected behaviour. Once you isolate cores you are isolating them from the OS, so effective the task context switcher won't operate on those cores. What this means is that if you pin a container to multiple isolated cores, it will only execute on a single core. Isolated cores are really for VM use

Yeah, its one thing to pick up RAM that's not listed on the QVL (impossible for any mfg to keep those lists up to date), but quite another to use RAM that's listed on the QVL in a configuration that it says won't work. Personally, I learned along time ago (due to a very similar problem with Windows) to only ever buy RAM from the QVL.

You can try this https://forums.unraid.net/topic/57181-docker-faq/#comment-564326

I'll have to look at it. Not sure why it won't work. What you might try doing though is create a new share on the array, and copy the backup folder into that share. Then on the Backup settings, change the destination to the array share and folder. Reload the tab and see if it picks up the backup set on the restore tab