Create your first user

A user is an account one of your people, or an automated system, signs in with to transfer files. It is not a Portal account: your users never see the Portal, and your Portal team members are not users.

Creating one takes two steps in two places, and both are required:

1. In the Portal, you create the account.
2. On the Connector, you grant it access to storage. That grant does double duty: it decides what the user may do, and the first granted storage becomes their home folder automatically.

A user created in the Portal but not yet granted anything on the Connector cannot sign in; the refusal says exactly that, so nobody is left guessing.

Already have users on another server? Import them instead of creating them one by one; the same two steps happen, in bulk.

Before you start

You can create the account at any time, even before any storage exists. For the user to actually sign in, your Connector must be connected, must have at least one virtual file system, and must have granted this user access to it; that is part 2. See Virtual file systems.

Part 1: in the Portal

Open your site, choose Users, then New user.

Username

Type the short name only, for example alice. The Portal adds the site name itself, so on site acme the full username becomes alice@acme. That full form is what the user types when they connect.

The rules: lowercase letters, digits, dots, underscores and hyphens; it must start with a letter or a digit; at most 63 characters.

On a dedicated site the panel may say Signs in as alice, meaning the short form works too because no other user on that server carries it. On a shared site the full form is always required.

Display name

Optional, for your own benefit in the Portal.

Sign in method

Password or SSH key is the ordinary choice and what the rest of this page assumes.

Organization sign in is for a site connected to your identity provider: the user signs in to the web client with their organization account, needs an email here that matches the one your provider reports, and holds no password on this site at all. See Sign in with your identity provider.

How they sign in

For a password or SSH key user, give the user at least one of these:

• Password. Subject to your site's password rules, if you have set any on Site settings.
• SSH public keys. One per line, in authorized_keys form, starting ssh-ed25519 or ssh-rsa.

Both is fine. Neither is refused: the form warns you the user will have no way to sign in.

For SFTP, prefer a key

A password on its own is a single factor on SFTP, FTPS and FTPES, because those protocols have no way to ask for a code. A key is stronger and does not expire. See Two step verification and what it covers below.

Which protocols they may use

Tick the protocols this user may connect over: SFTP, FTPS, FTPES, Web browser. Leave everything unchecked to allow all of them.

A user's allowance is combined with the site's: a protocol switched off on Site settings is off for everybody, whatever a user's own list says.

Home folders

Automatic is the default, and for most users the right one: whatever storage a Connector administrator grants this user becomes their home, by itself.

• One granted storage opens as their starting folder.
• Several: the first granted storage is the starting folder, and each further one appears inside it as a folder named after the storage. A later grant never moves an existing home.
• No grant yet: sign in is refused, with a message that names this as the reason.

Custom replaces that with an explicit map, for the users who need one (a shared drop area at /incoming beside a personal home, say). Each row is a path the user sees and a virtual file system on one of your Connectors:

• Exactly one row must be at /. That is where the user lands.
• Add more rows to place other storage at other paths, for example /archive.
• Two rows may not use the same path.

Folder they see	On storage
/	Company files
/archive	Cold archive

Switching a user back to Automatic clears the custom map and hands the layout back to the grants.

When you disconnect a Connector, the Custom rows that named its storage are removed from every user and listed under Removed folders in the editor, with the storage and the date. Restore puts the row back once that storage is connected again; Forget drops it. A user whose starting folder was on the disconnected storage is switched back to Automatic.

What this does not control

Either way, this decides where storage appears in the user's session. What the user may DO there is the Connector's decision, in part 2.

Optional settings

Setting	What it does
File sharing	Whether the user may create share links, whether they may create upload shares, whether shares must carry a password, and the longest expiry they may set
Allowed networks	One IP address or network in CIDR form per line. Empty allows sign in from anywhere. Up to 64 entries
Max concurrent sessions	0 means no cap
Upload and download speed caps	In KiB per second, per session. 0 means no cap. Where a site wide cap also exists, the stricter value wins

Choose Create user.

Part 2: on the Connector

Open your Connector's admin console, at http://localhost:8883 on the machine it runs on.

1. Choose Access, then Users. Your new user is listed there, synced automatically from the Portal. If it is not there yet, wait a moment and refresh.
2. Open the user, then choose Give access.
3. Which folders. Pick a folder set, or choose Or just one folder and pick the virtual file system.
4. What can they do. Pick a permission level for each folder:
   • 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.
5. Review, then Give access.

If the user is connected at that moment, their sessions end so the new access applies immediately.

For a user on Automatic home folders, this grant is also what creates their home: within about half a minute of the grant, their sign in starts working and the granted storage is where they land.

Full detail: Permissions.

Part 3: tell the user

Give them:

• The address. Your site's platform address, from Overview, under How your people connect.
• Their full username, including the part after the @.
• Their password, through a channel that is not the same email that carries the address. Turn on Must change the password at the next WebClient sign in in the editor, and the password you send is only ever temporary: they choose their own at their first web client sign in.
• The SSH host key fingerprint, from Settings, under Advanced, so they can check they are talking to your site the first time they connect.

Point them at What you were given, which is written for them and carries no SFTP.cloud branding.

Two step verification and what it covers

This catches people out, so it is stated plainly.

Two step verification applies in the web browser client only. Your users enroll an authenticator or a passkey there themselves, and it is asked for when they sign in there.

SFTP, FTPS and FTPES cannot ask for a code. There is no place in those protocols to prompt for one. On those protocols, a password is a single factor on its own.

What to do about it, in order of preference:

1. Give the user an SSH public key and leave their password empty. Their key is then the only way in on SFTP, and it is strong.
2. Limit the user to the web browser client, on Which protocols they may use.
3. Have the user create app passwords in the web client and stop using their account password in desktop clients. An app password is still a single secret, but it is one per program, protocol scoped, optionally expiring, and revocable on its own, which is much better hygiene than one password everywhere.
4. Turn on Refuse password sign in for every user for the whole site, on Site settings. Read that section first: an authenticator app does not satisfy it, and neither does an app password. Only an SSH key or a passkey does.

Seats

Each active user occupies one of the user accounts your plan includes. Disabling a user frees the seat immediately; disabled users cost nothing. If you are out of seats, the form says so and points at Plan and billing.