Users

The Users page on a site lists the accounts your people sign in with to transfer files. Creating the first one is covered step by step in Create your first user; this page is what you need afterwards.

What the list shows

Column	Meaning
User	The full username, including the part after the @. A badge marks a user on organization sign in, and whether their first sign in has completed the provider link
Status	Active or Disabled
Protocols	Which ways this user may connect. All protocols means no restriction
Storage	Where their folders come from right now, read live from your site: Automatic (derived from the Connector grants), Custom (an explicit map on the user), or No storage yet (nothing granted, so sign in is refused). Empty while your site cannot be reached. Removed folders: n beside it counts folders a storage disconnect removed, waiting in the editor to be restored or forgotten

Above the list, a filter row narrows it: a search box for the username or name, a Storage switch (all, No storage yet, Automatic, Custom), and From an import. Users the guided import created carry an Imported badge; combine the two filters to watch the storage half of an import land Connector by Connector.

Editing a user

Open the user to edit them. Two things about the editor are worth knowing before you touch it.

Nothing changes until you save. The drawer stages your edits and applies them in one motion.

Credentials are write only. SFTP.cloud cannot show you a stored password or a stored key, because it does not hold them in a readable form. So the editor works in explicit intentions rather than in current values:

You do	What happens on save
Nothing to the password	It stays exactly as it is
Change, then type a new one	It becomes the new password
Change, then leave it empty	The password is removed. Only their key will sign them in
Nothing to the keys	They stay exactly as they are
Replace, then paste keys	All their keys are replaced by the ones you pasted
Remove all	Every key is removed. Only their password will sign them in
Must change the password at the next WebClient sign in	The user is held on a change password screen at their next web client sign in. See below

The editor shows a pending note under each field describing what saving will do, and an Undo on each. If you remove both the password and the keys, it warns you the user will have no way to sign in.

The same rule applies to every other field: a field you do not touch is left alone.

Requiring a password change

Turn on Must change the password at the next WebClient sign in when you create a user with a temporary password, or at any time later. The user signs in to the web client as usual, password and second factor included, and is then held on a Choose a new password screen; nothing else in the web client works until they set one. The list shows Password change pending until they do, and the demand ends the moment the password changes. Turn the switch off to waive it.

Three things to know:

• It applies to the web client only. SFTP and FTPS cannot show a form, so they keep accepting the current password until it changes. A scheduled transfer does not stop.
• Setting a new password yourself does not waive it. A temporary password and the demand are one common move, so saving both together works as you would expect.
• A user who cannot reach the web client can never comply. The editor warns you when the user's protocols exclude the web client, or when the user signs in through your organization and has no password here.

The user's own change is recorded in your activity as a transfer user changed their own password, within a couple of minutes.

Sign in method and email

Sign in method is Password or SSH key, or Organization sign in for a site connected to your identity provider. A federated user requires an email matching the one your provider reports, holds no password here (switching an existing user over removes any stored password), and shows Pending first sign in until their first successful sign in completes the provider link. Switching a linked user back to Password or SSH key drops the link, and the provider account may later be linked to somebody else.

Home folders

Automatic (the default) derives the user's folders from what the Connector administrators grant: the first granted storage is their starting folder, further ones appear inside it, and with no grant their sign in is refused by name. Custom is an explicit map for the users who need one. The Storage column on the list shows which is in force, read from your site rather than guessed.

Custom folders that named storage you disconnected are moved to Removed folders in the editor: restore one once that storage is connected again, or forget it. A Custom folder whose Connector is merely not connected right now stays in the map, shows in the user's listings, and refuses to open until the Connector is back.

App passwords

If the user has created app passwords in the web client, the editor lists them by name with their protocols and dates, never the credentials themselves. Revoke ends one immediately: new sign ins with it are refused from that moment. Revoking is the right first move for any credential you suspect, and it touches nothing else on the account.

Disabling a user

Choose Disable.

• The user is disconnected immediately, including any transfer in progress.
• Every future sign in is refused.
• Their files and settings are kept.
• The seat is freed right away, so a disabled user costs nothing.

