The volumes are designed to be easy to set up, having only a few requirements (a ssh server with the rsync command installed). However some systems may need some special care in order to be up and ready. This page is gathering some system specific options and fixes that we could use previously.
The Disk Station Manager from Synology is a GNU/Linux based operating system but needs some tuning to enabled a good synchronization experience. First, you should upgrade it to the latest DSM version.
The compression can slow down file transfers on slow CPUs.
DSM 6 natively runs an older rsync version 3.0.9 (released in 2011). The main issue is that it doesn't support the rsync protocol version 31 (released in 2013).
A way to get a newer version of rsync running is to install the Docker package in DSM and run a more recent rsync from a container:
https://www.synology.com/en-us/dsm/feature/docker
and then run a container like this one to run an up-to-date rsync from it: https://hub.docker.com/_/centos.
Then, in your SyncPlanet volume configuration, specify a command to use rsync in the container instead of using the rsync of the host:
centos1
is the name of the docker container running on your NAS. You could also configure the volume's JSON using the API:
{
"_id": "sit/mystudio/myproject/myvolume",
"rsync_args": "--rsync-path='/usr/local/bin/docker exec -i centos1 rsync'"
}
This is useful to avoid sending passwords and increase security.
You will need to change some permissions in order to use key authentication instead of passwords. The procedure is explained here: https://forum.synology.com/enu/viewtopic.php?t=126166
Setting up a ssh-rsa key under the root account is more straightforward:
If you need to debug, remember that you can use the ssh command with -vv option to increase the verbosity of the connection and of the authentication procedure.
Windows can serve a SyncPlanet volume. For this we recommend using a Window Server Edition (avoid Windows «Home» Edition which has a bad network stack).
OpenSSH has been added to Windows server 2019. For older Windows server distributions, a viable solution is to install a GNU/Linux VM on this machine. and run OpenSSH from it.
The public key of the key pair must manually be placed onto the server you will SSH to. This is easiest to do via copy/paste into a Remote Desktop session. The public key should be named authorized_keys and copied into the .ssh folder inside the profile folder of the user you are setting up. For example, c:\users\myuser.ssh\authorized_keys. Note, if the user is in the local Administrators group on the server, the key must be placed in a different path. See the next section for more details.
Note, Windows Explorer won't let you create the folder with the name ".ssh". Instead, use ".ssh." with an extra dot at the end. The extra dot will be removed, and you'll have a folder correctly named .ssh
Note, this file has no extension. You may need to make file extensions visible to ensure you remove the .txt extension
If the user account on the server you are connecting to is in the local Administrators group, the public key must be placed in the C:\ProgramData\ssh\administrators_authorized_keys instead of the user's .ssh folder. Additionally, only the Administrators group and SYSTEM account can have access to that file, for security purposes. After copying your key into the file and saving it, you can use this script to set the correct permissions on it. Here are the complete steps:
$acl = Get-Acl C:\ProgramData\ssh\administrators_authorized_keys
$acl.SetAccessRuleProtection($true, $false)
$administratorsRule = New-Object system.security.accesscontrol.filesystemaccessrule("Administrators","FullControl","Allow")
$systemRule = New-Object system.security.accesscontrol.filesystemaccessrule("SYSTEM","FullControl","Allow")
$acl.SetAccessRule($administratorsRule)
$acl.SetAccessRule($systemRule)
$acl | Set-Acl
If you don't do this, and instead only place the file in the .ssh folder for the user, you'll either get prompted for your password (instead of using the key file), or your connection will fail with "Too many authentication attempts".
source: https://www.concurrency.com/blog/may-2019/key-based-authentication-for-openssh-on-windows
A rsync.exe is part of the https://en.wikipedia.org/wiki/Cygwin project. You can get it here: https://www.cygwin.com/.
--rsync-path='C:\cygwin64\bin\rsync.exe'
rsync.exe is capable of accessing local drive letters using the cygdrive path, therefore to access your volume's folder located in D:\VOLUME
you can use /cygdrive/d/VOLUME in the volume's URL:
ssh://lpnuser@x3.14y.11z.30:/cygdrive/f/LPN_SYNC/
The Microsoft file systems are case insensitive, while the other file systems are all case sensitive. When synchronizing heterogeneous systems, this means that /project/path/file
will be equivalent to /Project/Path/File
on Windows systems ONLY. Take that into account in your naming convention to avoid collisions if the production is synchronized between systems that include a Windows volume.
You may need to fine-tune the permissions of the files received on the volume.
Under some conditions the volumes may not be able to correctly respond to ssh and rsync calls.
The is an example where the local server was not having enough ressources, at 100% cpu and could not handle properly the incoming files using the samba (CIFS) protocol.