🚨 Grafana Error Guide: 'Access denied' — Dashboard & Folder Permissions

Overview

Grafana authorizes every dashboard and folder view against the user’s org role (Viewer/Editor/Admin), any folder- or dashboard-level permissions, team membership, and — in Grafana Enterprise/Cloud — fine-grained RBAC. When none of those grant access, Grafana returns 403 Forbidden and the UI shows “Access denied”. Because permissions are inherited from the folder, one wrong folder ACL can hide many dashboards at once.

The literal errors you will see:

Access denied to this dashboard

{"accessErrorId":"ACE...","message":"You'll need additional permissions to perform this action. Permissions needed: dashboards:read","status":"Forbidden"}

t=... lvl=info msg="Request Completed" method=GET path=/api/dashboards/uid/abc123 status=403

It occurs when a user opens a dashboard, a folder, or an API caller uses a token whose role/permissions don’t include the required action.

Symptoms

• The dashboard shows a padlock and “Access denied”; the URL is right but content won’t load.
• API returns 403 with Permissions needed: dashboards:read.
• A whole folder’s dashboards vanish for a team after a permission change.
• A service-account token that used to work now 403s.

curl -s -o /dev/null -w "%{http_code}\n" \
  -H "Authorization: Bearer $TOKEN" \
  http://localhost:3000/api/dashboards/uid/<uid>

403

Common Root Causes

1. Org role too low

A Viewer trying to edit, or a user in the wrong organization entirely, lacks the needed action.

curl -s -H "Authorization: Bearer $TOKEN" http://localhost:3000/api/user \
  | jq '{login, orgId, isGrafanaAdmin}'

2. Restrictive folder permissions

The folder’s ACL was changed to grant only a specific team/role, removing the default “Editor/Viewer” inheritance, so everyone else is denied — for every dashboard inside.

curl -s -H "Authorization: Bearer $TOKEN" \
  http://localhost:3000/api/folders/<folderUid>/permissions | jq '.'

[{"role":"Admin","permission":4},{"team":"sre","permission":2}]

3. Dashboard-level permission override

An individual dashboard can override folder inheritance with its own ACL, denying users who can see the folder.

4. Team membership lost

Permissions are granted to a team; the user was removed from (or never added to) that team.

curl -s -H "Authorization: Bearer $TOKEN" \
  "http://localhost:3000/api/teams/search?query=sre" | jq '.teams[]|{id,name,memberCount}'

5. RBAC role not assigned (Enterprise/Cloud)

Fine-grained RBAC requires an explicit role (e.g. with dashboards:read) bound to the user/team; without it the action is denied even for Editors.

Diagnostic Workflow

Step 1: Identify the user and their effective role

curl -s -H "Authorization: Bearer $TOKEN" http://localhost:3000/api/user \
  | jq '{login, orgId}'
curl -s -H "Authorization: Bearer $TOKEN" http://localhost:3000/api/org \
  | jq '{orgName:.name, orgId:.id}'

Step 2: Read folder and dashboard permissions

curl -s -H "Authorization: Bearer $TOKEN" \
  http://localhost:3000/api/folders/<folderUid>/permissions | jq '.'
curl -s -H "Authorization: Bearer $TOKEN" \
  http://localhost:3000/api/dashboards/uid/<uid>/permissions | jq '.'

Permission integers: 1=View, 2=Edit, 4=Admin.

Step 3: Check team membership

curl -s -H "Authorization: Bearer $TOKEN" \
  http://localhost:3000/api/teams/<teamId>/members | jq '.[].login'

Step 4: Look for provisioned access-control rules

grep -R "" /etc/grafana/provisioning/access-control/ 2>/dev/null
ls /etc/grafana/provisioning/access-control/

Step 5: Grant the missing permission

# Add a team as Viewer on a folder
curl -s -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -X POST http://localhost:3000/api/folders/<folderUid>/permissions \
  -d '{"items":[{"teamId":<teamId>,"permission":1},{"role":"Editor","permission":2}]}'

Example Root Cause Analysis

After a “tidy up permissions” change, an entire support team loses access to the “Customer SLOs” folder — every dashboard inside shows “Access denied”. API on one dashboard:

{"message":"You'll need additional permissions to perform this action. Permissions needed: dashboards:read","status":"Forbidden"}

Reading the folder permissions:

[{"role":"Admin","permission":4},{"team":"platform","permission":2}]

The default Viewer/Editor inherited entries were deleted and only the platform team was granted Edit. The support team, who are org Viewers relying on inheritance, now match no rule and are denied — for the whole folder, since dashboards inherit folder ACLs.

Fix: restore a Viewer grant for the support team (or the Viewer role) on the folder:

curl -s -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -X POST http://localhost:3000/api/folders/<folderUid>/permissions \
  -d '{"items":[{"role":"Admin","permission":4},{"team":<platformId>,"permission":2},{"team":<supportId>,"permission":1}]}'

Access returns immediately. Root cause: a folder ACL that removed inherited Viewer access, cascading to every child dashboard.

Prevention Best Practices

• Manage access at the folder level and let dashboards inherit; avoid per-dashboard overrides unless truly needed.
• Grant to teams, not individuals, so membership changes don’t require touching ACLs.
• Keep at least a broad Viewer grant on shared folders unless the content is genuinely sensitive.
• Provision permissions as code (access-control provisioning) so changes are reviewed and reproducible.
• When it’s an API token, verify the service account’s role and RBAC assignments, not just the token’s validity.
• See more Grafana guides.

Quick Command Reference

# Who am I / which org?
curl -s -H "Authorization: Bearer $TOKEN" http://localhost:3000/api/user | jq '{login,orgId}'

# Folder + dashboard permissions (1=View,2=Edit,4=Admin)
curl -s -H "Authorization: Bearer $TOKEN" \
  http://localhost:3000/api/folders/<folderUid>/permissions | jq
curl -s -H "Authorization: Bearer $TOKEN" \
  http://localhost:3000/api/dashboards/uid/<uid>/permissions | jq

# Team membership
curl -s -H "Authorization: Bearer $TOKEN" \
  http://localhost:3000/api/teams/<teamId>/members | jq '.[].login'

# Grant a team View on a folder
curl -s -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
  -X POST http://localhost:3000/api/folders/<folderUid>/permissions \
  -d '{"items":[{"teamId":<id>,"permission":1}]}'

Conclusion

“Access denied” is authorization, not authentication — the user is logged in but no rule grants the required action (usually dashboards:read). Typical root causes:

1. Org role too low, or the user is in the wrong organization.
2. A restrictive folder ACL that removed inherited access, cascading to all child dashboards.
3. A dashboard-level permission override.
4. Lost or missing team membership behind a team-based grant.
5. A missing RBAC role assignment in Enterprise/Cloud.

Read the folder permissions first; a missing inherited Viewer/Editor entry is the most common cause and fixes many dashboards with one change.