Control Panel ConfigurationLast updated: 6 August 2026

SFS Access includes a Global Settings panel for managing the Secure Root and checking that secure file storage is ready to use.

What to configure in Settings

• secure_root_path - the filesystem base path used for secure storage operations.
• create_if_missing_flag - whether SFS Access should create the Secure Root directory automatically if it does not already exist.
• enforcement mode - how strictly SFS enforces health and readiness checks for secure location flows.

You do not always need to change these settings. Many sites can start with the default Secure Root behaviour and only revisit Global Settings if storage location, permissions, or health checks need attention.

To create a secure area, first identify the above-webroot upload location where the files should live. Then define that location as an enclave by giving it a clear name.

A simple way to set up a secure area

1. Choose the above-webroot upload location you want to use.
2. Create the secure area and give it a name that will still make sense later.
3. If useful, attach one or more eligibility pools to limit which members can be assigned access.
4. Save the secure area and then move on to memberships and role permissions.

Naming guidance

• Use names that describe the files or business purpose.
• Avoid temporary project shorthand that may become unclear later.
• Keep naming consistent across similar secure areas.

Role Permissions is where you decide what a member can do after they have been assigned to a secure area.

In the sidebar, Memberships appears before Role Permissions, but many administrators will review both together: first decide who needs access, then decide exactly what each role is allowed to do.

Operation catalogue

• file_list - see the files in the secure area
• file_upload - add files to the secure area
• file_download - download files from the secure area
• file_delete - remove files from the secure area
• membership_manage - change who has access to the secure area
• policy_manage - change role permissions for the secure area
• enclave_lockdown - apply emergency restrictions to the secure area
• token_issue - issue a Vault token
• token_revoke - revoke a Vault token
• external_share_create - create a Gateway external share
• external_share_revoke - revoke a Gateway external share

Default system role model

Set permissions carefully and use Access Check after any role change so you can confirm the real outcome before live use.

Memberships is where you assign people to secure areas.

In the sidebar, Memberships appears before Role Permissions. In practice, this means you first decide who should have access, then decide exactly what their assigned roles allow them to do.

An eligibility pool helps limit who can normally be assigned to a secure area. Memberships then decide which of those people actually receive access.

How access scope is decided

1. The member should be in scope through the relevant eligibility pool.
2. The member must have an active enclave membership.
3. The assigned role must allow the requested operation.

OTP companion note

SFS Access works without OTP Pro. If OTP Pro is installed, some higher-security membership changes can require an extra verification step before the change is applied.

Good governance practice

• Assign access according to named responsibilities, not convenience.
• Removing access promptly when roles change.
• Revalidating access scope during periodic reviews.

This keeps policy intent aligned with real team structure and reduces hidden over-permissioning.

Lockdown controls are used when a secure area needs to be restricted quickly, for example during a suspected security incident or urgent review.

What lockdown does in practice

• Marks the secure area as locked.
• Prevents normal access until the secure area is unlocked again.
• Gives administrators a fast way to contain a problem while they investigate.

OTP companion note

SFS Access works without OTP Pro. If OTP Pro is installed, lock and unlock actions can require an extra verification step before they are applied.

Recommended incident pattern

1. Lock the secure area to contain risk.
2. Confirm the result using Access Check.
3. Review Security Activity Log for impacted operations.
4. Apply remediation and policy corrections.
5. Unlock only when the problem has been dealt with.

Use a simple internal runbook so administrators know when to trigger lockdown, what user impact to expect, and when restoration is appropriate.

SFS Access includes a Global Settings page for Secure Root management. If you are using SFS Access on its own, this is where you manage Secure Root behaviour directly.

When this page matters

If you are using the default Secure Root and it works as expected, you may not need to spend much time here. If you need to change the storage path or fix health issues, this is the place to do it.

Key settings

• secure_root_path - absolute filesystem path used as secure root anchor.
• create_if_missing_flag - allows SFS Access to create the Secure Root directory automatically if it does not already exist.
• enforcement_mode - monitor or enforce behaviour for health checks and operational strictness.

Simple configuration sequence

1. Set secure_root_path to the intended secure root location.
2. Set create_if_missing_flag according to your operational policy.
3. Choose enforcement mode for your rollout stage.
4. Save settings and run health validation.
5. Only proceed with secure location creation when health status is acceptable.

Health outcomes and action

• If health is good, continue with enclave and location workflows.
• If health fails, resolve the reported reason before retrying location creation flows.
• If settings save but health fails, treat the save as incomplete from an operations point of view.

Access Check shows what one member can currently do in one secure area.

This is useful when you want to confirm whether a user should be able to see files, upload files, download files, or carry out other actions before you ask them to test it themselves.

It is also useful when something does not behave as expected and you need a quick way to see what SFS Access is currently allowing or blocking.

Inputs

• Select an enclave.
• Select a member.
• Run the check to produce operation decisions.

Output model

The result shows each operation with:

• whether it is allowed or denied
• a reason code
• technical source detail

How to use reason codes

• Use reason codes as the starting point for troubleshooting.
• Cross-check the same reason in Security Activity Log events.
• Re-run checks after each corrective change to confirm outcome drift is resolved.

Typical use cases

1. Validate a new role-permission design before rollout.
2. Confirm membership assignment gives expected scope.
3. Confirm lockdown behaviour during incident containment.
4. Validate companion-sensitive operation visibility after OTP or companion changes.