Theme
Permissions
Permissions are decided here, on the Connector, and nowhere else. Not in the Portal, not by Syncplify, not by anyone who controls your site.
Every file operation is checked against them at the moment it happens, before it reaches the disk.
Giving access
Open a user under Access, then Users, and choose Give access. Three steps.
Step 1: which folders
Two ways:
- A folder set, shared with other users. See Folder sets.
- Or just one folder, which grants a single virtual file system.
If nothing is offered, no virtual file systems exist yet. Create one first: Virtual file systems.
Step 2: what they can do
For each folder, choose a permission level.
| Level | What it allows |
|---|---|
| View and download | Browse folders and download files |
| Upload only | Add files and folders; cannot read anything back |
| Drop box | Add files without seeing the folder contents |
| Full access | Read, write, rename and delete everything |
| Everything | Full access plus symbolic links |
| Custom | Pick the abilities one by one |
Step 3: review
The review step states in plain words what will happen. Confirm it.
If the user is connected right now, their sessions end so the new access applies immediately. There is no window where old permissions are still in force.
A grant can also be a home
For a user with no folder layout of their own (the Portal's Automatic home folders, which is the default), the storage you grant here becomes their home by itself: the first granted storage is where they land, and further ones appear inside it as folders named after the storage. The change reaches sign in within about half a minute. On a Connector older than this feature, that does not happen, and the user needs explicit folders set in the Portal instead.
What each level actually grants
The levels are names over twelve underlying abilities. Precisely:
| Ability | View and download | Upload only | Drop box | Full access | Everything |
|---|---|---|---|---|---|
| List folder contents | yes | yes | yes | yes | |
| Create folders | yes | yes | yes | ||
| Edit folder metadata | yes | yes | |||
| Rename folders | yes | yes | |||
| Delete folders | yes | yes | |||
| Download files | yes | yes | yes | ||
| Upload files | yes | yes | yes | yes | |
| Overwrite or append to files | yes | yes | |||
| Edit file metadata | yes | yes | |||
| Rename files | yes | yes | |||
| Delete files | yes | yes | |||
| Create symbolic links | yes |
Two of these deserve a note.
Upload only grants creating folders and adding new files, but not overwriting and not downloading. A user can put a file there and cannot read it back or replace it.
Drop box grants uploading and nothing else, not even listing. The user cannot see what is in the folder, including their own earlier uploads. That is what makes it a drop box rather than a shared folder.
Custom
Custom offers six grouped toggles rather than twelve raw abilities:
| Toggle | Grants |
|---|---|
| Browse folders | List folder contents |
| Download | Download files |
| Upload and overwrite | Upload files, and overwrite or append to them |
| Create and rename | Create folders, rename folders and files, edit folder and file metadata |
| Delete | Delete files and folders |
| Symbolic links | Create symbolic links |
Fine tuning by path
Inside one folder you can add path rules, for example a rule on /reports.
Rules only ever allow
Anything not covered by a rule is denied. A path rule cannot subtract from access; it grants access to a subtree.
Editing afterwards
A user's page lists every folder they can open on this Connector and what they can do in each. Click a permission to change it. A folder without access simply stays closed.
Removing access to one folder ends the user's live sessions and leaves their access elsewhere untouched.
Where these folders appear
Nothing on this page decides where a folder appears in the user's session. The paths they see after signing in are configured in the Portal, on Users.
The two halves have to agree:
| Portal says | Connector says | The user gets |
|---|---|---|
/ maps to Company files | Full access to Company files | A working home directory |
/ maps to Company files | nothing | A folder that will not open |
| nothing | Full access to Company files | Permission to a folder that never appears |
Moves across virtual file systems
A move never crosses a virtual file system boundary, whatever permissions say, including between two virtual file systems on the same Connector.
Clients fall back to copy and delete, which produces the right result more slowly. Lay out your storage so that things which get moved between each other live in the same virtual file system.
What a refused operation looks like
Users are told the operation was denied and never why. The real reason goes to the Connector's own log.
That is a deliberate trade: a precise error message is also a map of what exists and what is allowed. See Activity, where the withheld reason is recorded in full.