image-resizer
image-resizer copied to clipboard
Error. No file exists at the given path
Describe the bug
When trying to resize a PNG image with AWS S3 as the volume type, we are getting: Error. No file exists at the given path.
This works fine for JPG images in the same volume and locally (not using S3) I am able to resize PNG images.
Steps to reproduce
- Upload a PNG image to a volume using AWS S3
- Try to resize the image
- Error that no file exists (when it does and can be accessed)
Craft CMS version
Craft Pro 4.4.17
Plugin version
3.0.6
Multi-site?
Yes
Additional context
No response
How strange, I certainly can't reproduce that with a whole different set of image formats either, least of all PNG. Just to be clear, is this log message after the image has been uploaded? As in, you upload the file without resizing enabled, and then manually resize it - or this happens on upload?
In either scenario, does the file actually exist all okay on S3?
Yes file exists in S3 - no problems resizing JPG files or anything locally outside of S3. Yes the log message is post upload trying to manually resize the image. I haven't seen this on upload but the images we are looking at wouldn't be triggered as they are below the threshold.
Appreciate there is not much to go on here, anything that would help investigate. S3 setup is pretty standard, the plugin uses an IAM role as we are running in Kubernetes.
Thanks for clarifying. Pretty strange all in all.
Something worth checking is the fix described in https://github.com/verbb/image-resizer/issues/76 which could be similar
Updated to latest plugin but still seeing the same issue unfortunately.
I suppose you've also tried multiple types of PNG's of various sizes? What Image Resizer will do for remote filesystems is if it doesn't already exist locally, it'll download it to storage/runtime/temp
, resize it, then upload it back up to S3.
Can you verify if the file is being downloaded to the location when you upload? You can test first with a JPG, then a PNG. It should appear momentarily when it's being processed.
We are running inside Kubernetes so difficult for me to monitor which pod (out of 3) the image would download to, will try and see if I can catch it