What causes "permission denied for this operation" in AlistGo/alist?

Identify which operation failed and grant exactly that permission bit to the role

permission denied for this operation

Error message

permission denied for this operation

What it means

Returned by checkManage (server/mcp/auth.go:146) when the user has both PermMCPAccess and PermMCPManage but the merged permissions still lack the specific permBit passed for this operation (e.g. the write, rename, or delete bit). It is the finest-grained check: generic MCP grants are present, the individual operation is not.

Source

Thrown at server/mcp/auth.go:146

	}
	perm := common.MergeRolePermissions(user, reqPath)
	if !user.IsAdmin() && !common.HasPermission(perm, common.PermMCPAccess) {
		return fmt.Errorf("MCP access not permitted")
	}
	return nil
}

// checkManage checks if user can perform write operations via MCP.
func checkManage(user *model.User, reqPath string, permBit uint) error {
	if err := checkAccess(user, reqPath); err != nil {
		return err
	}
	perm := common.MergeRolePermissions(user, reqPath)
	if !user.IsAdmin() && !common.HasPermission(perm, common.PermMCPManage) {
		return fmt.Errorf("MCP manage not permitted")
	}
	if !user.IsAdmin() && !common.HasPermission(perm, permBit) {
		return fmt.Errorf("permission denied for this operation")
	}
	return nil
}

// UserContextFunc returns an HTTPContextFunc that injects a specific user (for STDIO mode).
func userContextMiddleware(user *model.User) func(ctx context.Context) context.Context {
	return func(ctx context.Context) context.Context {
		return context.WithValue(ctx, userKey, user)
	}
}

// resolveUserForStdio resolves a user by username for STDIO mode.
func resolveUserForStdio(username string) (*model.User, error) {
	username = strings.TrimSpace(username)
	if username == "" || username == "admin" {
		admin, err := op.GetAdmin()
		if err != nil {
			return nil, fmt.Errorf("failed to get admin user: %w", err)

View on GitHub (pinned to 843d9dc814)

Solutions

Identify which operation failed and grant exactly that permission bit to the role
Audit the role's permission checklist against the operations the tooling performs
Prefer explicit per-operation grants over broad write access

Defensive patterns

Strategy: validation

Validate before calling

// map each planned operation to its permission bit and verify the role grants it before running

Prevention

Design least-privilege roles per operation and test each tool once after setup
Audit permission checklists when tooling changes operations
Grant the exact missing bit named by the failing operation

When it happens

Trigger: A role with mcp manage but without, say, the delete permission invokes the MCP delete tool; permission sets selectively omitting one operation bit.

Common situations: Least-privilege roles that intentionally omit an operation, hit by a script assuming full write rights; permission templates where a single bit was overlooked.

Related errors

AI-assisted analysis of AlistGo/alist@843d9dc814 (2026-08-15). Data as JSON: /api/errors/e481b2ce81ff0b47. Report an issue: GitHub.