Enable them again at any time; everything comes back as it was.

Disabling is the right move for somebody who has left, somebody on long leave, and any account you suspect. It is reversible, immediate, and free.

Removing a user

Choose Remove. The user is removed from your site and signed out everywhere.

Files on your storage are not touched. Removing an account never deletes data.

Removal is permanent. If you might want the account back, disable it instead.

Resetting somebody's two step verification

If a user has lost the phone with their authenticator on it:

1. Open the user.
2. Under Two factor sign in, choose Reset all second factors.

That removes their authenticator and every passkey. They can then sign in with their password or key and enroll again from the web client.

You can also remove a single passkey, leaving the rest in place.

What you can and cannot see

The panel shows whether an authenticator is enrolled and lists their passkeys. It never shows the authenticator secret, and there is no way to read it.

Short usernames on a dedicated site

On a dedicated site, a user whose short name is unique on that server can sign in with the short form: alice rather than alice@acme.

This is derived live, never stored. So:

• If you create a second user called alice on a different site that shares the same dedicated server, both must then use the full form. The Portal warns you at creation time and names the users affected.
• On a shared site the short form is never offered, even when the name happens to be unique today, because another customer could take it tomorrow.

The full form always works everywhere. When in doubt, hand out the full form.

Signing somebody out immediately

Disabling the user is the reliable way. It ends live sessions, including transfers in progress, and refuses every reconnection.

Changing a password yourself does not by itself end a session that is already open. When the user changes it (from the web client's Settings, a required change, or a reset link), every other web client session of theirs ends at once and their trusted browsers are forgotten; connected SFTP and FTPS programs finish what they are doing and reconnect with the new password.

Whether a user can reset a forgotten password by email is a site setting; see Site settings.

When a user says they cannot connect

Work down this list in order.

1. Is the user active? A disabled user is refused with no explanation to them.
2. Is the protocol allowed? Check the user's own protocol list, and the site wide list on Site settings. A protocol switched off at the site level is off for everybody.
3. Are they using the full username? alice@acme, not alice, unless the site is dedicated and the panel says the short form works.
4. Are they connecting from an allowed network? Check Allowed networks on the user, and the country and network rules on Site security.
5. Is their address banned? Check Currently banned on the site's protection settings.
6. Is the Connector connected? If Storage shows it as not seen recently, a user whose starting folder is elsewhere still signs in; the folders on that Connector show but refuse to open (the web client says the storage is offline). A user whose starting folder is on it is refused until it is back.
7. Have they been granted anything on the Connector? A user on Automatic home folders with no grant is refused at sign in, and the message names this as the reason. A user with a Custom map signs in but sees closed folders wherever permission is missing.
8. Are they using a revoked, expired, or protocol limited app password? Check the app password list on the user: a revoked or expired credential is refused, and one scoped to SFTP only will never open FTPS.
9. Do they sign in through your organization? A federated user has no account password: desktop clients need an app password or an SSH key, and the web client sign in is through the organization button. If the provider itself refuses them, that is between them and your identity team; nothing here will say more.

Failures never tell the user which of these it was, deliberately. The Activity log and the Connector's own log carry the real reason.

Automation and service accounts

A user account for a script or a scheduled job is an ordinary user. Two habits make it a better one:

• Give it an SSH key and no password, so nothing about it can be guessed. Where a key is not practical, a dedicated app password with an expiry beats the account password: it is scoped, revocable on its own, and stops on schedule.
• Restrict Allowed networks to the addresses the job actually runs from.

See Automated and scheduled transfers.

Automation identity

A different kind of account is the automation identity: a user your Connectors may run transfer jobs as, from a script or a schedule, without any credential. Turn on Automation identity in the user's settings. The user's permissions on every Connector decide what those jobs may read and where they may write, so give it exactly the folders your automation needs and nothing else; a job needs only the storage it touches to be reachable. The switch changes nothing about how the user signs in; it only lets your own Connectors act as that user for transfers. See Transfers from a script.