THANK YOU! THANK YOU! THANK YOU!!!!!!

This is what I needed!

APACHE_DISABLE_REWRITE_IP=1  
TRUSTED_PROXIES=127.0.0.1 
OVERWRITEPROTOCOL=https  

Even without bash, it should still be possible to run podman logs

Could it be something like this?

Check out troubleshooting part here and check what responses you get from inside nextcloud container

It's nice and well integrated. But unfortunately when you have a lot of cards in a board it tends (the board) to slow down. If not for that performance issue it would be absolutely great

Cause found: App formvox broke mimetypes for me. Disabled, it works again. Additionally, I had an incomplete list of mimetypes in db, fixed via occ maintenance:mimetype:update-db

Turns out, the "unscanned" was just a tag from some app. I've remove those. But still the main issue remains: No picture has a thumbnail, all pictures download instead of rendering in browser

I did not find a way to do this. However part of my problem was Caddy reverse proxy not pointing to the right container. Updating my Caddyfile, and running the following solved accessing via my domain or other IPs.

https://docs.nextcloud.com/server/14/admin_manual/configuration_server/occ_command.html#setting-an-array-configuration-value

It's possible that the newer appimage depends on an external newer version of the glibc library, whereas the older appimage bundles it into the appimage.

I tracked down the relevant github issue. That issue is closed and it looks like they implemented a fix already.

Try 4.0.6

Installed the Audio Player app. It's a bit less odd for playing music than the Music app.
... but the Audio Player dashboard widget is worse. So I'm using both apps.

I patched from 31.0.8 to 31.0.12 to 32.0.3. No real problems.
I might get around to fixing these. I tried for a while after I upgraded. No luck.
My API Deploy Damon wont connect and the Websocket looks like I need to install something?

I think I need to do some config on the back end.
The help pages I've found for this stuff are all on github.
There's info there, but they kinda slam through the topic without much explanation.
This is a hetzner default nextcloud setup, so I may well have to refer to their docs too.
My instance works fine; I'm not too concerned about these errors. Any input is very welcome.

Damn. It was worth a shot. There might be a way to turn on more logging, but it's probably not worth the effort diagnosing the issue further. This far into the weeds it won't get you much, unless you want to start making bug reports to NextCloud

Damn. I thought that might be what you meant, but unfortunately it doesn't seem to work. I tried refreshing the page a few times first, and then:

$ sudo journalctl -u docker.service
-- No entries --

And the other two options mentioned on Docker's guide to logs were equally unhelpful. /var/log/syslog doesn't exist, and sudo cat /var/log/messages spits out an enormous amount of stuff, but the most recent is over 3 hours ago and not obviously related to any of this. (Note: it's 16:05 as I write this.)

2025-12-30T02:27:45+10:00 Synology1 synopkgctl[17441]: util.cpp:127 Install extension done
2025-12-30T02:27:45+10:00 Synology1 root[17622]: CS: [start-stop-status]: Synology Drive start...
2025-12-30T02:27:48+10:00 Synology1 redis-server[17759]: oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2025-12-30T02:27:48+10:00 Synology1 redis-server[17759]: Redis version=6.2.19, bits=64, commit=813cfe7f, modified=0, pid=17759, just started
2025-12-30T02:27:48+10:00 Synology1 redis-server[17759]: Configuration loaded
2025-12-30T02:27:54+10:00 Synology1 srvctl[18182]: (18182:59552) [INFO] client-updater.cpp(307): ====== ClientUpdater Starting. ======
2025-12-30T02:27:54+10:00 Synology1 srvctl[18182]: (18182:59552) [INFO] client-updater.cpp(326): ClientUpdater: release version from DB: 46
2025-12-30T02:27:54+10:00 Synology1 srvctl[18182]: (18182:59552) [INFO] client-updater.cpp(596): ====== ClientUpdater Success.  ======
2025-12-30T02:35:55+10:00 Synology1 invoked[9073]: store.cpp:229 failed to parse response: .
2025-12-30T03:10:06+10:00 Synology1 synoconfbkp[10005]: service/auto_config_backup.cpp:231 The key value is empty: priKey_hash
2025-12-30T03:10:06+10:00 Synology1 synoconfbkp[10005]: service/auto_config_backup.cpp:231 The key value is empty: pwd_hash
2025-12-30T03:49:40+10:00 Synology1 invoked[9073]: store.cpp:229 failed to parse response: .
2025-12-30T12:49:52+10:00 Synology1 dlid[15920]: server error. [504]
2025-12-30T12:49:52+10:00 Synology1 dlid[15920]: Error downloading payload
2025-12-30T12:49:52+10:00 Synology1 dlid[15920]: Error execute payload

Piping the output to grep -i next doesn't give any results since I obtained Let's Encrypt certs over a week ago. grep -i docker only gives:

2025-12-30T02:24:32+10:00 Synology1 synowebapi_SYNO.Docker.Container_1_stop[31186]: profile.cpp:1187 WebStation is not enabled

Repeated 9 total times with different numbers in the square brackets, between 02:24:00 and 02:26:00. (Plus some other responses from 2+ weeks ago.)

Yes, when you load the page. The logs for Docker itself would be viewed through SSH using something like journalctl -u docker.service. If you're lucky it'll report something there when you load the page and it makes the invalid request

You might be able to see something from the Docker daemon logs after opening the AIO web UI

Which logs is that, sorry? And I'm guessing you mean when I load up :8080/containers? The page screenshotted in the OP?

I ssh into the Synology and run docker version, then read out the "API version". Is that right?

Yes, API version, specifically the server one.

Running inside Docker is great, except where your program also talks to Docker, in which case the host version can matter. I'm just guessing here, since the log doesn't actually list the url that got a 404, but it would fit the symptoms. You might be able to see something from the Docker daemon logs after opening the AIO web UI.

Interesting, my Synology only has 1.41 as the highest Docker API. It also has the standard /var/run/docker.sock path, no need for the override.

Very interesting. I have a DS923+ running DSM 7.3.2.

Just checking that I'm doing it right. I ssh into the Synology and run docker version, then read out the "API version". Is that right?

Synology’s stuff is often too out of date or customised to run on the bare metal

That was actually why I was hoping to run Nextcloud on it through Docker, rather than running the version of Nextcloud that's in the DS Package Center.

My guess is it’s your API version isn’t actually supported by the AIO code - its asking for something that doesn’t exist in 1.43

Ah damn. That's unfortunate. I was hoping that being only one version behind, the official claim that only the latest version is supported would be more of a "just in case" disclaimer, rather than something that actually causes meaningful issues.

Thanks for the help.

Interesting, my Synology only has 1.41 as the highest Docker API. It also has the standard /var/run/docker.sock path, no need for the override.

I don't run Nextcloud on it though. Synology's stuff is often too out of date or customised to run on the bare metal. Just getting Nextcloud backups working to the Synology with Borg was a nightmare with their weird SSH permissions system.

Judging by that error in the Master container logs and the incomplete status info, it might be failing to get the container status. Glancing at the AOI code, GuzzleHttp is what it uses to talk to Docker, so a 404 there suggests its making a request to docker but that url doesn't exist. My guess is it's your API version isn't actually supported by the AIO code - its asking for something that doesn't exist in 1.43.

Unfortunately, it looks like AIO recently (in the last few weeks) updated and the minimum Docker API is now 1.44, hence that warning you get. I would maybe try 1.41, as that was the previously supported version and is likely to be the most compatible. It doesn't seem possible to downgrade the AIO container either, as that will lock you to the associated NextCloud version.

I would consider an alternative installation method, tbh. A VM on the Synology might work, and let you update Docker independent of Synology's schedule