Immutability Error - “Object is already immutable.. Access denied” on SharePoint Backup (Case #07988039)

[t7MevELx0]

Hi all,

We have an active support case open with Veeam (Case #07988039) and I’m looking to see if anyone else has encountered the following behavior in Veeam Backup for Microsoft 365.

Environment

• Current Version: 8.3.0.2511
• Planned: Applying rolled-up hotfix build 8.3.0.2567 (unrelated fix)

Repository is immutable object storage and functioning normally for other organizations and objects.

Error Observed

We are seeing repeated failures during SharePoint / OneDrive processing with the following message:

Code: Select all

Failed to apply immutability to object {value}
because the object is already immutable..
Access denied. Could not perform the operation because of missing permissions or wrong data center region.

Behavior Characteristics

• Repository immutability is enabled and operational.
• Error repeats across multiple job cycles.
• Backup job was recreated to eliminate job-state corruption.
• Issue persists on the newly created job.
• Environment is SharePoint Online / OneDrive (not hybrid, not on-prem).

What’s unusual is the contradictory nature of the message:

• The object is reported as already immutable
• Yet the operation fails with Access denied / wrong data center region

If the object is already immutable, I would expect idempotent behavior or a clean skip, not a failure tied to site processing.

Support mentioned this can be informational if the job continues, however in this case it is associated with failed object processing rather than a harmless warning.

Relevant Prior Fix

Release notes indicate that a similar issue was fixed in 8.2.0.2008:

SharePoint backup job to an object storage repository fails with the error:
Failed to apply immutability to object {value} because the object is already immutable. Access denied. Could not perform the operation because of missing permissions or wrong data center region.

We are now on 8.3.0.2511, so I’m trying to determine:

• Is this a regression?
• A different edge case hitting the same immutability logic?
• Something repository metadata-related?

Questions

1. Has anyone seen this persist across multiple job runs in 8.3?
2. Did applying a newer hotfix resolve it?
3. Has anyone had to recreate the repository to clear the state?
4. Has anyone confirmed this to be a metadata inconsistency issue in object storage?

Appreciate any insight from others running immutable object storage with VB365.

Thanks.