I'm running Docker on a UGREEN DXP4800+, and immediately after the latest Docker update my containers either stopped starting or became inaccessible. Portainer reported that the /var/run/docker.sock mount could not be found, while other containers such as Jellyfin failed during startup. Redeploying containers also failed, so I exported my configurations and images, uninstalled Docker, reinstalled it, and tested with a fresh Kavita deployment.
Kavita now appears to start successfully and reports that it is listening on port 5000, but I still cannot access it locally. The same is true for Jellyfin, Navidrome, Seerr, Nginx Proxy Manager, and my other services. Kavita's logs mainly show a failed attempt to contact its update service, followed by a successful local connection to port 5000. I'm new to Docker and would appreciate help determining whether this is a missing docker.sock mount, a Docker networking problem, or an issue with the NAS firewall. These services worked reliably before the update.
3 Answers
Before reinstalling or importing more configurations, confirm that the recreated containers still have the expected host-to-container port mappings. Kavita listening on container port 5000 does not automatically make it available externally; the port must be published, for example as a host port mapped to 5000. The same applies to Nginx Proxy Manager and the other services.
Updating Portainer may be worthwhile, but it will not fix missing port mappings or a broken Docker bridge. Check the network mode, published ports, firewall rules, and Docker daemon status first.
The missing `/var/run/docker.sock` message is a separate Portainer configuration problem. Portainer needs the Docker socket mounted inside its container, but that error does not normally explain why every other application is unreachable. First verify whether the Docker daemon and socket actually exist with `systemctl status docker` and `ls -l /var/run/docker.sock`.
If the socket path moved after the NAS update, recreate or edit the Portainer container with the correct host path. Also check that Docker is running normally and review the daemon logs before importing more containers.
The Kavita log indicates that the application itself is running: it is listening on port 5000 and its internal health check succeeds. The update-check errors are probably unrelated noise caused by the container being unable to reach the internet.
Because every service became unreachable at once, check Docker’s published ports and bridge networking rather than troubleshooting each application. From the NAS, compare the container’s configuration with the exported setup using commands such as `docker ps`, `docker port kavita`, `docker inspect kavita`, and `docker network ls`. Then test the host-side port with `curl http://localhost:`.
If the curl test works on the NAS but not from another computer, the NAS firewall or LAN access rules are likely blocking the traffic. If it fails on the NAS too, Docker may not have rebuilt its NAT rules correctly. Restarting the Docker service or Docker application—and, if necessary, rebooting the NAS—often rebuilds those rules.
I also tried importing my Nginx Proxy Manager configuration, but creating that container failed with a generic startup error. I’ll check the daemon status, socket path, and port mappings before trying another import.