S3 plugin: Missing credentials in config

[uncut trail]

I'm trying to use S3 as the file service. I configured everything according to the documentation: https://docs.medusajs.com/plugins/file-service/s3
I also followed this DEV post (https://dev.to/yinks/how-to-set-up-an-aws-s3-bucket-for-medusa-s3-file-plugin-4fno), because there was more information about the IAM user mangement and groups of AWS.

So basically the bucket works and is accessible via the url. I also added the 5 env variables

S3_BUCKET_URL=https://foxi-medusa-image-monster.s3.eu-central-1.amazonaws.com
S3_BUCKET_NAME=foxi-medusa-image-monster
S3_BUCKET_REGION=eu-central-1
S3_ACCESS_KEY_ID=<MY_ACCESS_KEY_ID_OF_CREATED_USER>
S3_SECRET_ACCESS_KEY=<MY_SECRET_ACCESS_KEY_OF_CREATED_USER>

But somehow when starting the server and uploading a thumbnail using the admin page for example I get this error:

error:   Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1
Error: connect EHOSTDOWN 169.254.169.254:80 - Local (192.168.0.45:58551)
    at internalConnect (node:net:1066:16)
    at defaultTriggerAsyncIdScope (node:internal/async_hooks:464:18)
    at node:net:1250:9
    at process.processTicksAndRejections (node:internal/process/task_queues:77:11) {
  message: 'Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1',
  errno: -64,
  code: 'CredentialsError',
  syscall: 'connect',
  address: '169.254.169.254',
  port: 80,
  time: 2023-04-11T18:21:45.616Z,
  originalError: {
    message: 'Could not load credentials from any providers',
    errno: -64,
    code: 'CredentialsError',
    syscall: 'connect',
    address: '169.254.169.254',
    port: 80,
    time: 2023-04-11T18:21:45.616Z,
    originalError: {
      message: 'EC2 Metadata roleName request returned error',
      errno: -64,
      code: 'EHOSTDOWN',
      syscall: 'connect',
      address: '169.254.169.254',
      port: 80,
      time: 2023-04-11T18:21:45.615Z,
      originalError: [Object]
    }
  }
}

Do I need to add some additional authentication somewhere?

[ancient forge]

i think is a problem whit all plugins in the version 1.8, i have the same problem with digital ocean plugin

[uncut trail]

ah damn...

do you know in which version it worked?

[flat granite]

The issues in the two plugins are unrelated. I see the issue in the s3 plugin. It is line 20 of /src/services/s3.js. The client is created without the config options. So if you are using the AWS CLI to configure the credentials on your machine, it should be fine, but if not, it may not work properly.

https://github.com/medusajs/medusa/blob/develop/packages/medusa-file-s3/src/services/s3.js

Follow this link https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html or just do the following:

For linux: curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" unzip awscliv2.zip sudo ./aws/install aws configure

The recommended best practices now are to use the CLI tool rather than hardcoding the credentials, but it should still be an option. I'll work on a pull request.

[uncut trail]

oh wow! yeah makes sense!

Thank you for the detailed message. Got it to work now with the aws cli :)

[flat granite]

Re-familiarizing myself, I see that there is this function at the end called updateAwsConfig. This function is called to update the config before every operation (upload, delete, etc.). But that may no longer work as originally intended, because I submitted an update to the plugin a while back to make it create and keep only one copy of the client, instead of creating a new client for each operation, which is far from ideal. Those clients were never destroyed and were essentially a memory leak. My change possibly broke the way that config updates were intended. In other words, the config options are being updated before every operation, but that no longer has an effect, because a new client is no longer created for every operation (after the config update). Instead, the client that is being used was created prior to the config update. If this makes no sense, don't worry about it. I'm going to play around with it a bit and see if I can tweak it to avoid this issue in the future for those not using the AWS CLI.

So, it looks like this is already addressed by this pull request: https://github.com/medusajs/medusa/pull/3740 So, once that is merged and released, this will be resolved. In the meantime, anyone experiencing this issue can avoid it by using the aws CLI mentioned above. This will set your config credentials in the local environment.

[cobalt ruin]

Bumping this ..

[flat granite]

It's going through the process. It just can take some time. The person who originally authored the pull request may be on vacation or busy on another project at the moment. It is in the pipeline and will be released imminently. In the meantime, there is a viable solution that will get you up and running (using the AWS CLI).

[ancient forge]

and for spaces digitalocean it will work also soon?

[flat granite]

I don't use digitalocean. Is there a github issue reported?

[celest shoal]

Hi! I saw the changes has already merged. Does it mean it's working by updating medusa?

[flat granite]

Not quite yet. It was merged into the development branch, so it should be in the release coming next week.

[deft viper]

I'm facing the same issue here. It was working earlier in the month and suddenly stopped allowing me to upload new images for products in the admin dashboard

My instance is on Railway. Would I still need to run the AWS Cli tool to fix this issue or is this an env config?

[celest shoal]

they are releasing the solution soon, since the problem was in the code.

[deft viper]

Understood. I meant in the meantime, is there something I can do to workaround this for now? I have to present this site I'm working on to a group of investors, and not having the ability to upload the images of the items is going to make it a hard sell

Is there an option to display images directly from the frontend site's public/images instead of having to retrieve them from S3?