mirror of
https://github.com/s3fs-fuse/s3fs-fuse.git
synced 2026-04-25 21:35:58 +03:00
[GH-ISSUE #2649] Cannot use bucket folders created outside s3fs #1266
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#1266
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 @jarau-de on GitHub (Mar 18, 2025).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2649
s3fs shows folders created outside of s3fs as empty files in Linux filesystem. It's not possible to get into the folders. If a folder was created in s3fs mount everything works as expected. It seems x-amz-meta-* information causes s3fs to struggle. If created inside of s3fs these meta information are created. Other tools as s3cmd and cyberduck are working as expected. I tried also complement_stat and compat_dir, but without any success.
@swesner411 commented on GitHub (Jun 5, 2025):
I'm having the same exact issue as described above and cannot find a fix. Details are the same. Pre-existing 'folders' do not work. Making one through s3fs works as expected. I'm on version 1.93
@vicr-np commented on GitHub (Oct 21, 2025):
In s3fs debug, I see this:
2025-10-21T14:23:34.722Z [INF] cache.cpp:AddStat(320): add stat cache entry[path=/Salesforce/]
2025-10-21T14:23:34.722Z [WAN] string_util.cpp:cvt_strtoofft(93): something error is occurred in convert std::string(-:-:-:-:455) to off_t, thus return 0 as default.
The metadata (from aws s3api head-object) shows
@gaul commented on GitHub (Oct 21, 2025):
@vicr-np could you share how this folder was made? The expected format for this value is an integer UID. I looked through GitHub but cannot find a similar colon-separated format. A web search suggests that there are multiple values, e.g.,
501:-:20:-:4294934976.@vicr-np commented on GitHub (Oct 23, 2025):
I'm not sure how it was created. I feel like the problem was introduce after creation, but I'm not sure. It's a production bucket, so I'm not comfortable tampering with it.
As far as I know, the only third party application used is S3 Browser. Otherwise, everything is done through the AWS Console or s3fs.
@ggtakec commented on GitHub (Oct 24, 2025):
(This is as far as I've been able to understand from my research. If I'm wrong, please ignore the comments below.)
Is it possible that this environment is outputting objects to S3 using Salesforce and the Output Connector of Salesforce Data Cloud?
If you use it, depending on the Data Cloud Output Connector you're using, you'll likely need to check the format of this meta data (which I believe means a directory).
If this assumption is correct, the metadata format handled by the Data Cloud Output Connector and s3fs-fuse are different, so if you manipulate objects with s3fs-fuse(assuming you can do so), there's a high chance that you won't be able to read them from Salesforce.
@vicr-np commented on GitHub (Oct 24, 2025):
This folder contains data related to Salesforce. There is a folder inside which is used for integration with Salesforce Marketing Cloud. We generally use the S3 API from Java to access these folders. I use s3fs when I need to investigate issues.
I have other unrelated folders have the same issue, so I don't think it has anything to do with Marketing Cloud.
I will keep investigating and report back if I find anything.
@ggtakec commented on GitHub (Oct 25, 2025):
@vicr-np Thank you for confirming. (I understood that this was different from what I imagined.)
First, regarding the headers relevant to this issue, I'll explain how s3fs-fuse interprets S3 object headers.
s3fs-fuse uses the following headers to recognize an object as a file/directory:
If
x-amz-meta-uidorx-amz-meta-giddoes not exist, s3fs-fuse will attempt to read the following headers instead:(The owner/group headers are used by
s3syncand are supported by s3fs-fuse for compatibility.)The value of these headers(uid/gid/mode/owner/group) are assumed to be numeric and are loaded.
In your case, it appears that
x-amz-meta-ownerwas used.Therefore, please identify the program in your environment that outputs this
x-amz-meta-ownerheader in the-:-:-:-:455format.Although I have not tried it myself, the following method may temporarily resolve this issue without correcting the root cause.
That is to set
x-amz-meta-uid: 0(or a value other than 0) for the target object.This will use
x-amz-meta-uidinstead of thex-amz-meta-ownervalue, so read-only access should be possible.[NOTE] However, caution is required.
If you write data from s3fs-fuse that involves modifying an object, this header and other headers will also be updated, which may cause the object to become unreadable in your client program.
@vicr-np commented on GitHub (Oct 27, 2025):
I wasn't able to determine the cause of the corrupt metadata, but was able to fix it with something like this:
@ggtakec commented on GitHub (Oct 28, 2025):
@vicr-np Thanks for sharing your fix.
It certainly looks like modifying the Content-Type would have produced the same result.
I'd appreciate it if you could let me know if you have any more information on these headers in the future.