rustfs/rustfs · error · LockError

Permission denied: {reason}

Error message

Permission denied: {reason}

What it means

The lock operation was denied for permission reasons. Lock ownership and access are scoped per owner/identity; the lock service refused the request because the caller lacks the right to lock the resource or act on the lock.

Source

Thrown at crates/lock/src/error.rs:31

// limitations under the License.

use crate::LockId;
use std::time::Duration;
use thiserror::Error;

/// Lock operation related error types
#[derive(Error, Debug)]
pub enum LockError {
    /// Lock acquisition timeout
    #[error("Lock acquisition timeout for resource '{resource}' after {timeout:?}")]
    Timeout { resource: String, timeout: Duration },

    /// Resource not found
    #[error("Resource not found: {resource}")]
    ResourceNotFound { resource: String },

    /// Permission denied
    #[error("Permission denied: {reason}")]
    PermissionDenied { reason: String },

    /// Network error
    #[error("Network error: {message}")]
    Network {
        message: String,
        #[source]
        source: Box<dyn std::error::Error + Send + Sync>,
    },

    /// Internal error
    #[error("Internal error: {message}")]
    Internal { message: String },

    /// Resource is already locked
    #[error("Resource '{resource}' is already locked by {owner}")]
    AlreadyLocked { resource: String, owner: String },

View on GitHub (pinned to 35af688cd9)

Solutions

1. Confirm the operation is being performed by the same owner identity that acquired the lock
2. Check and correct the lock-service access configuration for the requesting node
3. Do not retry blindly — permission denial is deterministic until configuration changes

fn is_permission_denied(e: &rustfs_lock::error::LockError) -> bool {
    matches!(e, rustfs_lock::error::LockError::PermissionDenied { .. })
}

match op.await {
    Err(e) if is_permission_denied(&e) => alert_config(&e), // needs operator action
    other => other?,
}

When it happens

Trigger: Releasing or extending a lock whose ownership does not match the caller's identity; a lock-service ACL that excludes the requesting node; credentials changing between acquisition and use.

Common situations: Multiple services sharing a lock namespace with different identities; rotated credentials invalidating an established session; misconfigured lock-service permissions after a redeploy.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Related errors

• Lock acquisition timeout for resource '{resource}' after {ti
• Resource not found: {resource}
• Network error: {message}
• Internal error: {message}
• Resource '{resource}' is already locked by {owner}

AI-assisted analysis of rustfs/rustfs@35af688cd9 (2026-08-20). Data as JSON: /api/errors/3e657f82de2b13d7. Report an issue: GitHub.