Users (except admin) not seeing album thumbnails

[ildyria]

Discussed in #4254

^{Originally posted by brandonjacksonphoto April 2, 2026}
When a user logs into Lychee, they see their albums but only as icons.. the thumbnails aren't appearing for them. I can see them logged as as the admin. I'm betting there's a setting I'm missing somewhere but I can't seem to find it.
I'm on ver 7.5.3
TIA!!

[jsaathof]

I had this with one of the updates too. I had to click on the maintenance action "pre-computed album fields" if I remeber correctly. Maybe this is your issue? I haven't had any issues since. I have done this on 7.2.0 and updated to almost every version since.

[ildyria]

@jsaathof Maybe, but it does not hurt to double check that the logic is sound. :)

[bmentink]

@jsaathof You comment: I had to click on the maintenance action "pre-computed album fields"
I don't see that option, please direct me to it.

I have a similar issue, either the thumbnails and images are blank or just blurred. However, can't even see them in Admin.

[ildyria]

I have a similar issue, either the thumbnails and images are blank or just blurred. However, can't even see them in Admin.

Can you open your network tabs in your browser ? It might be that your images are not loading from the correct url (likely a lot of 404 complaints).

[bmentink]

Not sure what you mean by "network tabs" I can open web sites in my browser tabs just fine .. no 404 complaints

[Siddo987]

Have a similar Issue: All photos and thumbs are shown correctly when logged in as admin. When not logged in at all no photos are shown except the ones from /dist like background pictures... All thumbnails and photos arent loading properly.
Thumbnails:

Photos:

Photos in Header:

Can reproduce errors on https://photography.sidowski.de/gallery
Error 403 "Invalid signature" under the picture links. Maybe because of trying to use http instead of https?

[bmentink]

It seems there is something very broke with Lychee. I just restarted by server, and the Lychee docker container, and now I have blurred thumbnails and missing images again. The images displayed fine before the reset.

Seems if I do anything with Lychee it breaks easily. To recover I will have to upload my images again, and go through the laborious task of Naming each image again.

One thing I notice, in your docker compose file you do not have PUID and PGID specified. I see from the logs that they default to 33, whereas my user is 1000, could this be an issue? My other container (Dokuwiki) sets these correctly to 1000.
When I try to set them (to 1000), nothing changes with the images, but the user (admin) cannot add albums or files any more.. The Diagnostic logs do not shed any light on it at all.

I do see error 404 on the network tab for each of my images. I don't see why that is, as the files are there as they were, and with the same permissions as when it was working .... what gives @ildyria Appreciate some help here

[ildyria]

@Siddo987

Error 403 "Invalid signature" under the picture links. Maybe because of trying to use http instead of https?

The invalid signature is a problem. Can you disable "Enable temporary image links" for now ? I am pretty sure that is the reason (I will need to investigate why it is not working as expected).

[ildyria]

@bmentink I assume that you pull a newer version ?

One thing I notice, in your docker compose file you do not have PUID and PGID specified. I see from the logs that they default to 33, whereas my user is 1000, could this be an issue? My other container (Dokuwiki) sets these correctly to 1000.
When I try to set them (to 1000), nothing changes with the images, but the user (admin) cannot add albums or files any more.. The Diagnostic logs do not shed any light on it at all.

Yes, version 7.0 to 7.2~something, the docker image was using root and was not respecting the PUID and GUID. This has been fixed, unfortunately this means that you need to do a chown/chmod on all the existing pictures to set them back to the proper id (e.g. if you are running as 33, and the folders are set with 1000:1000 then 33 won't have read access).

the user (admin) cannot add albums

That would mean that user admin cannot write to the database, which database backend are you using ?

Seems if I do anything with Lychee it breaks easily. To recover I will have to upload my images again, and go through the laborious task of Naming each image again.

That should not be the case, I have zero issues with my personal install running docker compose + traefik, so that is quite surprising.

[ildyria]

@Siddo987 I checked on my personal instance, the temporary link where you are getting 403 is working fine, so this is most likely due to difference of configuration. I will try to add some debug logs to have better visibility on why those are not working as expected. :/

[Siddo987]

Hi @ildyria,
​I managed to fix the 403 Forbidden - Invalid Signature error that anonymous users were encountering when trying to load images.
​What fixed the issue:
Changing the TRUSTED_PROXIES setting in the .env file to trust all proxies solved the problem: TRUSTED_PROXIES=*
Since my setup runs behind Cloudflare (with Full SSL enabled) on an All-Inkl web host, i think Laravel wasn't correctly recognizing that the incoming traffic was already using HTTPS. As a result, the application generated the cryptographic signature based on an http:// schema, while the browser requested it via https://. This schema mismatch caused the errors, locking anonymous users out with a 403 error. Setting TRUSTED_PROXIES=* forced Laravel to respect the https headers sent by Cloudflare.

​A quick note on how it happened:
To be completely honest, I am not 100% sure if only this change did the trick. I had been tweaking a few config settings and clearing caches right before this, so it is possible that a combination of previous changes just happened to take effect at that exact moment.

​What surprises me the most is that this error suddenly appeared out of nowhere without any manual changes to the server or the .env file prior to the crash. Maybe a background update on the hoster's side or a change in Cloudflare's edge routine triggered the strict proxy validation. Especially since i tweaked with the SSL certificates a few days prior.