[GH-ISSUE #2776] enable_content_md5 generates invalid MD5 hash on Rocky Linux 10.1 #1294

New issue

Open

opened 2026-03-04 01:52:54 +03:00 by kerem · 2 comments

kerem commented

2026-03-04 01:52:54 +03:00

Owner

Originally created by @zvanderbilt on GitHub (Dec 17, 2025).
Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2776

Environment:

s3fs version: 1.95-2.el10_1 (epel)
OS: Rocky Linux 10.1
OpenSSL version: 3.5.1 1
libcurl version: 8.12.1
fusermount version: 2.9.9
fips mode enabled

Description:
When using the enable_content_md5 mount option on Rocky Linux 10, s3fs generates an invalid Content-MD5 header that appears to contain a memory address rather than the actual MD5 hash of the file content. This causes S3 to reject all PUT requests with a BadDigest error.

Steps to Reproduce:
Mount an S3 bucket with enable_content_md5 option on Rocky Linux 10
Attempt to upload any file

Expected Behavior:
File uploads successfully with a valid Content-MD5 header.

Actual Behavior:
S3 returns HTTP 400 with BadDigest error. The Content-MD5 header contains what appears to be a memory address rather than a valid base64-encoded MD5 hash.

Example from debug logs:
> Content-MD5: EAAAAAAAAABA239b9H8AAA==

S3 response:

<Error>
  <Code>BadDigest</Code>
  <Message>The Content-MD5 you specified did not match what we received.</Message>
  <ExpectedDigest>100000000000000040db7f5bf47f0000</ExpectedDigest>
</Error>

Workaround:
Removing enable_content_md5 from mount options resolves the issue.

Additional Context:
Maybe not helpful but this same configuration works correctly on Rocky Linux 8 with the same s3fs version. The issue appears to be related to the newer toolchain (OpenSSL/libcurl/glibc) on RHEL 10-based distributions.

Originally created by @zvanderbilt on GitHub (Dec 17, 2025). Original GitHub issue: https://github.com/s3fs-fuse/s3fs-fuse/issues/2776 **Environment:** s3fs version: 1.95-2.el10_1 (epel) OS: Rocky Linux 10.1 OpenSSL version: 3.5.1 1 libcurl version: 8.12.1 fusermount version: 2.9.9 fips mode enabled **Description:** When using the enable_content_md5 mount option on Rocky Linux 10, s3fs generates an invalid Content-MD5 header that appears to contain a memory address rather than the actual MD5 hash of the file content. This causes S3 to reject all PUT requests with a BadDigest error. **Steps to Reproduce:** Mount an S3 bucket with enable_content_md5 option on Rocky Linux 10 Attempt to upload any file **Expected Behavior:** File uploads successfully with a valid Content-MD5 header. **Actual Behavior:** S3 returns HTTP 400 with BadDigest error. The Content-MD5 header contains what appears to be a memory address rather than a valid base64-encoded MD5 hash. **Example from debug logs:** `> Content-MD5: EAAAAAAAAABA239b9H8AAA==` **S3 response:** ``` <Error> <Code>BadDigest</Code> <Message>The Content-MD5 you specified did not match what we received.</Message> <ExpectedDigest>100000000000000040db7f5bf47f0000</ExpectedDigest> </Error> ``` **Workaround:** Removing enable_content_md5 from mount options resolves the issue. **Additional Context:** Maybe not helpful but this same configuration works correctly on Rocky Linux 8 with the same s3fs version. The issue appears to be related to the newer toolchain (OpenSSL/libcurl/glibc) on RHEL 10-based distributions.

kerem added the

need info

label

2026-03-04 01:52:54 +03:00

kerem commented

2026-03-04 01:52:54 +03:00

Author

Owner

@gaul commented on GitHub (Dec 17, 2025):

I wonder if you have a more a more restrictive crypto policy than the default? Can you run update-crypto-policies --show and share the result?

s3fs definitely lacks error-propagation and logging which might help reveal the underlying cause. Let me experiment with this.

@gaul commented on GitHub (Dec 17, 2025): I wonder if you have a more a more restrictive crypto policy than the default? Can you run `update-crypto-policies --show` and share the result? s3fs definitely lacks error-propagation and logging which might help reveal the underlying cause. Let me experiment with this.

kerem commented

2026-03-04 01:52:54 +03:00

Author

Owner

@gaul commented on GitHub (Dec 17, 2025):

You might try testing with the referenced PR to help us understand this issue.

@gaul commented on GitHub (Dec 17, 2025): You might try testing with the referenced PR to help us understand this issue.

kerem referenced this issue

2026-03-04 02:02:43 +03:00

[PR #1294] [MERGED] Allow overriding test credentials with a profile #1905