Theme
Before you install
Five minutes of planning here saves an afternoon later.
Where to put it
Put the Connector on a machine that is close to your storage, not close to your users. Every byte a user transfers passes through it, so the link between the Connector and the storage is the one that matters.
Good places:
- The file server itself, or a machine on the same LAN.
- A small VM in the same cloud account and region as your S3, Azure or GCS storage.
The machine does not need to be powerful. It moves bytes and checks permissions; it does not index, transcode or scan anything.
Supported platforms
| Platform | How | Download |
|---|---|---|
| Windows | Graphical installer, runs as a Windows service | sc-setup-windows-amd64.zip |
| Linux | Command line installer, runs as a systemd service | sc-setup-linux-amd64.tar.gz, sc-setup-linux-arm64.tar.gz |
| Docker | Official image, docker.io/syncplify/sc-conn | Nothing to download |
Every installer download is one archive holding the installer and its signature together. Extract it and run it; there is nothing to rename, and on the POSIX platforms nothing to chmod.
macOS and FreeBSD builds exist and are installed from the command line: see Install on macOS and FreeBSD. They are not the recommended production target today.
Network access
The Connector makes outbound connections only. There is nothing to open inbound, ever.
| Direction | Destination | Port | Why |
|---|---|---|---|
| Outbound | portal.sftp.cloud | 443 | Enrollment, re-enrollment, and renewing the Connector's certificate every few weeks |
| Outbound | Your site's server, head-<id>.on.sftp.cloud | 7600 | The permanent control and data link |
| Outbound | The release channel, sc-release.us-ord-10.linodeobjects.com | 443 | Checking for updates once a day, and downloading one you approve |
| Outbound | Your storage | whatever it uses | Reaching the actual files |
The release channel is the only one of these you can do without: block it and the Connector keeps working, it simply stops noticing new versions, and System > Updates will say when it last managed to look.
Leave the Portal rule open after enrolling
The certificate the Connector presents to your site lasts thirty days. The Connector renews it by itself, starting halfway through, over this connection to the Portal, and keeps trying every hour. If it cannot reach the Portal for the whole second half of that period, the certificate lapses and your site stops admitting the Connector the next time it reconnects.
It recovers by itself as soon as it can reach the Portal again; nothing has to be re-enrolled. But a rule that was opened for enrollment and closed afterwards takes the storage offline a month later, with nothing having visibly changed.
The Connector's dashboard warns you about a week before the certificate ends if it has not managed to renew it. See Troubleshooting.
The exact hostname to allow
Port 7600 is the one a firewall usually has to be told about, and the host it goes to is specific to your site. The Connector prints it. Open the Connector's admin console and go to System > Network: it lists every destination this Connector dials, by name and port, taken from its live enrollment, and shows whether each one is currently connecting. There is a Copy as text button for handing to whoever runs your firewall.
Do not write the rule against your site address
Your site address, the <yoursite>.on.sftp.cloud name your users connect to, is a CNAME pointing at the server your site currently runs on. It resolves to the same place today, so a rule written against it appears to work. It stops working the moment your site is moved to a different server, because for the duration of the move the Connector must reach both servers, and your site address names only one of them. Always use the hostnames the Connector's Network page lists.
Behind a proxy
The Connector needs a direct TCP connection to port 7600. An HTTP proxy that only forwards ports 80 and 443 will not carry it.
An accurate clock
The machine's clock must be right to within five minutes. Every session your site opens on the Connector carries a voucher stamped with the time it was issued, and the Connector refuses one that looks too old or dated in the future. That check is what stops a captured voucher from being used again later, and it can only work if the two clocks roughly agree.
Leave automatic time synchronization on, which is the default on every supported platform:
| Platform | What keeps the time |
|---|---|
| Windows | The Windows Time service, or your domain controller on a domain joined machine |
| Linux | systemd-timesyncd, chrony or ntpd, whichever your distribution ships |
| Docker | Nothing in the container: it uses the clock of the host it runs on |
The time zone does not matter, only the instant. A virtual machine that was paused or restored from a snapshot is the usual way a clock ends up far off without anyone touching it.
If the clock does drift past five minutes, the link stays up and every sign in is refused. Both the Connector's dashboard and the Portal's Storage page say so in words, and correcting the time is the whole fix. See Troubleshooting.
The data directory
The Connector keeps its database, its identity, its encryption keys and its signed logs in one data directory.
| Platform | Default |
|---|---|
| Windows | C:\ProgramData\Syncplify\sc-conn |
| Linux, macOS, FreeBSD | /opt/Syncplify/sc-conn |
| Docker | /data inside the container, on a volume |
You can put it elsewhere with --datadir at install time, or the SC_CONN_DATADIR environment variable.
Back this directory up
It holds your at rest encryption keys. Syncplify does not have them and cannot recover them. If you lose the directory and you were encrypting at rest, the encrypted data is unreadable forever.
It also holds the Connector's identity. Losing that means re-enrolling, which is a minor inconvenience by comparison.
Decide these before you start
Will the admin console be reached from this machine, or another one?
- From this machine: the default. Plain HTTP on
127.0.0.1:8883, reachable only from the machine itself. - From another machine: install with
--access network, which binds0.0.0.0:8883over HTTPS with a self signed certificate. Your browser warns about that certificate once.
Will you encrypt at rest? The choice is permanent per virtual file system and cannot be changed afterwards. Read Encryption at rest before you create your first one, not after.
Which storage will this Connector serve? Have the paths, buckets or credentials to hand. See Storage backends.
One Connector or several
One Connector can serve many virtual file systems, and one site can have many Connectors.
Use several when:
- Your storage is in genuinely different places, for example one on premises file server and one cloud bucket in another region.
- You want a failure of one machine to leave the rest of the namespace working.
Each Connector claims one connector slot on your plan.
Get the enrollment code last
The code expires, by default after 24 hours, and is shown once. Install first, then mint the code, then paste it. See Connect your storage.