crouton addiction

going to monch on some croutons in honor of these achievements

That's because we shadowbanned them

brilliant

I can't recall any conservatives expressing any opinions on here, and I'm happy they're generally not even expressed ironically

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

SOLVED! Nginx needs exec permissions even on directories.

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

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:

• This might be a Caddy error?
• Or might be the Nginx inside the container: https://stackoverflow.com/questions/25774999/nginx-stat-failed-13-permission-denied

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

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

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;

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.

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

i think it was just setting TRUSTED_PROXIES.

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

I think I must have borked something which broke the sync-themes command, and commenting that out in the install script fixed it. I instantiated a fresh install of Postmill about 40 hours ago where no such problem was present!

Will need to figure that out when I am at a keyboard again

holey dfamn. i like the cute little book mark flag <3

sorry, fans of the Latte theme

uh, that should not have disappeared

Yay! Must have just been me clearing my cookies or something

Hooray! I saw your downtime message, and thought it was pretty funny ;)

Me too.

i'm still logged in...

Whoops, thank you! Fixed :)

elly whitelist real :)

keep up the good admin work

I'm not whitelisted!

:(