Understanding user management is one of the first essential steps in designing a secure and productive work environment on Files.com.
When you combine a well-designed user schema with a thoughtful folder hierarchy, the result is a powerful and secure digital organization ready to scale to meet any enterprise needs.
Files.com is a multi-tenant platform that, by default, requires that all user names across all sites be unique.
If you need to use a user naming convention or have other requirements that mean you need to create user names that may exist in other sites on the platform, you can set up a custom user namespace by setting up a custom domain for your site and toggling the sitewide setting for Globally Unique Usernames to No, this site is using a custom namespace.
Note that if you have disabled Globally Unique Usernames (either through the setting or by setting up a custom domain for your site) and you are using a single-sign on provider, you must first disable your SSO integration before you can enable Globally Unique Usernames. This means you must edit every username associated with an SSO provider to change the authentication method first.
To ensure consistency in how your site is applying permissions, it is possible to require all Permissions to be assigned only to Groups, and not to individual users.
With this feature enabled, you can ensure that a group permission framework is followed, and no one - whether accidentally or purposely - grants users individual permissions.
Site administrators can enable this feature via a site-wide setting. To locate the setting, type "Manage all permissions via groups" in the search bar at the top of every page and choose the matching result. This setting requires the Power or Premier plan.
Enabling this setting will not remove permissions previously granted to individual users.
Before you add users, you’ll need to have a folder ready for them and, possibly, configure some global site settings before your users log in. We recommend you configure your site, create a folder for the user, and then create the user.
This step is optional, and you're not required to configure anything in your site before moving on to the next step.
However, when your users log in, they’ll interact with your site and you may want to apply some visual branding to it or apply some limitations and restrictions so that users cannot upload content that you wish to prohibit. You may choose to customize the menu categories visible to your users.
At a minimum, you may want to apply some branding, such as your logo and corporate color scheme, and define a folder structure as a “landing zone” for your users.
Your users will require a “home folder” so that, once they log in, they have a place where they can upload and download files.
Files.com allows you to create any folder structure you require and you can specify that any folder, or subfolder, becomes the “home folder” of a user.
For easier management, it’s best to place users into a well organized folder hierarchy. There is no “one size fits all” for a folder hierarchy but a common practice is to have a top-level folder named something like
Then, within this top-level folder, you can create subfolders for individual users, or subfolders for departments, teams, or groups, building a hierarchy that matches your needs.
For example, if you have a relatively small set of users, where you don't have a need to further differentiate them from each other, you could use a simple structure such as:
You could also arrange users based on their department, such as:
If your organization is global, you might wish to arrange users based on geographic regions, such as:
If your site will be used by both internal employees and external partners, you may wish to arrange users based on that criteria, such as:
Ultimately, the best hierarchy will be the one that best fits your business model.
If you have an existing identity system, such as an Active Directory or LDAP, or your users are being migrated from another system, then you may wish to match the folder hierarchy of the users as defined in that system.
If the users of your Files.com site are not related to the users of an existing system, or you wish to define a newer folder structure, then this is an opportunity to plan out a structure that best fits your needs.
To create folders, navigate to the Files section of your site and use the New Folder button to build the structure that you require.
You can also automate the creation of “home folders” for users.
Navigate to the folder that you want to create user “home folders” within, for example
home/, and select Folder Settings -> Automatically create new user folders here when users are created.
Once you've created some home folders, or configured them to be created automatically, you're ready to create user accounts.
Files.com offers a few different methods of creating a user. Site Administrators can use the Web to create a single user or use the Bulk import users feature to save time when creating multiple users. Additionally, we also offer the ability to Clone a user, and create user groups to help with onboarding additional users. With Files.com, you can also automate user creation using the API/SDKs or our CLI application.
To create a user, as a site administrator, type "Users" in the search box at the top of each screen and then click on the matching result. Click the New User button.
New user creation allows you to select authentication methods, group permissions, as well as Folder permissions on selected Folders for the user. Additionally, Advanced Settings are available while creating users. Using these settings you can setup additional configurations and permissions for this user including Admin permissions, IP restrictions, shared/bot user config, allowed protocols to be used, SSH (SFTP) keys, expiration date, to mention a few.
Files.com also offers seamless user provisioning and deprovisioning through the use of SCIM (System for Cross-domain Identity Management) and LDAP (Lightweight Directory Access Protocol). With SCIM, the process of creating and managing user accounts becomes automated, ensuring efficient and consistent user onboarding by using your existing identity provider. Additionally, LDAP integration provides a reliable method for accessing and maintaining directory services, making it easier to synchronize and manage user data.
Administrators can save time when creating a new user by cloning an existing user. This speeds up the user creation process by pre-populating most of the user's settings from the user being cloned, including group membership and permissions.
To clone a user, click the Clone button in the rightmost column of the user list.
You can create/import users in bulk via the web interface using our Bulk Create tool.
Type "Users" in the search box at the top of each page, and then click on the matching result. Click the Bulk Create button to open the tool, then expand the Supported columns legend to review the data options you can include with your import.
You can also use the Download CSV template button to get a copy of an example CSV file which you can modify to use for your import.
Once you have your CSV file populated according to the template and legend, use the Choose File button to select the CSV file from your local file system and then begin the import process.
The system will verify your file and show you any data errors that need to be corrected before your user import can be processed.
|COLUMN NAME||DESCRIPTION||ACCEPTABLE VALUES|
|username||The login name for the new user||REQUIRED - Can be any text|
|authentication_method||How the user's credentials are created.|
|password||The new user's password. Only valid if the authentication_method is password||Any text that matches your site's password rules|
|password_validity_days||How many days a password is valid before the user is required to change it. This overrides the site-wide setting.||Any whole number or 0. Can also be blank if not overriding the site-wide setting|
|require_password_change||Should the user be forced to change their password when the log in the first time?|
|The user's email address. Required if authentication_method is email_signup||A valid email|
|full_name||The user's full name.||Text containing at least 2 words separated by a space|
|company||The name of the user's associated company||Any text|
|group_ids||Which groups this user is a member of||Comma-separated list of numbers, which must be valid group IDs.|
|site_admin||Is this user an administrator (who has full access to the entire site and its settings)?|
|self_managed||Does this user manage its own credentials (i.e., is NOT a bot/shared user)?|
|notes||Any notes about this user. Will be visible to all site admins on the users page.||Any text|
|time_zone||What time zone the user is in||The time zone name|
|root_folder||Root folder for FTP (and optionally SFTP if the appropriate site-wide setting is set.) Note that this is not used for API, Desktop, or Web interface.|
Text containing a valid path to a folder the user has permission to access, e.g. "Customers/ACME" or "Sales". Does not need leading or trailing slashes.
When a user with a root folder logs in via FTP and the path does not exist (because it has been deleted), it will be automatically created, but the user will not have permissions to the folder.
|ip_whitelist||A list of IP addresses the user is allowed to connect from.||Text containing the IP addresses in CIDR format, separated by newline (\n) characters. You may specify a range in CIDR format, such as 192.168.1.0/27. Example: "22.214.171.124\n126.96.36.199\n192.168.17.0/27"|
|enforce_ip_whitelist||Should this user be required to connect from a site-allowed IP address? If |
|ssl_required||Whether the user is required to use TLS or SSL when connecting via FTP. If this is set to |
|access_expiration_date||Scheduled Date/Time at which user will be deactivated||Text containing a date in ISO 8601 format (YYYY-mm-ddTHH:MM:SS followed by offset from UTC) Example: 2020-03-14T13:27:01-04:00|
|ftp_permission||Whether the user is permitted to connect via FTP or FTPS|
|sftp_permission||Whether user can connect via SFTP|
|dav_permission||Can user connect with WebDAV?|
|restapi_permission||Can user connect via the web UI or the API?|
|folder_permissions||Permissions to automatically assign to new users||Text containing a list of folders and permissions, separated by pipe symbols (|), to assign to the newly created user.|
Automatically assign folder permissions to users with the folder_permissions column of the import file. Supply a list of folders and permissions, separated by pipe symbols, to be assigned to the user.
- admin : Able to manage settings for the folder.
- full : Able to read, write, move, delete, and rename files and folders.
- readonly : Able to list and download files and folders.
- writeonly : Able to upload files and create folders.
- readwrite : Shorthand for readonly,writeonly
- list : Able to list files and folders, but not download.
- bundle : Able to share files and folders via a share link.
- history : Able to view the history of files and folders.
This defines 3 permissions:
Home/Adam=admin. The user will be given Read-Only permission on the
/Sales folder, Read/Write and History permissions on the
/Engineering folder, and Admin permission on the
/Home/Adam folder. If any of those folders do not exist, they will be created automatically.
Use a slash for the folder name to specify the Root Folder, for example:
/=readonly. If a folder name contains a vertical bar, for example
Sales|North-America, the vertical bar must be escaped with a preceding backslash:
site_admin is enabled for the user, then the value of
folder_permissions is ignored, because site administrators have admin access to all folders.
Permissions are applied recursively to all sub-folders. To limit a permission to the specified folder name and not its sub-folders, add an asterisk
* after the permission value. For example:
A site administrator can unlock a user that has been locked due to repeated failed login attempts with these steps:
Type "Manage users" in the search box at the top of each page, and then click on the matching result. Find the locked user in the list, and click the Unlock button in the far-right column. Click the Unlock this user button to unlock the user.
You can adjust your site lockout settings. Type "Brute force protection" in the search box at the top of each page, and then click the matching result.
Below are the four main approaches to disable a user account:
Automatically disable users who have not logged in within a certain number of days. Type "Disable inactive users" in the search box at the top of each page, and then click the matching result. Enter a number of days after which users that have not logged in will automatically be disabled. This option disables the affected users within 24 hours of the specified duration. For example, if you set the duration to 7 days then the affected users will be disabled between the 7th and 8th day from their last activity. This is a site level setting and applies to all non-admin users.
If you want to bypass this setting for a particular user who is not a site administrator, edit the user's settings and enable the option Prevent this user from being disabled due to inactivity.
Manually disable a user's account by editing the user's settings to change the Account enabled toggle to the deactivated state. This option takes effect immediately.
Edit the user, go to the Authentication tab and scroll to the Access expiration date setting to specify the date when the user will not be able to log in. This approach allows you to set an end date for users with a known project duration or other situation where a specific date makes sense.
While setting up a new user account, you have the flexibility to specify a mandatory time window within which the user must perform their initial login. You can enter the number of days in the Number of days user must first login by field while creating a new user. Alternatively, you can set or modify this value by editing the user's setting Automatically disable this user if not logged in by this date. Note that this setting only applies to new users who have never logged in to the system at least once.
Once it is set, failure to log in within this prescribed period will result in an automatic deactivation of the user account, and any configured authentication methods will be removed. This proactive approach ensures that newly created accounts are put to use by their intended recipients as intended. This option disables the affected accounts within 24 hours of the specified duration. As an example, during the user creation process, if you set the Number of days user must first login by as 10 days, and the user fails to log in within that timeframe, the system will automatically disable the account between the 10th and 11th day from the user creation date.
User accounts which are marked as disabled will have to be re-enabled by a site administrator. Files.com does not provide any automated re-enablement of users, since re-enabling a user needs to be examined carefully by a site administrator.
Once a user is disabled/deactivated, they are not able to log in. A site administrator must explicitly re-enable the account using the setting noted as above in Manually Disable the User before the user may access the site.
Disabled users are not counted for billing purposes. User count or user's status has no relation to storage usage. Your site's storage usage will not be reduced if you disable users. If the file or folder is stored in Files.com, it counts toward storage usage.
Access to data transmission protocols can be specified for each user, allowing you to specify exactly which protocols a user is allowed to use to connect to Files.com.
Edit the users's settings and click on the Privileges tab. Scroll down to Protocol Access and select the Edit button. You can allow or disallow the selected user's access to FTP (including FTPS and FTPES), SFTP, WebDAV, Web Portal, Desktop app, and the Files.com API.
User accounts with Administrator access privileges, cannot be denied access to the Web Portal, Desktop app, and the Files.com API but can be disallowed from having access to FTP (including FTPS and FTPES), SFTP, and WebDAV.
Rather than disabling a user, site administrators can choose to completely delete a user from the site.
To access the list of users, type "Users" in the search box at the top of each page and click on the matching result. To delete a user, locate the user in the table, and click the Delete button. You will be prompted to enter your password to confirm the deletion.
A site administrator can use the Files.com Command Line App (CLI) to delete a user. First, you will need to obtain the user's ID. You can use a command similar to the one shown here (replace the
<NAME> with the username of the desired user)
files-cli users list --fields id,username --filter-by username=<NAME> --use-pager=false
Then, use the ID reported back from the files-cli and use it like this command (replace
<ID> with the ID of the user to delete)
files-cli users delete --id=<ID> --reauthenticate
When prompted, enter your password or 2FA code.
Share Links are not affected. When a user is deleted, any Share Links they have created are not deactivated. Site administrators have access to all Share Links and will still be able to change the settings or revoke any Share Links that were created by a now-deleted user.
Folder behaviors are not removed. With the exception of notifications for the now-deleted user, any folder behaviors they configured will still exist after the user is deleted.
Automations are not removed. Site admins can monitor and update existing automations, even if they were created by a now-deleted user.
Files and Folders are not automatically removed. Removing users does not remove "their" used storage.
There are four different types of "Administrative" permission levels that can be granted to a user.
Site Administrators are the highest level. Users with this permission have access to and authority over everything within your Files.com site including users, data, settings, and logs. The first user created on a site is a Site Administrator by default, however does not have any special permissions beyond that. The initial user can have his or her Site Administrator status revoked by another Site Administrator.
The additional, limited, administrator types are:
|Group Administrator||This type of admin is able to add and create users to existing groups for which the admin is responsible. Once users are created, group admins are not able to alter them. Any subsequent changes must be performed by a site admin.|
|Folder Administrator||This type of admin is able to manage folder settings for specific folders. A site administrator or another folder administrator must grant this user folder admin privileges for specific folders. Subfolders inherit folder admin privileges by default. The same user may be both a Group Administrator and a Folder Administrator for one or more folders.|
|Billing Administrator||This type of admin is able to access the User Profile -> Account tab and can see billing information, invoice history, and usage data.|
While you can set any user to be a Shared/Bot user, we anticipate each individual user on an account will be have their own set of permissions based on their security policies with your business. We strongly encourage our customers to create individual user accounts for each person accessing Files.com for their connections to manage appropriate permissions. However, some use cases require that accounts be shared among multiple people or automated scripts/bots.
You can set an account as Shared/Bot user to create a user account that is shared by multiple people, typically with limited access, or used by an automated script. To do this, edit the user's settings and click on the Privileges tab, then enable the toggle for Shared/bot user. Note that you can not set an account as Shared/Bot user if that user's authentication method is already associated with any SSO provider.
Shared/Bot users can use all aspects of the Web UI, including Previews and Office integration, but they have some special restrictions:
Users set as a Shared/Bot user are prevented from changing their own password, email address or time zone. For example, you may want to create one shared username through which several people will be uploading documents to your Files.com site. Creating that username as a Shared/Bot user prevents an individual from changing the password, email address or time zone, which would disrupt service for all of the other people attempting to use this user account.
Shared/Bot users bypass all 2FA requirements. 2FA requires a physical device, which would only be able to be possessed by one physical person. 2FA is disabled for Shared/Bot users to allow multiple people as well as automated scripts or bots to log in using this account.
Because of all the restrictions listed here, Shared/Bot users may not also be site admins. To promote a Shared/Bot user to an admin, you must first disable the Shared/Bot user setting before you can enable the Administrator access setting.
Site administrators can change the password for any user on their site by following these steps:
Type "Users" in the search box at the top of every page, and then click on the matching result. Click on the username of the user, then click the Authentication tab. Click Set new password, and you will be prompted to enter and confirm the new password. You'll also be prompted to re-authenticate by entering your own password for added security.
Users can also reset their own passwords themselves by using the Forgot your password? link on your site's login page. If the link is not present on your site's login page, you can enable it with the Password recovery via email setting. To find the setting, type "Password recovery via email" in the search box at the top of every page, and then click the matching result. Users must have an email address set in their user settings to receive a password reset email.
When creating new users, you can opt to manually set their password by selecting the Password authentication method (instead of the default Email signup) upon user creation.
To find your current list of users, type "Users" in the search box at the top of every page, and then click on the matching result. Any user account that has been disabled will be displayed in grey.
Site administrators are listed at the top, and have the "Site administrator" icon on their avatar. Bot/shared users have the "Bot/shared" icon on their avatar.
To download the entire list, we recommend using the Files.com Command Line App (CLI). To list all your users, run this command:
files-cli users list
The disabled field will be labelled true for disabled user accounts and false for active users.
You might find it helpful to export in CSV format and save that output to a file. Here's how to do that using the CLI:
files-cli users list --format csv > users.csv
Click here to download the CLI App. On that page, you'll need to pick your exact operating system to download the correct version.
The user list includes date and time information about user activity and user logins which can be used to audit or track users last activity on the Files.com platform.
When using the web portal, the user list includes the following columns:
|Last Login At||Shows the last time that the user performed a session login using their login credentials.|
|Last Active At||Shows the last time that the user was active. This includes activity performed using any connection interface.|
|Last Web Login At||Shows the last time that the user performed a session login in the Files.com web portal using their login credentials.|
|Last FTP Login At||Shows the last time that the user performed a session login using their login credentials via the FTP or FTPS protocols.|
|Last SFTP Login At||Shows the last time that the user performed a session login using their login credentials via the SFTP or SCP protocols.|
|Last WebDAV Login At||Shows the last time that the user performed a session login using their login credentials via the WebDAV or WebDAVS protocols.|
|Last Desktop App Login At||Shows the last time that the user performed a session login using their login credentials via the Files.com Desktop App.|
|Last REST API Login At||Shows the last time that the user performed a session login using their login credentials via the Files.com REST API.|
|Last API Usage At||Shows the last time that the user performed actions using the Files.com REST API, regardless of whether a session login or an API Key was used.|
When using the Command Line Integration (CLI) App to export the user list as a CSV file, the exported file will contain the following corresponding columns:
|last_login_at||Shows the last time that the user performed a session login using their login credentials.|
|last_active_at||Shows the last time that the user was active. This includes activity performed using any connection interface.|
|last_web_login_at||Shows the last time that the user performed a session login in the Files.com web portal using their login credentials.|
|last_ftp_login_at||Shows the last time that the user performed a session login using their login credentials via the FTP or FTPS protocols.|
|last_sftp_login_at||Shows the last time that the user performed a session login using their login credentials via the SFTP or SCP protocols.|
|last_dav_login_at||Shows the last time that the user performed a session login using their login credentials via the WebDAV or WebDAVS protocols.|
|last_desktop_login_at||Shows the last time that the user performed a session login using their login credentials via the Files.com Desktop App.|
|last_restapi_login_at||Shows the last time that the user performed a session login using their login credentials via the Files.com REST API.|
|last_api_use_at||Shows the last time that the user performed actions using the Files.com REST API, regardless of whether a session login or an API Key was used.|
Session logins include those where the user credentials are held in an external Identity Provider systems, such as Active Directory or LDAP systems.
Use of an API Key will only update the Last Active At and Last API Usage At fields. Use of an SSH/SFTP Key is identical to a session login and will update the Last Login At, Last Active At, and Last SFTP Login At fields.
Files.com includes a feature that allows non-users to request a user account on your site, streamlining the whole process from request to user creation.
Site administrators can enable this feature with a setting. To find the setting, type "Allow non-users to request a user account" in the search box at the top of every page, and then click the matching result.
If this setting is enabled, a Request an account link will appear under the Log in button on your login page. Clicking the Request an account will prompt the visitor to enter their information for a new user account.
To review account requests, type "User requests**"** in the search box at the top of every page, and then click the matching result. Click the Create user button to pre-populate the new user form with their name and email address. You can then provide the rest of the information, such as assigning a username and folder permissions.
Site administrators can be notified by email when a new user request is received. To find this feature, type "Notify admins of requests for a user account" in the search box at the top of every page, and then click the matching result. If this setting is enabled, all site admins who have not opted out of site alert emails will receive a notification email for each new user request.
Get Instant Access to Files.com
The button below will take you to our Free Trial signup page. Click on the white "Start My Free Trial" button, then fill out the short form on the next page. Your account will be activated instantly. You can dive in and start yourself or let us help. The choice is yours.Start My Free Trial