Squid

The primary venue for support on LinuxServer containers is via their discord. See https://github.com/linuxserver/docker-digikam/issues/new/choose

Click the icon and then hit "Edit" and switch to advanced view and get rid of all the devices (either its listed under extra parameters or under show more options)

Run check filesystem against disk 1 (And also run a memtest to rule it out as a possible source for this problem)

https://forums.unraid.net/topic/57181-docker-faq/page/2/#comment-566087

Did you have a cache drive? After the reboot, both the docker image and libvirt image were re-created onto disk #5. If you did have a cache drive, it's not appearing at all. If you didn't have a cache drive, then Apps - Previous Apps and check the stuff off will fix you up (Also, no need to upload diagnostics to a 3rd party site. You can attach them directly here (and that is preferred))

So it sounds like you've forwarded the ports to allow you direct access to the OS without going through a reverse proxy or VPN? If this is the case, it's not a matter of absolutely zero attempts to access it, but only a matter of WHEN someone will access it. Without the 15 minute timeout, all any script kiddie has to do (once they find the open port, which they will) is simply keep trying passwords until they succeed. Doesn't matter how hard of a password it is, brute force will always eventually succeed. 15 minutes massively slows them down. And, no it cannot be disabled without modifying the code / internal config files etc 6.10+ has the philosophy of security over convenience due to the current world which we live in.

If the container doesn't support setting PUID / PGID then it doesn't support doing it. What containers? This doesn't seem correct that they won't boot if you don't set the permissions on appdata to be 0777. Now, if they boot, but YOU can't access the files within appdata, then that's a different matter....

Or a more roundabout way is to set up a barebones VM that uses VNC. This you can access via MyServers no problems. Within that VM you can then access any of the apps.

Settings - Date & Time - also set up the NTP servers (time1.google.com, time2.google.com, time3.google.com, time4.google.com)

Pretty sure that linuxserver no longer supports this app at all. BUT, from what I remember years ago you had to initially set up how the library gets scanned etc on another "real" Kodi instance and then copy over advancedsettings.xml and sources.xml from that instance to the headless one and then you use the headless app as the target when you tell radarr etc to update the library. You're also going to odds on use MySQL / MariaDB to hold the database More info here on that app thats currently in CA https://github.com/matthuisman/docker-kodi-headless But to be honest unless things have changed Kodi-Headless was always a "hack" that mostly worked and you're better off just having your Kodi boxes set to rescan the library when starting and the library is stored on a MariaDB docker instead of internally.

By design it has to be a remote path in the template. After the initial download it is saved. If you can't upload (or find) an image you like remotely, then you can manually copy the appropriate file to /var/lib/docker/unraid/images with the correct naming

Yeah, currently the stats are returned directly via "docker stats" divided by the core count in the system (so it's normalized to a max of 100% - docker stats by itself would actually return 0.52*32 = 16.64%) While I don't have any real issues with what you're proposing, one downside is that if you ever add up the percentages they could quite easily exceed 100%

There's 3 showing with a cable plugged into one of them Settings for eth0: Supported ports: [ TP ] Supported link modes: 100baseT/Full 1000baseT/Full 2500baseT/Full 5000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 100baseT/Full 1000baseT/Full 2500baseT/Full 5000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: Unknown! Duplex: Unknown! (255) Auto-negotiation: on Port: Twisted Pair PHYAD: 0 Transceiver: internal MDI-X: Unknown Supports Wake-on: pg Wake-on: g Current message level: 0x00000005 (5) drv link Link detected: no driver: atlantic version: 5.10.28-Unraid firmware-version: 1.5.44 expansion-rom-version: bus-info: 0000:0c:00.0 supports-statistics: yes supports-test: no supports-eeprom-access: no supports-register-dump: yes supports-priv-flags: yes -------------------------------- Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: Unknown! Duplex: Unknown! (255) Auto-negotiation: on Port: Twisted Pair PHYAD: 1 Transceiver: internal MDI-X: off (auto) Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: no driver: igb version: 5.10.28-Unraid firmware-version: 0. 4-1 expansion-rom-version: bus-info: 0000:08:00.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes -------------------------------- Settings for eth2: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on Port: Twisted Pair PHYAD: 1 Transceiver: internal MDI-X: on (auto) Supports Wake-on: pumbg Wake-on: g Current message level: 0x00000007 (7) drv probe link Link detected: yes driver: e1000e version: 5.10.28-Unraid firmware-version: 0.2-4 expansion-rom-version: bus-info: 0000:00:1f.6 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes --------------------------------

The mce happened during processor initialization and is perfectly normal for some combinations of hardware and isn't your issue.

As in what? When booting up you get a ton of text scrolling by and then it winds up at a blank screen? Boot into the non-gui mode

And the KVM suggestion was to simplify things as it's causing issues (I seem to recall when I had a KVM on my system it did the same thing -> poor design of the KVM when it's not switched)

I deleted that comment, as it was actually your unassigned disk that you then began to preclear

Nope. There's nothing to signify any reason for loss of data. TBH, the usual cause of loss of data is user error, especially if there's no corruption on any disk.

Try getting rid of the KVM. It's having constant reconnections spamming the logs

Navigate to https://ip-address (note the "S"), accept the warning then from Settings - Management Settings update the DNS record

I'm sure it's possible if you know how to arrange network rules etc. But it's far easier to simply connect the 2.5 switch to the extender instead, unless the switch is even farther away from the AP than the extender is and will massively slow down your internet access even more.

Maybe I'm missing something here. You've got 2 cables coming out of the server. One is winding up at the AP and one is going to the 2.5 switch? What I'm suggesting is simply move the cable feeding the internet to the computer to instead feed the switch.

It's all the same... The AP is acting as a switch. If you connect the 2.5 switch to the AP you've got a single connection with no loss in speed in inter-communications

10:1 it's simply a connection issue and will wind up eventually happening again. Hard to say since the diagnostics are from after the reboot. Yes Are the counters increasing though? What does the Array Operations tab say about it proceeding?

Connect the 2.5G switch to the router (or the switch following it if you have one) Everything connected to the 2.5G switch will communicate with each other at 2.5 regardless of what the speed of the router / switch it's connected to is.