Syncplify.me Server v8

Appearance

Running the services under dedicated accounts ​

A default installation runs both the Web/REST service and every worker service as LocalSystem on Windows and as root on Linux. Many hardening policies want them on dedicated accounts instead, and the product supports that, with one thing worth knowing: the two services talk to each other over a control channel the operating system itself guards, and that guard must admit both of them.

The control channel ​

Every worker exposes a small control channel that the Web/REST service uses to read live sessions, feed the dashboard, clear the anti hammering blocklist, drain the node, terminate transfers and trigger reloads. It is a named pipe on Windows and a unix domain socket on Linux, never a TCP port, so nothing else on the machine, and no browser, can reach it. Every request on it also carries a secret minted when the worker starts.

Because the operating system enforces who may open the pipe or the socket, the services do not have to trust each other or guess which account the other one uses. They only have to be admitted, which the sections below explain.

Windows ​

The pipe admits SYSTEM, the local Administrators group, the account the worker itself runs as, and the two services by their service identity. Every Windows service has a security identifier derived from its name, shown as NT SERVICE\ss-webrest and NT SERVICE\ss-wrk-<site>, and Windows places it in the service's token whatever account the service logs on as, provided the service was installed with a service SID type. The installer sets that on every new install and on every upgrade, so on a current installation nothing needs to be done: change the Log On As account of either service in services.msc, restart it, and the control channel keeps working.

To check an installation:

sc qsidtype ss-webrest
sc qsidtype ss-wrk-<site>

Both must report SERVICE_SID_TYPE: UNRESTRICTED. If one reports NONE, the service was installed by a version that predates this mechanism and has not been reinstalled since. Run the install command once, from an elevated prompt, and restart the service:

ss-webrest svc install
ss-wrk svc install --virtualsite <site>

Both commands are safe to repeat: on an already installed service they change nothing except the SID type.

Any log on type works: LocalSystem, LocalService, NetworkService, a local or domain user, a group managed service account, or the virtual account NT SERVICE\<name>. The account still needs what any service account needs, the right to log on as a service and read and write access to C:\ProgramData\Syncplify\Server; that part is unchanged.

Linux ​

The socket lives under /opt/Syncplify/Server/data/run, mode 0600 in a 0700 directory, which admits the worker's own account and nobody else. When the two services run as different accounts they are joined through a group named syncplify. The product does not create it; its presence is how you tell the worker that sharing is deliberate.

  1. Create the group and add both service accounts to it:

    groupadd syncplify
usermod -aG syncplify <webrest account>
usermod -aG syncplify <worker account>

  2. Give each unit its account. Run systemctl edit ss-webrest and systemctl edit ss-wrk-<site>, then put this in each override:

    [Service]
User=<account>
SupplementaryGroups=syncplify

  3. Make sure both accounts can use /opt/Syncplify/Server/data and /opt/Syncplify/Server/log, then restart the worker first and the Web/REST service after it.

On start the worker hands the socket directory and the socket to the group, 0750 and 0660, and logs that it did. If the group exists but the worker's account is not a member, the kernel refuses the hand over, the socket stays private, and the worker logs a warning saying so. Without the group, nothing changes.

What you see when it is not set up ​

Nothing fails at startup, because each service starts fine on its own. What fails is the connection between them, and the product says so in three places:

  1. The Web/REST service logs a warning naming the account it runs as and the pipe or socket that refused it, once every ten minutes for as long as the refusal lasts.
  2. A notification titled Worker control channel refused appears in the Admin UI, once per start of the Web/REST service, with the same details and the fix.
  3. The dashboard shows the reason next to its live indicator instead of just going grey.

A worker whose own account is refused by its pipe, which is a Windows worker on a dedicated account without a service SID, logs an error and raises a notification titled Worker control channel failed, and keeps serving clients meanwhile.

The escape hatch ​

If, in some environment the above does not cover, the local transport cannot be made to work, the worker can be told to use an authenticated loopback TCP listener instead:

ss-wrk serve --virtualsite <site> --ipc-transport tcp

or the equivalent environment variable SS_IPCTRANSPORT=tcp. On Linux put Environment=SS_IPCTRANSPORT=tcp in the unit override. On Windows add SS_IPCTRANSPORT=tcp to the Environment value (type REG_MULTI_SZ) under HKLM\SYSTEM\CurrentControlSet\Services\ss-wrk-<site> and restart the service. The Web/REST service needs no setting: it learns the transport from the worker.

This is a last resort, not a configuration option. Every request on the loopback listener still requires the worker's secret, so it is degraded rather than exposed, but it gives up the guard the operating system provides, and the worker logs a warning at every start for as long as it is in force. Use it to keep a system running while the real cause is found, then remove it.