Object Lock COMPLIANCE mode allows deletion (v1.0.0-alpha.77)

[swenew]

Issue
Objects with COMPLIANCE retention can be deleted despite active retention period.

Observed behavior:

• Bucket created with --with-lock
• Default retention configured
• Explicit object retention set and displayed correctly
• mc retention info shows correct expiry date
• Delete operation succeeds (creates delete marker)

Expected behavior:
Delete should fail with "Access Denied" error when retention period not expired.

Environment

• Version: v1.0.0-alpha.77
• Deployment: Docker
• Client: MinIO Client (mc)

Impact
Object Lock API works correctly but enforcement is missing. This breaks WORM storage compliance for production use (e.g. GoBD tax compliance in Germany).

Can anyone confirm this?

Regards Swen

[loverustfs]

Ok, please wait for our confirmation.

[loverustfs]

Hello @swenew ,

Could you post an issue, and explanation of steps?

Bug tracking is not done in the discussion section.

[swenew]

mc retention info shows "NO RETENTION" for objects with bucket-default retention (enforcement works correctly)

Description:

When a bucket is configured with a default COMPLIANCE retention policy, objects uploaded to that bucket are correctly protected from deletion. However, mc retention info reports "NO RETENTION" for those objects. Retention set explicitly at the object level displays correctly.

I initially reported a related issue in the discussions where objects could allegedly be deleted despite an active COMPLIANCE retention period. I was unable to reproduce that behavior on 1.0.0-alpha.82 — deletion is correctly blocked. The issue described here is limited to the display of per-object retention info when relying on bucket-default retention.

Environment:

• RustFS Version: 1.0.0-alpha.82
• Client: MinIO Client (mc)
• Deployment: Docker, Single Node Single Disk (SNSD)

Steps to Reproduce:

1. Create bucket with Object Lock
   mc mb --with-lock rustfs/test-bucket

2. Set default retention (COMPLIANCE, 30 days)
   mc retention set --default compliance 30d rustfs/test-bucket

3. Verify bucket-level retention
   mc retention info rustfs/test-bucket
   Output: Object locking 'COMPLIANCE' is configured for 30DAYS ✅

4. Upload object
   echo "test" > test.txt
   mc cp test.txt rustfs/test-bucket/test.txt

5. Check retention info on object
   mc retention info rustfs/test-bucket/test.txt
   Output: Mode : NO RETENTION ❌ (expected: COMPLIANCE, expiring in 29 days)

6. Attempt to delete object
   mc rm rustfs/test-bucket/test.txt
   Output: ERROR Object is under COMPLIANCE retention and cannot be deleted until ... ✅

Expected behavior:
mc retention info should report COMPLIANCE, expiring in 29 days — consistent with the actual enforcement.

Actual behavior:
mc retention info reports NO RETENTION, although deletion is correctly blocked.

Comparison — Explicit object-level retention:

Retention set during upload
mc cp --retention-mode compliance --retention-duration 30d test.txt rustfs/test-bucket/test2.txt
mc retention info rustfs/test-bucket/test2.txt
Output: Mode : COMPLIANCE, expiring in 29 days ✅

Retention set after upload
mc retention set compliance 30d rustfs/test-bucket/test3.txt
mc retention info rustfs/test-bucket/test3.txt
Output: Mode : COMPLIANCE, expiring in 29 days ✅

Summary:

| Scenario | retention info | Deletion Blocked |
| Bucket-default retention | ❌ "NO RETENTION" | ✅ Correct |
| Explicit retention (at upload) | ✅ COMPLIANCE | ✅ Correct |
| Explicit retention (after upload) | ✅ COMPLIANCE | ✅ Correct |

Impact:
Enforcement works correctly in all cases — this is a display bug in per-object retention info when relying on bucket-default retention. For compliance audits, correct reporting of retention status is critical.

[Kris33]

Confirming this bug still exists in 1.0.0-beta.1 (build 2026-04-29, commit 8e1bd56).

Setup: single-node RustFS with 8×3.6T XFS disks, EC:2, used as a Bareos S3 backup target. Bucket created with bucket-default Object Lock COMPLIANCE retention of 90 days. Objects written via Bareos multipart uploads (~100MiB volume parts).

Reproduction matches the original report exactly:

$ mc retention info --default rustfs/bareos-test
Object locking 'COMPLIANCE' is configured for 90DAYS.

$ mc retention info rustfs/bareos-test/Full-0001/0001
Name    : rustfs/bareos-test/Full-0001/0001
Mode    : NO RETENTION

• Bucket-level config: ✅ correct
• Per-object info (inherited from bucket default): ❌ reports NO RETENTION, expected COMPLIANCE, expiring in ~88 days

Enforcement is working correctly — version-id-targeted deletion is properly blocked:

$ mc rm --version-id 29f565b5-12bf-4f33-9d04-1c66289ec56d rustfs/bareos-test/Full-0001/0001
mc: <ERROR> Failed to remove `rustfs/bareos-test/Full-0001/0001`.
Object is under COMPLIANCE retention and cannot be deleted until 2026-07-29 12:14:47.078659983 +00:00:00

So this remains a display-layer bug only — actual WORM enforcement is intact, which is the critical path.

But for compliance audits where retention status reports must match enforcement, the discrepancy is a real problem. Auditors looking at mc retention info output without performing a delete-test would conclude objects are unprotected when they aren't.

Carrying over from at least alpha.77 → beta.1 across the entire alpha series. Hopefully something to address before GA.