I’ve just updated four apps, three of which have failed to restart after the upgrade. app_lifecycle.log (attached) says:
(ERROR) app_lifecycle.compose_action():58 - Failed 'up' action for 'netdata' app: Timed out waiting for response
and
(ERROR) app_lifecycle.compose_action():58 - Failed 'up' action for 'filebrowser' app: permissions Pulling \n init Pulling \n filebrowser Pulling \n filebrowser Error Get "https://registry-1.docker.io/v2/": context deadline exceeded\n init Error Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)\n permissions Interrupted\nError response from daemon: Get "https://registry-1.docker.io/v2/": context deadline exceeded\n
and
(ERROR) app_lifecycle.compose_action():58 - Failed 'up' action for 'plex' app: Timed out waiting for response
There’s also a very long line I won’t post in here which shows that the Plex update was downloading, but then seemed to fail, spawning a long series of retry countdowns ending with
Downloading \ncontext deadline exceeded\n
I think this is a problem at the other end, but could it be at mine? And how might I address is if it is?
Update: I tried to install a second instance of Plex as a test, and that failed as well with the same “Timed out waiting for response” entry in the log. Can anyone please advise?
I’ve tried to restart them manually several times over the last 24 hours, none of which have worked. Can I change the timeouts? I have almost zero worthwhile knowledge of Docker, so I don’t know how to do this, even if it’s possible.
The log I’d previously attached doesn’t contain much that makes sense to me. There are timeouts:
[2026/08/10 20:01:41] (ERROR) app_lifecycle.compose_action():58 - Failed 'up' action for 'plex' app: plex Pulling
\n plex Error Head "https://registry-1.docker.io/v2/plexinc/pms-docker/manifests/1.43.3.10861-07dfddaeb": net/http: TLS handshake timeout
\nError response from daemon: Head "https://registry-1.docker.io/v2/plexinc/pms-docker/manifests/1.43.3.10861-07dfddaeb": net/http: TLS handshake timeout\n
I looks to me like it’s trying to reach files held on registry-1.docker.io and either failing to connect or failing to get a response in time, then giving up. Is this a fair reading?
I’ve just installed 25.10.5 in a VM and tried to install the problematic apps there, and all three installed successfully. I’ll try updating my physical server to .5, maybe that’ll help.
Response in the VM was exactly the same, albeit faster. Same response in an Ubuntu VM. I’m also trying to set up Windows Subsystem for Linux so I can test it there, but the installation has stalled for some reason.
For reference, in case it makes any difference, the VMs are running on my desktop, not my server, and while both physical machines use the same internet connection, the powerline network adapters connecting everything give a slower connection to the server.
I’m wondering if some of my problems are caused by my LAN and/or internet connection (it was upgraded last week, but I haven’t experienced any problems with it since then). When I updated the real server to .5, the update page didn’t initially show the normal update, only the manual option (which I think might not be possible, unless I change off of the General train). Next attempt gave an EFault saying it had timed out while downloading the manifest. Third attempt worked, of course.
Edit: curl in WSL gives exactly the same response as the other three.
I thought that maybe the problem was caused by a bug in the latest app releases, so I thought I’d roll them back to the last one: TrueNAS says it’s not possible to do this with the app in stopped state.
One of the apps, File Browser, is now showing another update, version 1.4.28, which seems to have been released shortly after I updated yesterday. TrueNAS won’t install this update because, as with rolling back, it says that the app cannot be updated while in a stopped state.
Of course, since I can’t start these apps, I can neither update nor roll them back.
The errors are due to docker.io blocking your connection. You’ll need to create an account and then perform docker login from the shell with your new account to docker.io.
It’s to prevent abuse on docker.io servers. You’re starting to pull enough images to hit the unverified limits. Just create a free account and log in and you should be good. I ran into this exact issue a few weeks ago.
Update: I bypassed my miserable powerline network and ran cables. The affected apps started immediately, and I was able to update one of them as well. No errors were thrown, given the lack of new entries in the logfile.
I didn’t have to create a docker.io account, so I assume that I wasn’t actually being blocked at that end, rather that something in my LAN was just so substandard that it was throwing things off somehow. It remains to see whether it goes back to being a mess when I remove the cables.
