Folder Permissions

Folder permissions control who can access folders within your site. You grant them to users, groups, or partners.

For straightforward shared file access, start with users, groups, and folder permissions in the Default Workspace. Add Workspaces to group the resources and flows for a task or functional area, or to delegate administration; see Solution Design. Each Workspace still uses folder permissions to control access within it.

For non-partner access, user and group permissions layer together. The result for a user is the union of those permissions.

Permission changes apply to impacted users as soon as you save them. Adding a folder permission to an existing group propagates to every member of that group automatically. Removing a permission ends the user's own access, but it does not end the Share Links they already created or the email notifications created for them.

When Workspaces are in use, folder permissions are scoped to the Workspace. Workspace Administrators assign folder permissions to users, groups, and partners within their Workspace. Site Administrators can assign folder permissions within any Workspace.

To check a specific user's, group's, or partner's effective access to a folder and see where it comes from, use the Check Access feature from that folder's Permissions tab.

Permission Options

Site Administrators can assign users or groups the following permissions:

Upload Replacement With Write Permission

Write and Read/Write permission allow uploads to new file paths. Some transfer clients, including SFTP clients, upload part of a file and then resume at an offset. Requiring Full permission for that subsequent write would leave users who only have Write or Read/Write permission with incomplete uploads.

The following 15-minute allowances let those clients finish a transfer without granting the user general overwrite access. A follow-up write can be a continuation of an incomplete upload or a replacement of a completed file; the allowance permits both. Uploading over an existing file otherwise requires Full permission.

For 15 minutes after a user's upload to a path completes, that user can upload to the same path again to replace or append to whatever file is there. Each completed upload restarts the 15-minute window. The allowance applies across sessions, clients, and API keys belonging to that user, as long as the user still has Write permission on the destination folder. On a Remote Server mount, the allowance starts when the upload starts.

The allowance belongs to the user and the path. Deleting the file or replacing it with another user's file does not clear the allowance. Renaming or moving the file does not transfer the allowance to its new path. For example, if a Write user uploads to incoming/report.csv and a Full user then replaces that file, the Write user can still replace the Full user's file at incoming/report.csv within the remaining window, even after logging out and back in.

Separately, any user with Write permission can upload over an empty file that was created or modified within the last 15 minutes, regardless of who created it. This lets a transfer proceed when an earlier operation created the file without any contents. A Write user without Full permission receives a Full-permission-required error when neither allowance applies.

Custom metadata has its own allowance so uploaders can attach information to the files they deliver without needing Full permission. A user with Write permission can add or modify custom metadata on a file they created, for 15 minutes after that file was last modified. This allowance belongs to the file and its creator.

When Broader Permissions Replace Existing Permissions

When you grant a permission that includes an existing permission for the same user, group, or Partner, Files.com keeps the broader grant and removes the redundant narrower grants it covers. For example, granting Full permission on a folder replaces that user's existing Read and Write permissions on the same folder. Granting Folder Admin permission on a parent folder replaces that user's direct permissions on the subfolders it covers. This does not reduce access: the new grant includes the permissions that were removed. Files.com stores only grants that add access instead of retaining narrower grants that provide no additional access.

Permissions are consolidated only when both grants belong to the same user, group, or Partner and the new grant actually covers the old one. A permission granted directly to a user does not replace permissions the user receives through groups. A permission granted to a group affects only other permissions for that same group. A permission limited to the selected folder does not replace permissions on its subfolders, and a Permission Fence prevents a permission above the fence from replacing permissions below it.

The narrower permissions are removed, not hidden. If you later remove the broader permission, Files.com does not restore them. Grant the narrower permissions again if they are still needed.

The Settings Changes log and History Logs record the new broader permission. The automatic removal of the redundant permissions is part of that grant, so it does not create a separate permission-removal entry for each permission that was replaced. When reviewing an access change, use the broader permission grant to identify why the narrower entries disappeared.

Moving a Folder with Granted Permissions

When a folder is moved on Files.com to a different location, all of its folder permissions and folder settings are updated to the new location.

For Remote Mounts, folder moves initiated from the remote server are not reflected in Files.com.

Deleting a Folder With Granted Permissions

Deleting a folder that has granted permissions removes those privileges from all associated users, partners, and groups. Adding a new folder of the same name or restoring the folder does not restore those permissions; you must grant them again.

If the deleted folder was a user's FTP root folder, the folder is automatically recreated when the user next logs in, but the user has no assigned rights for the folder.

Share Links After a Permission Is Removed

Removing a user's permission on a folder ends that user's own access to it. It does not end the Share Links that user already created over the folder. Those links keep working, and a live link keeps showing the folder's current contents, because a Share Link belongs to your business rather than to the access of the person who created it.

To end a link, revoke it or set an expiration date. To put someone else in charge of it, change its owner. The Ownership and Sharing Policy page explains the behavior in full, including the site setting for organizations that want links to end when a user is disabled or deleted.

Email Notifications After a Permission Is Removed

Removing a user's permission on a folder does not delete or disable email notifications the user created or that an administrator created for them. The notifications continue sending activity emails even though the user can no longer access the folder or manage the notification. This applies whether the permission was assigned directly or through a group.

To stop the emails, a Site Administrator or Folder Admin for the folder must delete the notification. The user can unsubscribe from the link in a notification email. The Email Notifications page explains the behavior in full.

Online Editors and File Previews

For editing documents in the Files.com editor and Microsoft Office for web, users must have Full permissions on the folder containing the file. Without Full permissions, users can open but not edit the document.

To preview files in the Files.com web interface, users need at least List/Preview permission. Read permission also allows normal downloads. List/Preview permits viewing content and is not a security boundary that prevents a recipient from capturing it.

Adding or revoking permissions does not immediately affect files already open in online editors or in active previews. The revocation takes effect when the user's session expires or the browser tab is closed.