Syncplify Server! v6.0.27 released 🚨

Importance of this update: VERY IMPORTANT
  • HAProxy headers now report the correct client IP address in the SSH2/SCP/SFTP protocol handler
  • Importers (V4/V5) now auto-sanitize all IP/Network lists by removing incorrect items
  • Decreased heap memory allocation by ~0.8%
  • Sped up file transfers by ~1.4%
  • Upgraded SyngoDB to v4.5.5
  • Radically changed validation for all APIs and database objects/structures: now anything that can be sanitized (auto-corrected) will be sanitized, and validation errors will be reported only for those rare cases in which automatic sanitization is not possible: this should reduce the number of errors returned by the Admin UI upon saving configuration changes by up to 95%
  • Most of the remaining errors are now reported with clear messages in plain English
  • Removed nearly all null values from JSON objects returned by the APIs

Upgrading from v6.0.x is a simple and fairly automatic process: simply download the latest version from the official download page, and install it over the existing version, all of your settings and license will be kept.

If, instead, you’re upgrading from an older (v4/v5) version, you find the upgrade instructions in our knowledge base.

Thank you all for trusting our software with your secure file transfers!

A much improved Admin UX is coming…

First of all, let’s clarify: UX is not UI.

While UI refers to the User Interface (what a human-machine interface looks like), UX refers to the User eXperience (how a human-machine interface behaves).

With Syncplify Server! V6 we think we’ve done a pretty good job at UI… but there are things in our UX that could be improved. For that reason, one of the v6.x upcoming releases will be focused on UX, and on ways to improve and make it easier for an administrator to manage our software.

In order to do that, we had to start with identifying what could be done better, and we have indeed identified a few areas, namely:


The current strategy is: validate everything, and report all mistakes in a technical way that overlaps with the fields our REST API manages. This is probably still the best for those very few people who know the inner workings of our REST API inside out. But let’s be honest, how many of them are there? We cannot expect our customers to have this type of knowledge, they didn’t design our software, and they don’t only have our software to manage in their daily routine.

So, we need to go from: validate –> report everything (in tech notation)

To: sanitize –> validate –> report if needed (in plain English)

Most things can actually be sanitized. For example, let’s say you created a Virtual Folder for a User, but forgot that all virtual folders must be POSIX-root-based (i.e. begin with a forward-slash). We can simply add that leading forward-slash for you, and not even bother reporting a validation error.

Validation errors will still be reported (but in plain English) only when there is no unambiguous way to automatically sanitize the contents of a field that were filled-in wrong by the administrator.

As a result, our Admin interface will produce a lot fewer error messages (as many mistakes will be automatically sanitized) and the few errors that will be displayed to the administrator will be in plain English, thus far easier to understand and know what to change to fix them.

Reduce the “nulls” to check via REST API

Most modern OpenAPI-compliant JavaScript frameworks are not designed to automatically generate the logic to check for null conditions in every return value. The result is that this logic often has to be written-in by hand by the developer, which leads to bugs and errors.

We’re working hard to ensure that our REST API always returns a predictable set of non-null fields for every call. This will make the UI-side logic abundantly easier and cleaner to design and develop.