I’m starting to see a very odd problem. I’m only seeing it on client websites we host with Trellis. All the clients that have reported this issue have their servers now on DigitalOcean.
Some asset (images) URLs return 404, even though the file exists and the permissions and ownership on it are correct (664, owned by web:www-data).
An example path for one of these images is /web/app/uploads/cache/2016/03/water-dragon/2806819678.jpg
I thought it be an Nginx config issue and that I might need to edit rewrite rules to account for the file being another folder level down, but this issue also occurs under canonical structures.
I tried copying the file into the higher-level /web/app/uploads/cache/2016/03/
folder, ls
shows the file is there, the browser returns 404 when trying to access it. That’s consistent with this issue happening with other clients - they don’t have nested files.
I rsync’d the file to my home folder and can open it just fine.
Weirdly enough, the filename changes colors in the ssh session shell when copied to the higher-level folder when using ls
to list. I can’t figure out what the colors represent if anything at all.
This is the stupidest bug to consider switching away from trellis for, but it’s happening frequently enough that my clients are questioning why I switched them from their comfortable shared or managed hosting plans. Does anyone have any insight into why nginx would fail to return a perfectly valid URL path?
Happens with images of all shapes and sizes and formats, and while I have had issues with ACF PRO scripts not being founds (js and css scripts), I haven’t really seen it happen to other css or js files, so I hesitate to assume it’s the same bug, but it might.
I’m using different versions of trellis with these clients, but this example specifically is a release from around a month ago - I don’t think it’s my trellis version being out of date.
Has anyone run into behavior like this and/or have any insight into what’s going on and why?