-
7.3.0 - Docker containers not starting, container name already in use error
UPDATE: Removing Docker.img one more time, then restarting, then recreating Docker.img finally allowed my containers to launch. I'm certain @Kilrah was correct and the issue was with thr RAM-Disk for Docker Logs plugin after all.
-
7.3.0 - Docker containers not starting, container name already in use error
I thought you were on to something but I've removed the plug-in and rebooted and am getting the same error
-
7.3.0 - Docker containers not starting, container name already in use error
Just upgraded to 7.3.0 from 7.2.6. Many of my Docker containers didn't auto start and were missing on the docker page. Trying to re-add the container from template results in the following error: docker: Error response from daemon: Conflict. The container name "/redis" is already in use by container "55e3df3eac0373e6d7df884f1cae5b83246d05c80b9f8cc291e8546c5a31cf40". You have to remove (or rename) that container to be able to reuse that name. In an effort to mitigate I deleted docker.img using the toggle on the Docker settings page. I then had docker.img recreated. Now the containers that were launching post upgrade are getting the same error when trying to recreate from template. I have also restarted but continue to get the error. Diagnostics attached. tower-diagnostics-20260513-1213.zip
-
-
[PLUGIN] WireGuard Watchdog
This redirects any docker containers with Host networking through wg0, at least it did for me. Uninstalled.
-
Unraid no WAN connection
This is wild. Finally looked in my OPNsense logs and can see that Crowdsec was blocking all traffic from my server: Removed that decision, and immediately everything on Unraid started working again. Crowdsec shows it was a decision based on firewallservices/pf-scan-multi_ports from 4 hours ago, which is how long I've been scratching my head over this.
-
Unraid no WAN connection
root@Tower:~# cat /etc/resolv.conf # Generated by rc.inet1 nameserver 208.67.222.222 # eth0:v4 nameserver 208.67.220.220 # eth0:v4
-
Unraid no WAN connection
Hi all. This morning I noticed that my Plex and all other docker containers were unable to reach the WAN. Also, when I open the Log or Shell windows in Unraid's UI I get just a blank window, and Community Apps says it can't reach anything. I have changed my server's network DNS config from Automatic, to OpenDNS's IPs but it didn't help. If I try to ping or nslookup from an ssh session I get no response: root@Tower:~# ping google.com ^C root@Tower:~# nslookup google.com ;; communications error to 208.67.222.222#53: timed out ;; communications error to 208.67.222.222#53: timed out ;; communications error to 208.67.222.222#53: timed out ;; communications error to 208.67.220.220#53: timed out ;; no servers could be reached All other devices on my network are functioning. I don't really understand what the issue could be. Diagnostics attached. Thanks! tower-diagnostics-20260409-0933.zip
-
Array files on Cache Drive don't survive a reboot?
In the reboot to install 7.1.3 I experienced the issue again, so I looked into it further and I believe it had to do with ZFS dataset vs a directory on ZFS. I ran mover to clear everything out of the Data share on my cache, then stopped all dockers and deleted the Data share from cache entirely. Then I rebooted again, and the Data share reappeared, with old files in it that had been moved weeks ago. After verifying that those files had in fact been moved to the array, I deleted the Data share from cache again, rebooted, and this time there was no Data share upon reboot. I then wrote a file to /mnt/user/data and confirmed that it was created on the cache drive. It's been several days, and I've run mover and rebooted a few more times to test, and everything is working as expected. Oh, and I have SABnzbd writing to /mnt/user/data instead of /mnt/cache/data.
-
Array files on Cache Drive don't survive a reboot?
Oh good call. I'll give it a shot.
-
Array files on Cache Drive don't survive a reboot?
Thanks so much much for the reply. tower-diagnostics-20250506-1954.zip
-
Array files on Cache Drive don't survive a reboot?
I have SABnzbd downloading files to: \mnt\user\data\usenet\complete\tv And Sonarr moves the files to: \mnt\user\data\media\tv This move happens basically instantly, because the share is Data and everything is happening on my Cache Drive and they'll remain there until Mover runs. But if I reboot the server before running Mover, the array files on the Cache Drive will disappear. Everything else on the Cache Drive will be intact, just not the individual media files moved by Sonarr, Radarr etc. Also, I've observed that while the media files aren't visible in the file system, the space reported used on the Cache Drive will be inclusive of those media files. I've been running Unraid for over a decade, but never experienced this behavior until recently, after a power outage last week, when my UPS kept the server online until initiating a graceful shutdown, and again yesterday, when I rebooted to perform the upgrade to 7.1.0. In both instances, later on that day, I noticed that files that had downloaded since the last time Mover ran were now missing.
-
Intel Arc A380 Fan Control
I searched the forum but didn't find anything about controlling the fan of an Intel Sparkle A380 card. The fan on mine spins up and down constantly at idle. It's not a big deal, and only noticeable because my desk is right next to my server, but wanted to know if anyone has found a solution to the ramp up and down. Power states maybe?
-
Mover consumes all disk IO/usage causing plex to buffer.
I agree with OP. I've been trying to use the new feature of mover in 7.0 to empty a drive but it seriously makes everything else lag.
-
Unraid Fan Control Script
Finally got around to installing and configuring this. Works great!
-
[Plug-In] Community Applications
Hello. I'm running 7.0 and everything in CA had been working fine but now Action Centre isn't loading, even though I have a Docker container with a pending update. This was working yesterday, but isn't working today. Is this an issue with 2025.01.15b or should I look elsewhere for a root cause?
adammerkley
Members
-
Joined
-
Last visited