This content is locked for now — You don’t have permission to view this content.

Question

Customers are reporting that they cannot access knowledge base documentation via the customer portal for a specific Jira Service Management project. We have already checked the following points:

Article/parent page restriction: Checked and confirmed.

Difference between Atlassian Account and portal-only customers: How can this be verified?

Global knowledge base permission: Checked and confirmed.

Recent change in Confluence: How can this be verified?

Atlassian incident: Checked and confirmed.

Sami Shaik · Answer

@Fabio Santos , the three replies above cover the switches; here are the two "how can this be verified" questions you asked, plus the order I would run everything in.

Verifying the account type. In the JSM project, Customers: a portal-only account shows the email with no Atlassian avatar or display-name link, and the row has no "has site access" marker; an Atlassian-account customer shows the full profile card. The authoritative list is in Atlassian Administration → Products → the site → Jira Service Management → Portal-only customers; if the email is there, the account holds no Confluence licence and the knowledge base must allow "All logged-in users" ( @Arkadiusz Wroblewski point), or those customers see the lock. Check one affected customer this way and you will know which population is failing.

Verifying a recent Confluence change. Three places, from cheapest to most complete: the linked space's Space settings → Permissions page shows "Last modified by" at the bottom with a date; each affected page's ••• → Restrictions dialog shows who set a restriction and when, and the page's Page history shows when the content type or location changed ( @Martin Runge live-doc and move cases both leave a trace there); and for the site-level view, Atlassian Administration → Security → Audit log records space-permission and anonymous-access changes with the actor, on Standard and above. If all three are quiet across the window when customers started complaining, the cause is on the JSM side (the linked-space binding, the Who can view value) rather than in Confluence.

Order: account type of one failing customer first (it splits the problem in half in one check), then the Overview page restriction ( @Mihai_LeanZero ), then Who can view (Arek), then content type and location of one failing article (Martin), then unlink and relink. Post which step cleared it; this symptom has four different causes and the thread will help the next person only if the real one is named.

Martin Runge · Answer

Hi @Fabio Santos,

I have two more ideas:

* Content type. Only classic Confluence pages render in the portal. If someone converted the article into a live doc, the portal cannot render it, and you get exactly this lock message.
* Page location. If the page is now elsewhere, the portal keeps resolving the old reference and fails the permission check instead of returning a clean not found.

Have you tried unlinking and relinking the space in JSM Project settings > Knowledge base? This might clear a stale link.

Servus, Martin

Mihai_LeanZero · Answer

Fabio, your list misses one.

The Overview page of the linked Confluence space, the space home page. Atlassian's KB on this exact symptom lists it as the first cause: if the Overview page is restricted, that restriction overrides the page permissions for every page in the space, even when the articles themselves are public. Easy to skip, it doesn't look like a parent.

Second thing, which "global KB permission" did you check? The Who can view setting in the service space's knowledge base settings and the Anonymous access view permission in the Confluence space settings are two separate switches, and they can contradict each other.

Is it every article or only some?