Issue: The limits of the cloud?

Issue: The limits of the cloud?

I had a nasty problem today with my Hub at hub.hubzilla.hu.

I uploaded four images to the cloud for two posts and, to do so, created a subdirectory called “2026-09-04” within the existing cloud directory “Artikelbilder”:

Artikelbilder/2026-09-04/sortierung.png
Artikelbilder/2026-09-04/timeline.png
Artikelbilder/2026-09-04/datei_teilen01.png
Artikelbilder/2026-09-04/datei_teilen02.png

I then published the two posts, using two of the uploaded image files in each post. Both posts were made public. After a few minutes, my hub was no longer accessible. The Nginx error log filled up with messages of this kind:

2026/09/04 16:48:38 [error] 1653#1653: *6569 upstream timed out (110: Connection timed out) while reading response header from upstream, client: ::1, server: hub.hubzilla.hu, request: "GET /cloud/pepecyb/Artikelbilder/2026-09-04/sortierung.png HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php8.4-fpm-my_webapp.sock", host: "hub.hubzilla.hu"

Although only the file name changed from time to time. These were exclusively messages relating to the four files I had used in the posts. All other services on the server remained accessible without restriction. After a reboot, I was able to access my hub again, but after a short while it became inaccessible once more and these messages filled the log again. After another reboot, I quickly deleted both posts and the four files, including their subdirectory. The problem did not recur after that.

For testing purposes, I then uploaded the four images again. To do this, I created a subdirectory called ‘solidified’ within ‘Artikelbilder’. I then integrated them using the post editor; in the source code, they were referenced by their hash value filenames. Shortly afterwards, the hub was once again unreachable and the errors mentioned above reappeared in the log, with the difference that the path no longer showed the file’s real name, but instead appeared as photo/HASHVALUE.png. For example:

... upstream timed out (110: Connection timed out) while reading response header from upstream, client: ::1, server: hub.hubzilla.hu, request: "GET /photo/3f8ed291-733e-402f-84d0-ee5dcdec77f6-2.png HTTP/1.1" ...

After rebooting and quickly deleting the posts and the images, along with the subdirectory, there were no further problems.

I’d actually noticed some time ago that images from subdirectories containing many further subdirectories and numerous files were no longer appearing (specifically the most recent ones) in the image selection dialogue of the post editor. So I couldn’t select them. When I moved them, as a test, into a new top-level subdirectory, they reappeared in the selection dialogue.

For this reason, I made a third attempt with the two posts. I uploaded the two images for the first article (sortierung.png and timeline.png) to the root level of my channel’s cloud storage and referenced them in the post. The ‘file not found’ error did not occur. For the second post, I created a subdirectory called ‘Artikelbilder2’ in the cloud and, within that, a subdirectory called ‘solteilen’, into which I uploaded the images for this post (datei_teilen01.png and datei_teilen02.png). I then created and published the post using these files. The error did not occur this time either.

I have a feeling (bearing in mind the observation that images are not visible in very full subdirectories in the selection dialogue) that, for some reason, there are limits on the number of files and directories in the cloud.

Could that be possible? Or does anyone here have any idea what might be causing this?

The behaviour is reproducible. And it occurs just as frequently when using Redbasic as it does with Solidified. It doesn’t seem to be down to the theme (which would be rather unlikely anyway… I’ve checked… the files are present in ‘store’ and are also entered in the database).

@Mario Vavti @Harald Eilertsen