[NoCredentialProviders: no valid providers in chain] when using custom AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY

[bokchoi2020]

Have you read a contributing guide?

• I have read CONTRIBUTING.md
• I have searched the existing issues and didn't find any that were similar
• I have considered creating a pull request with fixes instead of a bug report and want to proceed

Current Behavior

Login works fine, Sync Server status is green, notes can sync (except images, spins).
When sharing space, get error: NoCredentialProviders: no valid providers in chain.
This only happens if AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are not the default upon first "make start".
If default is used, the invite link creation is instant.

Expected Behavior

Expect invite link to be created.

Steps To Reproduce

1. Edit .env.override to customize AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY for security. (still using minio, not amazon s3)
2. Follow steps here to create storage folder, chown to user, add docker.override.yml : https://github.com/anyproto/any-sync-dockercompose/wiki/Configuration#running-as-a-non-privileged-user-only-for-linux
3. make start
4. Switch to client, add client.yml, create account login. See initial space sync.
5. Create new space.
6. Share the space.

Environment

- OS:RHEL10
- Version:Server is at github commit bbdb10753a178b10fd38866a0236376ae9966978 (HEAD), client is stable 0.55.5

Anything else?

• If the server is failing to share, when I remove the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY from the .env.override, it continues to fail.

• To make it work again, I have to remove the ./storage folder completely, remove the custom AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, then "make start", and recreate user on client.

• Note: 40.png in the demo space keeps syncing (spinner spins) if I use custom keyid and key. When default keyid and key is used, the upload is almost instant. Sharing space is similar, default is instant while custom spins then errors out. I feel like maybe somewhere the key/keyid is hardcoded?

• Syntax for password and user id is fine.
  I tried to create another bucket with the same user and password.
  mc alias set myminio http://minio:9000 non_default_user non_default_password

And it returned
Added myminio successfully.

Checking with: "mc admin info myminio" showed details regarding the bucket uptime and storage.

[fb929]

I will check

[TzuH-Hsu]

I encountered the same issue. While I haven't verified this with a live test yet, I suspect I've identified the root cause by looking at the configuration.

The issue likely stems from the volume mount in any-sync-filenode when running as a non-privileged user (as mentioned in the wiki for rootless containers).

In the docker-compose file, the AWS credentials are mounted explicitly to the root user's home directory:

any-sync-dockercompose/docker-compose.yml

Line 140 in cef0b5e

- ./etc/.aws:/root/.aws:ro

When the container is configured to run as a non-root user (e.g., via user: "1000:1000"), the process typically fails to access /root/.aws due to:

• Permission denied: The non-root user cannot access the /root directory.
• Wrong Home Directory: The AWS SDK usually looks for credentials in $HOME/.aws, but for a non-root user, $HOME is usually not /root.

[TzuH-Hsu]

I found further evidence supporting this hypothesis in Discussion #341.
@tribals mentioned that placing credentials in ~/.aws/credentials solved this specific error.

This confirms that the AWS SDK is indeed looking for credentials in the running user's home directory (which is not /root when running as non-privileged), and it fails to find the volume mounted at /root/.aws.

Suggested Fix

Since the home directory of the container user might vary or is unknown in the compose context (and we cannot use ~ in docker volume paths), the most robust fix is to mount the credentials to a neutral path and explicitly tell the AWS SDK where to find them using environment variables.

In docker-compose.yml (or override):

services:
  any-sync-filenode:
    environment:
      # Explicitly point SDK to the mounted location
      - AWS_SHARED_CREDENTIALS_FILE=/etc/any-sync-filenode/.aws/credentials
      - AWS_CONFIG_FILE=/etc/any-sync-filenode/.aws/config
    volumes:
      # Mount to a neutral, accessible path instead of /root/.aws
      - ./etc/.aws:/etc/any-sync-filenode/.aws:ro

This approach ensures the credentials are accessible regardless of which user (root or non-root) is running the process.

[GeekSquirrel]

I encountered the same problem when using a non-root user, came to the same conclusion as @TzuH-Hsu, and the fix worked for me.