Could not find file in the store located at url: //s3-bucket/prefix/file.jpeg

installation
1

I am currently in progress of setting up the official Docker image on AWS ECS.
While running on EC2 the docker image works perfectly fine.

However after starting it on ECS with the same configuration, I end up with broken avatar images.

Related errors:

Could not find file in the store located at url: //x-dev-xx-xxx-x.s3.dualstack.eu-central-1.amazonaws.com/original/1X/761c151e2d0ebedff3330dc6ec7a27050fef43f9.jpeg

and

Failed to process hijacked response correctly : FinalDestination::SSRFDetector::LookupFailedError : FinalDestination: lookup failed

The file is in the bucket and the access rights are the same as for the EC2 instance.

Can somebody please point me where I can dig deeper and find the root cause?

Thanks

2

Did you build am image with launcher and push the image to a repo? And you’re launching it with the same env as launcher uses?

3

Yes. I use the environment variables that the run-cmd command generates. I could not spot an error so far.
Unfortunately I could not find some ECS examples for Discourse so far.

4

You’re on the right track, but it’s tricky getting the standee migrated and assets uploaded. I’m not sure what the issue might be.

5

I found the root cause. Due to my setup of the Discourse AI plugin I had added a private Zone to the VPC to make the diverse services available VPC internally.

When running Discourse on an EC2 instance in a Docker container, the container gets a host name like 12-34-56-78-app. When running as an ECS task however you can not set the host name when in awsvpc mode, neither you can’t configure the DNS search domain. This leads to the fact that DNS resolution is different on ECS, in my case adding a search domain like xxxx.internal.

After digging around I found using tcpdump that Discourse tries to resolve its own FQDN as part of the SSRF checks. If this fails, the check fail. As a subsequent error the call to S3 fails with the bogus error message above.

The fix in my case was to add the FQDN record which is an alias to my Cloudfront distribution to my private DNS zone.

2 Likes
6

Wow. That’s some good debugging! And that’s why this is an unsupported install! Not much way that much of any of that could be guessed!

1 Like
7

In the end it is as usual: if it does not work, it’s always DNS :joy:

8

Hi @nodomain,
I experienced the exact error as in your post below. The request to user avatar for example https://example.com/user_avatar/example.com/myself/96/215_2.png response with 500. In my case, the domain name example.com is not setup in public DNS, in the testing stage, I spoof example.com in my host file locally. Will this issue not appear when the domain name example.com got setup in public DNS?