Install on Linux

The Linux installer is a single command line program. It downloads the Connector, verifies its signature, installs it, registers a systemd service, starts it, and prints the setup wizard URL.

You need root, or sudo.

Install

Download the installer archive for your architecture from sftp.cloud/downloads, or straight from the link in the table below, then extract it and run it:

tar xzf sc-setup-linux-amd64.tar.gz
sudo ./sc-setup install

Or as one line, which is what you want in a provisioning script:

curl -fsSLO https://sc-release.us-ord-10.linodeobjects.com/sc-setup/latest/sc-setup-linux-amd64.tar.gz \
  && tar xzf sc-setup-linux-amd64.tar.gz \
  && sudo ./sc-setup install

Architecture	Archive
x86-64 (amd64)	sc-setup-linux-amd64.tar.gz
ARM64 (aarch64)	sc-setup-linux-arm64.tar.gz

Run uname -m if you are not sure which you need: x86_64 means amd64, aarch64 means arm64.

The archive extracts two files into the current directory:

File	What it is
sc-setup	The installer. Already executable, so there is no chmod step
sc-setup.sig	Its signature

Keep both files together

The installer verifies itself against sc-setup.sig before it touches anything, and refuses to run without it. Extract the whole archive into one folder and run sc-setup from there. Do not move or rename one file without the other.

It asks how the admin console should be reachable, then reports each step and finishes with the URL to open.

For a headless server with no browser on it, install with network access so you can finish the setup from your workstation:

sudo ./sc-setup install --access network

That binds 0.0.0.0:8883 over HTTPS with a self signed certificate. Your browser warns about that certificate once; that is expected.

Continue with First run.

What it installed

Thing	Where
The program	/usr/local/bin/sc-conn
The uninstaller	/usr/local/bin/sc-setup
The data directory	/opt/Syncplify/sc-conn
The service	A systemd unit, enabled and started

Signature verification

Two separate checks happen, both against a release key built into the installer itself:

1. The installer verifies itself against sc-setup.sig before it does anything at all. This is step 1 of 8, and it is why the two extracted files have to stay together.
2. It then verifies the Connector package it downloads, before installing it.

That key is held offline by Syncplify. Neither the Portal nor your site holds it, so neither of them can distribute a Connector build, or an installer, that a machine would accept.

If you want to check the download before you extract it, every published file is listed in checksums.txt:

curl -fsSLO https://sc-release.us-ord-10.linodeobjects.com/sc-setup/latest/checksums.txt
sha256sum --ignore-missing -c checksums.txt

That is a convenience, not the security boundary. The signature check in step 1 is the boundary, and it always runs.

All the flags

sc-setup install [--access local|network] [--datadir DIR] [--package FILE]
                 [--base-url URL] [--channel stable] [--version X] [--silent]
sc-setup uninstall [--purge] [--datadir DIR] [--yes]
sc-setup version [--json]

Flag	Effect
--access local or --access network	How the admin console binds. Asked interactively when omitted; local when there is no terminal
--datadir DIR	A different data directory. Recorded so uninstall finds it again
--package FILE	Install from a local signed package instead of downloading, for air gapped machines
--version X	Install an exact version instead of the channel's current release
--channel stable	A different release channel
--silent or -S	No prompts; defaults for every question

--package cannot be combined with --base-url, --channel or --version.

Air gapped install

On a machine with no internet access:

1. Download the signed package on a machine that does have access.
2. Move it across.
3. sudo ./sc-setup install --package ./sc-conn-<version>.pkg

The package is verified against the same baked in key. Enrollment then uses the manual bundle path rather than a code; see Enroll to your site.

Managing the service

sudo sc-conn svc status
sudo sc-conn svc stop
sudo sc-conn svc start
sudo sc-conn svc restart

systemctl works too.

Logs

The service writes its log to files in /opt/Syncplify/sc-conn/logs. The file being written is sc-conn.jsonl; older ones carry a date in their name. It can be pointed at another directory, at the system journal (the stdout output) or at syslog from Settings.

tail -f /opt/Syncplify/sc-conn/logs/sc-conn.jsonl

A Connector first installed at version 1.0.28 or earlier writes to the system journal unless you changed it, and an update leaves that choice alone:

journalctl -u sc-conn -f

The signed, tamper evident operation log is separate, always written, and lives in the audit directory under the data directory. See Log integrity.

Updating

Do not re-run the installer to update. Updates have their own path, with a rollback slot and an automatic health check. See Updates.

Uninstalling

sudo sc-setup uninstall

The data directory is kept, so reinstalling picks up exactly where the Connector left off: same identity, same virtual file systems, same encryption keys, same enrollment.

To delete it as well:

sudo sc-setup uninstall --purge

--purge is permanent

It deletes your at rest encryption keys. Syncplify does not have them and cannot recover them. Any data still encrypted with them becomes permanently unreadable.