mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 13:26:00 +03:00
[GH-ISSUE #1745] Failing to connect to bucket with credentials that do not have permission to read the root of the bucket #900
Labels
No labels
bug
bug
dataloss
duplicate
enhancement
feature request
help wanted
invalid
need info
performance
pull-request
question
question
testing
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/s3fs-fuse#900
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
@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.
@rlsutton1 commented on GitHub (Aug 19, 2021):
Actually just changing CheckBucket in curl.cpp fixes it, this reverts 2 lines commited in
d3278f4886@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)
@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.
@liuzhenqi77 commented on GitHub (Sep 14, 2021):
Can confirm this issue, works on 1.89 but fails on 1.90