This section covers various topics related to the day-to-day operation of your Syncplify Server!

Where is the manual?

This knowledge base covers some common topics in a broader way than a manual ever could, but it's limited to those topics, and it doesn't have the full coverage that a true manual has.

You can find the full Syncplify Server! Manual here.

We strongly advise and recommend that you thoroughly study it. It will save you hours on day-to-day operation, and you won't have to wait for our support staff to respond to your assistance request, because you'll have the knowledge, the power, and the ability to manage your server effectively and independently.

Using network shares (UNC paths) with Syncplify Server! v6+ on Windows

Windows does not allow system services running as SYSTEM (or LocalSystem) to access UNC paths. This is a design choice by Microsoft, so every system service of every vendor (not just Syncplify) is subject to it.

So what can you do when you need your system service to access those "network shares"? For example you may want to place your users home-VFSs on a different storage (this is practically mandatory in high-availability environments).

The correct and secure way to do it (according to Microsoft's Best Practices) is the following:

Step #1 - Create a Windows or Active Directory "service account"

A service account is just a user account which will be used to run your system service. This particular account will have to be given permissions onto the following directories/folders:

To avoid unattended-operation complications, it's best to set this account to never expire and to never have to change its own password. An Administrator should take care of that, from time to time, according to corporate policies.


Step #2 - Grant the proper storage permissions to the service account

As already described above, this newly created service account will need to be granted access permissions to the folders and network paths listed above:


Step #3 - Run your virtual site's "worker" service impersonated with the above service account

Open Windows' SCM (Service Control Manager) and locate the "worker" (wrk) service for the virtual site you need to be able to access UNC paths:


Double click on it, and set it to run "as" the impersonation account you previously created:


Do not forget to restart the virtual site's system service for these changes to take effect

Once restarted, if you did everything correctly, the virtual site will now be able to access its users' home-VFSs located on the remote UNC paths (network shares) the service account has access to.

Using network shares (UNC paths) with Syncplify Server! v6+ on Linux

Since the Linux version of Syncplify Server! is implemented as a systemd service, this knowledge base article assumes a basic familiarity with the Linux operating system and with its systemd subsystem.

All of the operations below are assumes to be performed as root or via sudo.

First of all you need to prepare, ahead of time, a file containing the credentials that will be needed to access the SMB/CIFS shared path. For the sake of this tutorial we will save these credentials in the /etc/.smbcreds file, which will have this format and contents (but with your own credentials, of course):


Next, you have to create a directory that will be used as local "mount point? for the remote SMB/CIFS share when it's mounted on system boot. For the sake of this example let's call it sftpdata:

mkdir /sftpdata

Now you will have to create two files in systemd's configurations directory. It doesn't matter how you call these files, as long as they have the same name, and the exact extensions shown here below:

File: /etc/systemd/system/smbsftpdata.mount


File: /etc/systemd/system/smbsftpdata.automount



The last step is to enable the automount in systemd, so that next time the OS boots this shared path will be automatically mounted in your system:

systemctl enable smbsftpdata.automount

Done! Now reboot your operating system, and after the reboot systemd services (including Syncplify Server!) will have access to your remote SMB/CIFS shared folder contents via the local mount point /sftpdata.

How to backup your Syncplify.me Server! v4/v5

This article refers to old/discontinued versions of our software.

Backing up your Syncplify.me Server! v4 or v5 is a very simple process, it basically consists of just 1 simple step shown below. But please read the whole article, as there are some important notes for those who are running very old version 4's.

Running a very old v4?

If you are running a version prior to v4.2.5 your software does not have a backup function. In order to enable such function, please make sure that you’re running v4.2.5.

How to take a backup

Backups can only be taken locally, on the same machine/VM where Syncplify.me Server! is installed, by pasting a very special URL into your browser (any browser except Internet Explorer).

Provided you're using the standard port our software comes pre-configured with, if you're running v4 this is your special URL to produce a backup file:\SMSBackup&file=BK$datetime

While if you're running v5 this is the special URL you need:\SMSBackup&file=BK$datetime

Of course if you're running our Web/REST interfaces on ports other than 4443 (for v4) or 5443 (for v5) you'll have to edit the special URLs here above, and specify the actual port you're using.

Once you paste the special URL into a local browser on the server, you'll see a small OK message. At that point you will find a zip archive containing the current full backup of your Syncplify.me Server! software in the following folder: C:\SMSBackup

Insecure warning in your browser? It might be OK...

After installing Syncplify Server! you will be able to manage it securely via web interface over HTTPS.

Now, a very common choice is to use a self-signed certificate, because it saves money and if you know what you’re doing it doesn’t compromise security. This is, in fact, the most common choice among our users (according to our surveys).

But if you use a self-signed certificate, your browser will warn you that your connection may not be private or secure. That’s because self-signed certificates are often used for man-in-the-middle (MitM) attacks. But this is not the case, of course, if you can verify that this particular self-signed certificate was created by you and for you.

To get rid of this annoying message, you basically have 2 options:

  1. Spend some money to buy a trusted X.509 (SSL/TLS) certificate from a Certification Authority like DigiCert, Comodo, Thawte, and the like. It goes without saying that this is the recommended choice, as it takes advantage of the inherent trust chain provided by the Certification Authority.
  2. Verify and accept the self-signed certificate you have just created and add it to the trusted keychain of your browser. In this case, you are advised to always verify the certificate’s fingerprint to make sure it’s really the one you created yourself, and that you’re not a victim of a Man-in-the-Middle (MitM) attack.

If you have chosen option #2, here’s how you do it in Chrome:


This is how you do it in Firefox:


And this is how you do it in the new Chrome-based Microsoft Edge (the old Edge is very similar though):


If you're using a self-signed certificate (or if you're accessing the management UI via its IP address instead of host name) it's totally normal for this to happen, and you can safely go ahead and skip the browser warning. Once you do that, you will be able to securely access Syncplify.me Server!’s a web management interface.

