Troubleshooting and SupportLast updated: 6 August 2026

The following covers the most frequent issues encountered during initial configuration and everyday use, along with their most likely causes.

An enclave cannot be created from a particular upload location

Only EE upload locations that are above webroot are eligible for SFS Access enclaves. Check the path configuration for the intended location in EE Files and confirm it resolves to a directory above your webroot.

Secure location creation is blocked after settings changes

Check Global Settings and Secure Root health. A saved settings change is not operationally complete if health validation still reports a blocking state.

A member is being denied an operation they should be allowed

Check three things in order:

1. Confirm the member is in the relevant eligibility pool.
2. Confirm the member has an active membership in the enclave.
3. Confirm the role assigned to that member has the required operation enabled in Role Permissions.

Use Effective Access Check to see the evaluated decision for that member and enclave in one view.

A governance action requires OTP and OTP is not available

Some higher-risk admin changes may ask for OTP verification. If OTP services are unavailable, those specific changes may be blocked or hidden until OTP is working again. Core SFS Access workflows still operate without OTP.

Control Panel panels display a licence notice instead of content

This indicates the licence is not active or has expired. Confirm your licence key is entered correctly and has not passed its validity date. During the 7-day trial period, the grace period must not have elapsed.

An enclave action is denied for all members including enclave admins

Check whether the enclave is in a locked state. Locked enclaves block file operations for all members. Only unlock once you have verified the situation that triggered the lock.

Access behaviour does not reflect a recent permission change

This can happen if cached policy results have not refreshed yet. Re-run Effective Access Check, then compare the reason code with recent Security Activity Log entries after the relevant admin change was saved.

Use this workflow when an access result is not what you intended, such as a user being blocked unexpectedly or allowed unexpectedly.

1. Run Effective Access Check first. Check the affected member and enclave. Capture the allow or deny result and reason code.
2. Review the Security Activity Log. Find recent events for the same member or enclave. Compare reason codes with the Effective Access Check result.
3. Confirm enclave status. If the enclave is locked, operations will be denied until it is restored to active state.
4. Verify pool and membership scope. Confirm eligibility pool scope, active enclave membership, and assigned role for the affected member.
5. Check role operation permission. Confirm the assigned role allows the exact operation that is failing.
6. Check OTP Pro status for higher-risk admin changes. If the failing action needs OTP verification, confirm OTP Pro is available and the verification window is fresh. If OTP Pro is unavailable, OTP-protected actions may be blocked or hidden.
7. Check Secure Root health where relevant. If the issue involves secure location setup or directory creation, confirm Global Settings and Secure Root health state.
8. Check for stale policy state. If configuration was changed recently but behaviour did not update as expected, confirm the change saved successfully, then re-test.

If the issue remains unresolved, collect the member, enclave, operation, and reason-code evidence from these steps before contacting support.

If you need support with JCOGS Secure File Service - Access, please contact us at support@jcogs.net.

To help us respond quickly, please include the following when you get in touch:

• ExpressionEngine version — for example, EE 7.4.0.
• PHP version — for example, PHP 8.3.
• SFS Access version — shown in the Control Panel and in addon.json.
• OTP Pro version (if installed) — include this only when OTP Pro is part of your environment.
• Clear description of the issue — what you expected to happen and what happened instead.
• Reproduction steps — the specific actions that lead to the issue.
• Effective Access Check result if the issue relates to an unexpected access decision.
• Relevant Security Activity Log entries if available.

For licensing queries, contact licensing@jcogs.net.

SFS Access caches access decisions for performance. For a short period after admin changes, old cached results can make permissions look wrong: these transient results are called stale decisions.

Typical stale-decision symptoms

• A user is still denied after you changed their role or membership.
• Effective Access Check does not match a recent policy update.
• Different pages appear to show older access outcomes.

Changes that should invalidate cache

• Role permission updates.
• Membership assign, deactivate, or remove actions.
• Enclave-level changes such as upload-location binding or lock status changes.

Safe diagnostic sequence

1. Record the member, enclave, and operation that appears wrong.
2. Run Effective Access Check and note the reason code.
3. Confirm the recent admin change actually saved.
4. Review Security Activity Log for matching events and timing.

Operational recovery guidance

If behaviour still looks stale after valid changes, wait briefly and run the check again. If the same stale result repeats, treat it as a support case and include the member, enclave, operation, and reason-code evidence.