[GH-ISSUE #1745] Failing to connect to bucket with credentials that do not have permission to read the root of the bucket #900

Open
opened 2026-03-04 01:49:46 +03:00 by kerem · 5 comments
Owner

Originally created by @rlsutton1 on GitHub (Aug 19, 2021).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1745

Additional Information

We have a shared bucket, and create accounts that only have permissions for certain paths.
s3fs seems to be checking the credentials by trying to access the root of the bucket, but the account does not have permission and this check fails causing s3fs to fail to start

I have confirmed that the configuration works with a near identical bucket and an account with full permissions.

Version of s3fs being used (s3fs --version)

V1.90 (commit:a868c06) with OpenSSL

Version of fuse being used (pkg-config --modversion fuse, rpm -qi fuse, dpkg -s fuse)

2.9.9

Kernel information (uname -r)

5.8.0-50-generic

GNU/Linux Distribution, if applicable (cat /etc/os-release)

20.04.2 LTS (Focal Fossa) (Ubuntu)

s3fs command line used, if applicable

s3fs test.bucket:/somepath /home/me/s3 -o passwd_file=/etc/passwd-s3fs-somepath -o umask=0007,uid=1000 -o allow_other -o use_path_request_style -o url=http://s3-ap-southeast-2.amazonaws.com -o enable_content_md5 -o endpoint=ap-southeast-2

/etc/fstab entry, if applicable

s3fs syslog messages (grep s3fs /var/log/syslog, journalctl | grep s3fs, or s3fs outputs)

s3fs.cpp:s3fs_check_service(3575): Failed to connect by sigv4, so retry to connect by signature version 2.
s3fs.cpp:s3fs_check_service(3590): invalid credentials(host=http://s3-ap-southeast-2.amazonaws.com) - result of checking service.

Details about issue

Originally created by @rlsutton1 on GitHub (Aug 19, 2021). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/1745 ### Additional Information We have a shared bucket, and create accounts that only have permissions for certain paths. s3fs seems to be checking the credentials by trying to access the root of the bucket, but the account does not have permission and this check fails causing s3fs to fail to start I have confirmed that the configuration works with a near identical bucket and an account with full permissions. #### Version of s3fs being used (s3fs --version) V1.90 (commit:a868c06) with OpenSSL #### Version of fuse being used (pkg-config --modversion fuse, rpm -qi fuse, dpkg -s fuse) 2.9.9 #### Kernel information (uname -r) 5.8.0-50-generic #### GNU/Linux Distribution, if applicable (cat /etc/os-release) 20.04.2 LTS (Focal Fossa) (Ubuntu) #### s3fs command line used, if applicable s3fs test.bucket:/somepath /home/me/s3 -o passwd_file=/etc/passwd-s3fs-somepath -o umask=0007,uid=1000 -o allow_other -o use_path_request_style -o url=http://s3-ap-southeast-2.amazonaws.com -o enable_content_md5 -o endpoint=ap-southeast-2 #### /etc/fstab entry, if applicable #### s3fs syslog messages (grep s3fs /var/log/syslog, journalctl | grep s3fs, or s3fs outputs) s3fs.cpp:s3fs_check_service(3575): Failed to connect by sigv4, so retry to connect by signature version 2. s3fs.cpp:s3fs_check_service(3590): invalid credentials(host=http://s3-ap-southeast-2.amazonaws.com) - result of checking service. ### Details about issue
Author
Owner

@rlsutton1 commented on GitHub (Aug 19, 2021):

I have further checked and found that if I bypass CheckBucket in curl.cpp and also bypass s3fs_check_service in s3fs.cpp I can start s3fs and create or read S3 obects.

<!-- gh-comment-id:901586420 --> @rlsutton1 commented on GitHub (Aug 19, 2021): I have further checked and found that if I bypass CheckBucket in curl.cpp and also bypass s3fs_check_service in s3fs.cpp I can start s3fs and create or read S3 obects.
Author
Owner

@rlsutton1 commented on GitHub (Aug 19, 2021):

Actually just changing CheckBucket in curl.cpp fixes it, this reverts 2 lines commited in d3278f4886

MakeUrlResource(get_realpath("/").c_str(), resource, turl);

turl           += urlargs;
url             = prepare_url(turl.c_str());
path            = get_realpath("/");
<!-- gh-comment-id:901592317 --> @rlsutton1 commented on GitHub (Aug 19, 2021): Actually just changing CheckBucket in curl.cpp fixes it, this reverts 2 lines commited in d3278f488676990560ed0d4066220ee4f00183ec MakeUrlResource(get_realpath("/").c_str(), resource, turl); turl += urlargs; url = prepare_url(turl.c_str()); path = get_realpath("/");
Author
Owner

@rainmeng commented on GitHub (Aug 24, 2021):

Hit by this issue. From log with v1.89 it honors the prefix,

2021-08-22T03:18:02.467349+00:00 ip-10-57-4-37 s3fs[2844]: > GET /test-bucket/?delimiter=/&max-keys=1000&prefix=prefix/ HTTP/1.1
2021-08-22T03:18:02.467465+00:00 ip-10-57-4-37 s3fs[2844]: > Host: s3.amazonaws.com
2021-08-22T03:18:02.467567+00:00 ip-10-57-4-37 s3fs[2844]: > User-Agent: s3fs/1.89 (commit hash unknown; OpenSSL)

with v1.90 it doesn't

2021-08-24T01:30:11.246495+00:00 ip-10-56-86-107 s3fs[10763]: > GET /test-bucket/ HTTP/1.1
2021-08-24T01:30:11.246633+00:00 ip-10-56-86-107 s3fs[10763]: > Host: s3.amazonaws.com
2021-08-24T01:30:11.246772+00:00 ip-10-56-86-107 s3fs[10763]: > User-Agent: s3fs/1.90 (commit hash unknown; OpenSSL)

<!-- gh-comment-id:904257308 --> @rainmeng commented on GitHub (Aug 24, 2021): Hit by this issue. From log with v1.89 it honors the prefix, 2021-08-22T03:18:02.467349+00:00 ip-10-57-4-37 s3fs[2844]: > GET /test-bucket/?delimiter=/&max-keys=1000&prefix=prefix/ HTTP/1.1 2021-08-22T03:18:02.467465+00:00 ip-10-57-4-37 s3fs[2844]: > Host: s3.amazonaws.com 2021-08-22T03:18:02.467567+00:00 ip-10-57-4-37 s3fs[2844]: > User-Agent: s3fs/1.89 (commit hash unknown; OpenSSL) with v1.90 it doesn't 2021-08-24T01:30:11.246495+00:00 ip-10-56-86-107 s3fs[10763]: > GET /test-bucket/ HTTP/1.1 2021-08-24T01:30:11.246633+00:00 ip-10-56-86-107 s3fs[10763]: > Host: s3.amazonaws.com 2021-08-24T01:30:11.246772+00:00 ip-10-56-86-107 s3fs[10763]: > User-Agent: s3fs/1.90 (commit hash unknown; OpenSSL)
Author
Owner

@gposton commented on GitHub (Aug 27, 2021):

I've hit this issue as well after upgrading to v1.90. We had no issues w/ 1.89. I believe it to be related to this PR which went in with the 1.90 release. https://github.com/s3fs-fuse/s3fs-fuse/pull/1728.

<!-- gh-comment-id:907296124 --> @gposton commented on GitHub (Aug 27, 2021): I've hit this issue as well after upgrading to v1.90. We had no issues w/ 1.89. I believe it to be related to this PR which went in with the 1.90 release. https://github.com/s3fs-fuse/s3fs-fuse/pull/1728.
Author
Owner

@liuzhenqi77 commented on GitHub (Sep 14, 2021):

Can confirm this issue, works on 1.89 but fails on 1.90

<!-- gh-comment-id:919520293 --> @liuzhenqi77 commented on GitHub (Sep 14, 2021): Can confirm this issue, works on 1.89 but fails on 1.90
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/s3fs-fuse#900
No description provided.