We purposely don’t show any screenshot taken with Internet Explorer, as its JavaScript support (depending on the browser version) is generally too buggy, and we do not support its use in conjunction with our software.

Virtual File System (VFS) Encryption

You may have notices that, depending on the Syncplify Server! edition you're running, you may be able to enable Encryption when you create a new Virtual File System (VFS).

This means that whatever you upload to that VFS will automatically be stored in an encrypted form on the server's storage, and it will be automatically decrypted when downloaded again by a client.

Note: this has nothing to do with encryption over the network, which is always on, and is guaranteed by the file transfer protocols you're using - this article refers to what's known in the industry as "at-rest encryption".

An encrypted VFS transparently encrypts and decrypts data on-the-fly during the interaction with the server machine/VM's storage medium, making sure that the files at-rest on the server-side are always encrypted. This way you can run your server externally, and still always be sure that whoever operates the server for you doesn’t have access to your files/backups. This is also a requirement in some cases when your company has to comply with the PCI/DSS or HIPAA regulations.

As long as an encrypted VFS is accessed via a secure file transfer client using a legitimate user account, a VFS will show us just like any other folder, and files in it can be downloaded in clear by the legitimate user.


But let's say you have a text file on your client computer for example, and you want to upload it to a remote Syncplify Server! into an encrypted VFS...

The file on your client will look something like this:


Yet, once uploaded to the remote Syncplify Server!, should someone had raw direct access to the server's storage, all they would see is this:


Feel free to run your SFTP server in the cloud, or host it in any other insecure place, or delegate its management to an untrusted third party... whoever might have physical access to it, still won’t be able to acquire your files, as they’re all encrypted “at-rest” on the server’s disk drive (or any other storage medium).

Overriding permissions on folders/directories

Syncplify Server! gives you the ability to override permissions on sub-folders that are physically contained inside a user’s Home VFS.

Let’s say, for example, that the actual directory structure on the disk is the one you see in the picture here below, and that the user's Home VFS is of type "Disk" and points to C:\SFTPRoot:


When an SFTP client connects, under the root the user will see the incoming and outgoing folders, and by default they will have the same permissions as the root folder that contains them.

But what if you wanted, for example, to restrict the incoming folder to only uploads, and the outgoing folders to only downloads? What if you wanted to change (override) the user's permissions on them on a per-directory basis?

You can use the Permission Override tab inside the User profile to do so: