silly question, does anyone know what we did to fix thumbnails? (fixed!)

Submitted by twovests in meta (edited )

~8 months ago, when Jstpst came back up online, thumbnails weren't working. Whoops!

Besides setting TRUSTED_PROXIES in the docker-compose, I'm working on another Postmill install with someone and we can't figure out how to fix it lol

I've scoured Jstpst, the Element room, etc. Jstpst and this other Postmill install are very similar setups, using the same Caddy version, similar Caddy files, same Postmill version, similar Docker Compose files, and the same Postmill versions. And yet I can't figure out how to fix it...

(There are actually a few things that were fixed that I don't personally remember, like a Vary: Accept header, etc. But thumbnails is thing number 1 hehe)

Fixed!

The problem was I needed to chmod +x the submission_images_2x/ and submission_images_1x/ dirs. Just an Nginx thing

5

Comments

You must log in or register to comment.

emma wrote

i think it was just setting TRUSTED_PROXIES.

exactly how are the thumbnails broken? what do the thumbnail urls being generated look like?

3

twovests OP wrote (edited )

Just like with Jstpst, the thumbnail URL (e.g. https://jstpst.net/media/cache/submission_thumbnail_2x/8715833c4e1d896ba5cc0a3857f7db8b59f36886409251b2871b505c5b1bf25b.jpg) instead throws a 404.

TRUSTED_PROXIES is set, as are the same permissions for the directories in the relevant Docker.

(The 404 page for JstPst still throws the Vary: Accept and Vary: Accept-Encoding. So, I was wrong in OP.) (I'm hesitant to post the site here, since this is an instance for my Irls and I've made some very personal posts here over the years hehe)

EDIT: The postmill-docker-example-web-1 says its for 'permission denied' so I'm still looking into that

1

emma wrote

ok, so, when the image is thumbnailed, this fact is stored in the cache. being thumbnailed, it should have an image in /app/public/media/cache/submission_etc_blahblahblah, so you should check that these are being created, and that files in these directories are web accessible.

if they aren't there, then you could try clearing the cache. i believe bin/console cache:pool:clear cache.app is the right thing here, but you could also just delete /app/var/cache entirely. this will force it to check if a thumbnail exists again, and if not, attempt to thumbnail it again.

it really sounds like persistent storage is misconfigured or something, though.

2

twovests OP wrote

Yeah; they're populated in "/app/public/media/cache/submission_thumbnail_2x/{hash}.jpg", and even have the right permissions. (I also chmod 777'd one of them just to test, but the web logs still say "Permission denied".)

E.g. Just like JstPst, I have:

/app/public/media/cache/submission_thumbnail_2x # ls -lha
total 40K
drwxrwx---    2 www-data www-data    4.0K Mar 10 04:19 .
drwxrwxr-x    4 root     root        4.0K Mar  8 10:30 ..
-rw-rwxr--    1 www-data www-data   15.3K Mar  8 03:02 1e7e72e1f466066e11c9ec8cfd764c1b13bd26f15059ffcecb12798da45eac13.png
-rw-rwxr--    1 www-data www-data    1.3K Mar 10 04:19 83c04d36f7e707aad8323d5e8536fa6921f0e0e78254da4c1e0cfcb6065ddf24.png
-rwxrwxrwx    1 www-data www-data    3.7K Mar  8 02:55 8949be8ddb088c68d93b1904633d2a0e7d94c99c5a47b72d5a98614b8a15a62d.jpg
/app/public/media/cache/submission_thumbnail_2x #

(Where 8949...a62d.jpg I messed with the permissions to see if that would work.)

I deleted /app/var/cache and... Broke the site! So I'm going to go fix that now. (Wait, I was able to fix it, yay.)

tldr: TRUSTED_PROXIES set, the cached image files are indeed present with identical permissions to jstpst. Will continue debugging later;

1

twovests OP wrote (edited )

huh, the media_cache, submission_images, and var folders exist in the same subdirectory as the docker-compose.yml. Investigating...

(edit) Still the same permissions as on jstpst. hmmm

1

emma wrote

the docker setup does that to make retaining your data easy. they're bind-mounted to the appropriate locations in each container.

2

twovests OP wrote

That makes sense! Further debugging and posting logs here for my future reference:

This might

postmill-docker-example-web-1          | 2025/03/10 18:16:44 [crit] 30#30: *10 stat() "/app/public/media/cache/submission_thumbnail_2x/83c04d36f7e707aad8323d5e8536fa6921f0e0e78254da4c1e0cfcb6065ddf24.png" failed (13: Permission denied), client: 172.18.0.1, server: , request: "GET /media/cache/submission_thumbnail_2x/83c04d36f7e707aad8323d5e8536fa6921f0e0e78254da4c1e0cfcb6065ddf24.png HTTP/1.1", host: "", referrer: "https:///"
postmill-docker-example-web-1          | 2025/03/10 18:16:44 [crit] 30#30: *11 stat() "/app/public/media/cache/submission_thumbnail_2x/8949be8ddb088c68d93b1904633d2a0e7d94c99c5a47b72d5a98614b8a15a62d.jpg" failed (13: Permission denied), client: 172.18.0.1, server: , request: "GET /media/cache/submission_thumbnail_2x/8949be8ddb088c68d93b1904633d2a0e7d94c99c5a47b72d5a98614b8a15a62d.jpg HTTP/1.1", host: "", referrer: "https:///"
postmill-docker-example-web-1          | 2025/03/10 18:16:44 [crit] 30#30: *13 stat() "/app/public/media/cache/submission_thumbnail_2x/1e7e72e1f466066e11c9ec8cfd764c1b13bd26f15059ffcecb12798da45eac13.png" failed (13: Permission denied), client: 172.18.0.1, server: , request: "GET /media/cache/submission_thumbnail_2x/1e7e72e1f466066e11c9ec8cfd764c1b13bd26f15059ffcecb12798da45eac13.png HTTP/1.1", host: "", referrer: "https:///"
postmill-docker-example-web-1          | 172.18.0.1 - - [10/Mar/2025:18:16:44 +0000] "GET /media/cache/submission_thumbnail_2x/83c04d36f7e707aad8323d5e8536fa6921f0e0e78254da4c1e0cfcb6065ddf24.png HTTP/1.1" 404 366 ""

to future me:

1

twovests OP wrote

SOLVED! Nginx needs exec permissions even on directories.

I solved this by chmod +x submission_images_2x/, submission_images_1x.

2

emma wrote (edited )

i think this is just how unix permissions work in general, not just an nginx thing

$ mkdir poo
$ echo crouton > poo/stuff
$ cat poo/stuff
crouton
$ chmod 600 poo
$ cat poo/stuff
cat: poo/stuff: Permission denied

congrats on solving it

2