Your user can't see a page? Security permissions troubleshooting 101

When a user reports that they are unable to view or edit a specific page or file on the intranet, the issue is typically caused by restricted access permissions, page privacy settings, or broken security inheritance.

Understanding error codes

Depending on your site configuration, users attempting to access restricted content will encounter either a 404 (Not Found) or a 403 (Forbidden) error message.

Administrative Note: The global configuration setting security.showForbiddenPage controls which error code is surfaced to end users:

• Setting enabled (true): Displays a 403 Forbidden error, explicitly indicating the content exists but the user lacks permissions.

• Setting disabled (false): Displays a 404 Not Found error, obfuscating the page's existence from unauthorized users for security.

Verify page privacy status

Private pages are restricted exclusively to designated page owners and site administrators.

1. Navigate to the target page using an administrator account.

2. Click Edit in the page header.

3. Check the Private checkbox status:

   • If Private is checked, standard site users cannot view or search for the page regardless of their group permissions.

   • Uncheck Private and save your changes to grant general access.

2. Audit page view and edit permissions

If the page is not in draft, verify that the individual user or their security group has been assigned explicit access rights.

1. As an administrator, expand the header section of the affected page to view the current security permissions panel.

2. Verify that the user or a security group they belong to is explicitly listed under either VIEW ONLY or VIEW & EDIT.

3. To modify permissions, click the Pencil icon in the security header.

4. If the permission panel is editable (not inheriting settings), click Add people and security groups to search for and assign the missing user or group.

3. Review security inheritance

If the Use security settings from parent page checkbox is enabled, the page automatically inherits its access control list (ACL) from its parent container in the site hierarchy.

Top-Level Parent Page (Permissions set here)
   └── Sub-Page 1 (Inherits parent permissions)
        └── Target Page (Inherits parent permissions)

• To maintain inheritance: Navigate up the page hierarchy to the parent page (or top-level section page) where Use security settings from parent page is unchecked. Modify the permissions on that parent page; changes will automatically cascade down through the entire section.

• To break inheritance: Uncheck Use security settings from parent page on the target page. This allows you to define custom, standalone permissions for that specific page.

4. Check file asset permissions

If a user cannot download or view an embedded file attachment, file-level permissions may differ from the page housing the file.

1. Navigate to the page where the file is attached.

2. Click the file details link to access the standalone File Page.

3. Expand the security panel on the File Page and audit the VIEW ONLY and VIEW & EDIT permissions using the same steps outlined in Section 2.