ezgoodnight

Checking traceroute and mtr to hub.docker.com shows that when my downloads are slow, my whole network is getting a pretty insane amount of packet loss (20-60% loss) from several of the hops, with more than a few timing out entirely. Other threads I've seen about slow docker layer downloads (non-Unraid posts) all seem to be investigating that and getting similar results to mine. I got faster results from a traceroute today and my containers updated very fast. This could be a coincidence, but logically it follows. The non-Unraid posts elsewhere have said this could be an issue with your ISP, something you would have to take up with them. I have not spoken to mine yet but wanted to post this information in case it helped anyone. Are the layers hosted anywhere but Docker Hub? With Github I AM getting a lot of timed out hops and packet loss. It could be depending on where the layer or data is pulled from it is very slow. I don't know enough about the infrastructure to know which are hosted privately. mtr and traceroute to linuxserver.io and github.com are both giving me similar packet loss to what I had earlier when I was checking hub.docker.com so part of the intermittent issue, for me at least, is when it is pulling from multiple sources, each have their own latency (for various reasons). I guess do your own network tests and contact your ISP if you think it will help. I think that is my next step if the slow downloads continue.

Just starting to look for a fix, but I'll also chime in that this is happening to me often, same timeframe of past several months. With me it's intermittent. Today updates are taking forever. Some layers download just fine, others are really slow.

Similar to other users with an old version, I'm getting a login issue with the current version of this container. All versions have run just fine for more than a year now. Plex.tv sees the login and authenticates it (I see it in my account), but the Overseer app stays stuck at the login page and I get this in the logs: Scan interrupted {"errorMessage":"Permission denied even after attempted authentication :( Wrong username and/or password maybe?"} It stays stuck on the login page after authentication and I am prompted to close the window. I saw "DNS issue" regarding this earlier in the thread. I recently started hosting a Technitium container but I don't think that would be the issue. I tried logging in on a device that is using my ISP's DNS with the same result. Some more information I'll add: I was logged in before all of this, as I was troubleshooting why SuggestArr stopped working, none of the suggestions I got notifications for were in my Overseerr. I logged out of Overseer to authenticate with my new password because of the recent data breech. And now I'm stuck on the login page. This seems to be affecting SuggestArr as well, but this is possibly because it cannot connect to Overseerr. I've reinstalled the container after removing. Tried deleting the folder in appdata, and that did not fix the issue so I restored the backup. Update: I tried deleting perms.txt, no change. Update 2: UGH IT JUST STARTED WORKING. Trying a Fourth browser on a third machine after leaving it off overnight and it authenticated correctly. Maybe some service was down that came back up over that time. I have no idea but it just behaved normally.

The easy fix was removing the container and setting it up again. It was like losing nothing because everying was still in appdata. Just now one of my other computers was getting the 400 Bad Request and the fix was clearing the cookies in the browser I was using. Everything is normal now. Thanks for the answers.

Upgraded to the new container available just now, the WebUI no longer comes up (400 Bad request) and the logs end in: Critical: libusb_init failed Search is telling me that this is not a problem so it is possibly just a coincidence I'm seeing this error in the logs and something else is stopping the webUI from loading. Any thoughts appreciated, these plex containers have run flawlessly for more than a year only to be borked by this. Edit: I did a backup of the folder in my appdata, then uninstalled the container and reinstalled it from Community Apps. This did fix the 400 Error (I can get into Plex WebUI now) but I still have the libusb_init failed error. The pages on this were probably right and this is unrelated to whatever issue was breaking the WebUI or server app. In any case the fix seems to be a simple Uninstall/Reinstall, although I also went to the trouble of rebooting the containers and then the machine (it did nothing).

The web UI keeps crashing, this is the second time I've had this issue today. This is what the log says: 2025-03-07 10:37:43,354 DEBG 'start-script' stdout output: [info] rclone finished, sleeping 24h before re-running... 2025-03-07 10:37:43,354 DEBG 'start-script' stderr output: /bin/bash: line 1: log_rotate: command not found 2025-03-07 11:25:43,365 DEBG 'start-script' stderr output: Enter configuration password: password: Restarting the container will get me past this problem, but it keeps happening. I'll have go back and read through the thread to see if there is an explanation of what rclone is doing. Edit: OK, so clicking "configs" in the web UI is what brings up configuration password which is making me thing something is configured wrong and it can't unlock the conf file? Edit 2: I am able to stop this crash by removing the password and encryption from the conf file, which isn't ideal.

Like Argus, my web UI had -stopped- working and the logs confused me at first because there were no errors, this was marked as a warning. Whatever the case, running this command and setting up a password for the conf allows the web UI to load. Did the paths change in an update? rclone config --config /config/rclone/config/rclone.conf I seem to remember having an issue with the authentication, but I don't remember the fix. My problem when I first set up my container was more like what Argus is describing. This conf issue stopped the UI from listening on port 5572 completely.

I was stressed to have this issue after upgrading to 7.0.0 this morning. This quite easily solved the problem. Thank you.