What should I do if the Docker container cannot start after the NAS is restarted? Check these three places first

Last month, the power switch tripped at home. When the NAS called, it started up on its own. I was quite happy. As a result, the mobile phone could not connect to AdGuard Home, the TV turned on Jellyfin and started spinning around, and the downloader also pretended to be dead. After logging into the background, I saw that only 4 of the 9 Docker containers were alive, and the remaining 5 were all lying on the ground. My first reaction was to delete and reinstall, but later I found out that it wasn't that far.

This article walks through my demining process. If your NAS is like this, don’t rush to pull a new image. Check the following three places. In most cases, you can get it back within ten minutes.

Let’s break things down into two levels first: The rise of NAS does not mean the rise of Docker

This is where newbies are most likely to panic. NAS system startup, hard disk identification, and shared folder mounting, this is one layer ； The Docker engine starts and then pulls up your pile of containers one by one. This is another layer. The two are not synchronized, let alone packaged.

After my trip, the Feiniu NAS system returned to normal within ten minutes, and files could be opened, but the Docker avatar didn't seem to receive the notification. It is very clear at a glance using the command line. SSH in and type docker ps -a , if it shows Exited, it means it was not woken up correctly the last time it was shut down or restarted. The only ones that are really running are the ones at the beginning of Up.

So the first step is not to repair the container, but to confirm its actual state. Many tutorials ask you to delete the image as soon as you come up, which is equivalent to restarting the router and then reflashing the system. First, check the table below:

first place: The restart policy is not enabled, or it is enabled but not written correctly.

Docker has its own set of restart strategies, and there are only a few commonly used ones.: no means it will never start automatically, always means it will be pulled up as long as the Docker engine is on, unless-stopped means it will be pulled up automatically unless you stop it manually, and on-failure means it will be pulled up only when it exits abnormally. For the resident containers on the NAS at home, I usually let them eat unless-stopped.

Of the five containers that I didn't wake up this time, two of them did not enable automatic restart. When I first installed it, I followed the tutorial and clicked Next. I didn't pay attention to this switch. I rarely restarted the NAS, so the problem was always hidden. It wasn't until the circuit breaker tripped that the original shape was revealed.

If you have SSH permissions, you can add it with just one command.: docker update --restart unless-stopped 容器名 . Don’t be afraid if you don’t have SSH. The web backends of Synology and Feiniu have corresponding check boxes. I’ll explain the location later. After changing, don’t just change one. Go through all the permanent items I installed to save you having to fish them out one by one next time.

But there is an exception here and I want to make it clear: unless-stopped is not a panacea. If you manually click on a stopped container, it will not get up by itself just because the NAS is restarted. This is the original design. There is also a situation where the container starts up and exits immediately, and the restart strategy will repeatedly pull it and fail repeatedly. In this kind of cycle, it is useless to look at the status. You have to check the logs and start reporting errors. That is no longer the fault of the strategy.

A more specific startup sequence issue is related to the restart strategy, but the pitfall is not in the strategy itself. For example, when Jellyfin mounts a hard disk that is not yet in place, the container is indeed pulled up, but the directory it requires is empty or does not exist, and the process exits after a few seconds. At this time, you can't see any results even if you stare at the restart strategy for a day.

second place: The startup sequence is wrong, Docker runs ahead of the hard disk

The one I was most wronged about this time was qBittorrent. Its download directory is located on a USB external hard disk. After the NAS restarts, the system runs Docker first, but the USB disk is still on the way. When I stood up the container and took a look, the mounting points were empty and all download tasks were marked in red. When the system mounts the disk, the container will not recognize itself again, and it will be stuck there.

This problem is characterized by: You manually restart the container and it works normally again. Because the hard drive was already mounted at that time. The judgment is also simple. First check whether there is no such file or directory in the error log, and then check whether the path on the host machine exists.

