Confluence Page Permissions: Diagnosing Why a User Can't See or Edit a Page

A user reports they can't open a page you can see perfectly well, or they can view it but the Edit button is gone. In Confluence this is almost always a permissions layering problem, not a bug: space permissions, page restrictions, and group membership stack on top of each other, and a restriction at any layer silently wins. The useful takeaway: work from the broadest layer (global and space permissions) down to the narrowest (page restrictions), because the narrowest layer is where most surprises hide.

Recognizing the condition

Typical symptoms that point to a permissions issue rather than something else:

• The page returns "Page Not Found" or doesn't appear in the page tree or search results for the affected user, but loads fine for you.
• The user can view the page but has no Edit button, or editing works on sibling pages but not this one.
• Access broke recently — often after someone edited restrictions, moved the page, or changed group membership.

If the page is missing for everyone including admins, suspect deletion, a move to another space, or an indexing problem instead — this guide won't cover those.

Common causes at a glance

Check 1: Confirm the user's actual group membership

Permissions are evaluated against groups, so start by confirming which groups Confluence thinks the user belongs to right now. As a Confluence administrator, go to Administration > Users, open the user, and review their group list. If your instance syncs from an external directory (LDAP/AD), remember that membership changes can take time to propagate — a user added to a group five minutes ago may not have the group's permissions yet. Have the user log out and back in before deeper debugging; sessions can hold stale membership data.

Check 2: Space permissions

Open the space containing the page, then Space Settings > Space Permissions (you need space admin rights). Verify the user's group has at least "View" for the space, and "Add/Edit" if they need to modify pages. Two traps here:

• Anonymous access: if anonymous view is enabled, people sometimes assume logged-in users inherit it. They don't necessarily — check the actual groups.
• Global permissions: under Administration > Global Permissions, confirm the user's group can use Confluence at all. A group removed here loses everything regardless of space settings.

Check 3: Page restrictions — including ancestors

This is the most common culprit. Open the target page and click the Restrictions (lock) icon. Restrictions are allow-lists: if a page has any view restriction, only the listed users and groups can see it — everyone else is excluded, even if the space grants them access.

Critically, view restrictions inherit down the page tree. If a parent page three levels up is restricted to the "Managers" group, every child page is invisible to non-members, and the child page's own Restrictions dialog won't make that obvious. Walk up the breadcrumb trail and check restrictions on each ancestor. Edit restrictions, by contrast, apply only to the page they're set on.

Check 4: Rule out caching

Confluence caches permission and membership data, so a correct configuration can still produce wrong behavior for a while after a change. If everything above looks right:

1. Wait 15–30 minutes and re-test, or
2. As a system administrator, go to Administration > System > Cache Management and clear the relevant caches (or all caches on a small instance), then have the user re-test in a fresh session.

Be aware that flushing caches on a large production instance causes a temporary performance dip while caches rebuild — do it off-peak if the site is busy.

Fixes mapped to findings

• Missing space permission: add the appropriate group in Space Permissions. Prefer groups over individual users so the fix survives staff changes.
• Page restriction blocking access: edit the restriction to include the needed group, or remove the restriction entirely if the space-level permissions are sufficient. If the block comes from an ancestor, fix it there — adding the group at the child level won't override an inherited view restriction.
• Stale membership: force a directory sync (Administration > User Directories > Synchronize) if you use an external directory, then have the user re-authenticate.
• Recurring mystery restrictions: check page templates and blueprints — a template with baked-in restrictions will keep producing restricted pages.

Verifying the fix

Don't take the user's word or your own admin view as proof — admins often see content others can't. The reliable check: use a test account in the same group as the affected user (or have the user test), in a fresh browser session or incognito window, and confirm both visibility in the page tree/search and the expected edit capability. Search is a good canary: a page the user can't view should not appear in their search results at all.

When to escalate

Escalate to Atlassian support or your platform team when:

• Permissions are demonstrably correct at every layer, caches are cleared, and access is still denied — this suggests ACL index corruption, which may require a content index rebuild (Administration > Content Indexing) or support involvement.
• Multiple users report intermittent visibility across unrelated spaces — that pattern points to instance-level cache or directory-sync problems, not page settings.
• Restriction changes appear to save but don't persist, which can indicate a database or clustering issue on Data Center deployments.

Before escalating, capture: the space key, page ID, affected username, their group list, screenshots of the Restrictions dialog and Space Permissions, and roughly when the problem started. That turns a vague "can't see the page" ticket into something support can act on immediately.