Squid

exit code from rc.docker stop is not zero in your case so the rest of the commands never execute (&& continues execution if previous return code was 0)

This is what you want to use for the repository entry ghcr.io/mdhiggins/plexautoskip-docker:latest This is the thread you want But it's rather old and most of the images are missing But effectively you add in the applicable ports / paths that the container uses (you garner that from the dockerfile listed) and add them into the template with appropriate host mappings. If you don't understand what path / port mappings actually are, then best to watch Otherwise it is an exercise in frustration on your part.

You need to post the entire diagnostics and the syslog that captured the crash

You're free to contact support as you choose (a link is at the bottom of every page here), and include a link to this post, your diagnostics etc, but answers are likely to be identical to what has already been itemized. Get rid of the zero byte files and reboot. And upgrade the OS version and not downgrade. I don't think so. No different than saying that there's a knocking sound coming from your car when you're talking to a mechanic. In terms of your specific issue, it appears to be actual corruption.

After deleting / renaming, you need to reboot. Won't change a thing. If anything, you should upgrade to 6.11.5

Probably because no drivers are installed for the card. (ie: Unraid does not have drivers for any audio device installed)

Is there anything pulled? Is the status in the docker tab showing an update available??

Orphans happen whenever you make a change to a template and the docker run cannot execute for some reason. It also happens due to a bug in the Apps tab if you update a container from within Apps (and not the docker tab). Orphans are harmless and take up no real space. (Hence why the CA bug isn't a high priority at the moment) Are either of these situations applicable to you?

Your data is all safe. As the banner says, you need to post your diagnostics

Safari issue that comes into play depending upon if certain settings have been changed in the OS. Fixed next rev

Different, but related, and also fixed. My testing on that did show that cookie clearing did fix.

I now have a profound appreciation of just how messed up Safari is Anyways, this should be fixed on the next rev of CA (Monday ish release)

The next revision of CA will fix the issue some users have with crashing when running Safari on a actual Mac. Release probably happening on Monday. Root cause: Safari operates differently than every other browser past, present and future if and only if you've made a change to the font-size (possibly other entries) in Settings - Font Size that the OS uses. Clearing history and cookies on Safari will also fix the issue in the meantime.

Have you tried setting a Trim Schedule (or Trim now) in Settings, Scheduler?

https://unraid.net/contact

Yeah. inadvertent change to the .plg that messed it up. If it was summer and I had a pool, you have permission to beat me with a wet noodle

Does it work if you uninstall Dynamix Share Floor?

Do you only have a 100Mb/s switch?? While not impossible, it would be very rare. If you don't, you have a network cable running to your switch / router as it's only connecting at 100mb/s instead of the usual 1000.

Close the banner.... Won't bug you again for 30 days (6.12) or unless you close your browser (6.11)

Can you post your entire diagnostics

You probably dislodged slightly the cable to the drive. Reseat the cabling (both ends)

Yes

The container port is NOT 8080. The container port is 80. The host port when you add that is 8080, and the webUI as mentioned should be as I wrote above. You need to remove that port and then re-add it Also, should be noted that since you're giving the container its own dedicated IP, all the port mappings are ignored anyways. The container will always use 80. Port mapping only works (by design) in bridge mode. It doesn't make much sense to map the ports in any other mode.

Have you run a memtest for a minimum of a pass or two? (If you're booting via UEFI, then you will need to switch temporarily to legacy boot or set up another stick to run https://www.memtest86.com/) Another (unlikely) possibility is do the CL timings match on your mismatched sets of memory? Is no change, enable the syslog server (mirror to flash) and after it reboots, post the resulting syslog contained within /logs on the flash drive