I have two native methods. One is not to put the container's data directory on a disk that is prone to late arrival, such as a USB disk or a slow mechanical disk. Don't put key containers if you can. ； The other is to add a delayed start to the container, or set it to retry after failure, and wait until the disk arrives before running. In the web backends of Synology and Feiniu, you can see switches such as "Automatically start at boot" when editing containers. Turning it on is just the first insurance. What really needs to be solved is the order of startup.

If you have docker compose, you can write it in the service restart: unless-stopped , and then give the dependent volume a health check. But there are many web backends used at home, so there is no need to bother with compose just for this matter. What I'm doing now is: The download disk is set separately, and important containers use built-in storage by default, which means one less variable and one less mine.

The third place: Half of the ports, paths, and configurations were changed, and they were only exposed after restarting.

There is an even more annoying situation: The container usually runs fine and you haven't touched it, but as soon as the NAS is restarted, it starts up and then backs down. This is probably because a certain configuration file was written incorrectly, or the port is occupied by another container, but I have never had a chance to rerun it before, so it was not exposed.

The one I stepped on was AdGuard Home. After changing the upstream DNS, I saved half of the configuration. The webpage did not report an error, so I thought it was successful. After restarting, the container keeps Exited (1), and there is a sentence in the log that configuration parsing failed. Delete the extra half line in the configuration file and start it. This kind of thing never happens at all, because the container has not been restarted and the bad configuration has not been read.

So as long as you see a non-0 number after Exited, first docker logs 容器名 Look at the last few dozen lines. Don’t be afraid of reporting errors in English, just look for a few keywords: no such file, permission denied, address already in use, config. It doesn’t matter if you don’t understand it. You can still locate the error by just sending it to search. I was really too lazy to read the logs, so I checked the port, path, and environment variables in the original configuration of the container. Most of the pitfalls were hidden in these three.

I will talk about the port conflict separately. After the NAS is restarted, the container startup order is not exactly the same. The two containers may grab a port 80 or 53 at the same time, and the latter one cannot be started. AdGuard Home and other DNS services are installed on the same machine, so it is especially easy to fight on 53. Make a mental note before installation, don't just plug a bunch of containers into the default port.

Where is the "auto-start" function of Synology and Feiniu?

I've used both backstages, so I'll write down the entrance location to save me from rummaging through it.:

The two systems have different names, but the meaning is the same. Don't close the window after turning on the switch. Manually stop the container on the spot and start it again. Only when it gets up can it really take effect. I tried this when helping a friend to watch Synology. One of them turned on the switch but did not click Save. As a result, the next time the power was cut off, it still lay flat.

If your NAS does not use Docker at all and only has a few built-in applications such as photo albums and file sharing, then this article will not be useful for the time being. But as soon as you start playing Docker of Feiniu NAS , sooner or later, you will encounter a situation where the containers are not neat after a restart.

I really can’t get up, so I’ll take two steps to save myself.: Read the log first, then rebuild

After checking the first three places, most of the containers can be retrieved. If it really doesn't work, don't delete the data volume directly. Do two steps first:

• See full log: docker logs --tail 100 容器名 , adjust the error time to after the NAS is restarted, and do not regard the old logs from a month ago as the cause of the disease.
• Look at mounts and networks: docker inspect 容器名 It's very long. Newbies can just search Mounts and NetworkMode to confirm whether the path and network are what you want.

If it still doesn't work, consider rebuilding. Rebuilding does not mean deleting data, but retains configuration files and data volumes, and only rebuilds the shell of the container. Both Synology and Feiniu web backends have entrances for exporting or rebuilding. Before starting, take a screenshot of the configuration, including the environment variables, ports, and paths. I didn't take a screenshot at first, so I reconstructed it from memory, missing the PUID and PGID, and the folder permissions were a mess.

Finally, the ending. Don’t mess up the order: First docker ps -a Look at the status, then look at the restart strategy, then check the startup sequence and mounting, and finally it’s the turn of logs and rebuilding. Usually, when you finish loading the container, you can easily handle it The account number of containers and memory Remember, don't wait until something goes wrong to remember who is running.