Using SSH key authentification on a Synology NAS for remote rsync backups

Synology DiskStations are awesome. The DSM web interface is both powerful and easy to use and is constantly improving. One thing I have struggled with, though, has been setting up public key authentification in order to allow automated scripts to push backups to the NAS via rsync. Here is how it can be done.

First, two things to keep in mind :

  • By default, root is not allowed to connect, you need to connect with another user and use sudo su (type the password of the user you are connected with, not the root password).
  • Only members of the administrators group are allowed to connect by SSH. However, even non-administrators can use the rsync service.

Public key authentification is disabled by default, you will need to enable it :

  • make sure the SSH service is enabled in Control panel > Terminal & SNMP > Enable SSH service
  • set up a user account if you don’t already have one (mine will be called foaly) and temporarily add it to the administrators group using Control panel > User > foaly > Edit > User groups)
  • log into the NAS via SSH : ssh foaly@[nas-ip] in a Linux terminal or use Putty on Windows
  • log into a root session : sudo su
  • edit the SSH service config : vim /etc/ssh/sshd_config
  • uncomment the lines PubkeyAuthentication yes and AuthorizedKeysFile .ssh/authorized_keys (make sure not to change anything else, otherwise you could lock yourself out of SSH)
  • restart the SSH service, either using synoservicectl --restart sshd or by disabling and re-enabling the SSH service in Control panel > Terminal &SNMP
  • if you added your user to the administrators group at the beginning of this procedure, you can now remove it form the group (except if this is the same user you want to add keys to, keep reading)

Now that public key authentification is enabled, you need to exchange keys for each host and user that need to be able to automatically authenticate. Let’s assume you want to allow a remote server to authenticate with the user backup :

  • add the backup user to the administrators group
  • connect to the server and generate a key pair if don’t have one already : ssh-keygen -t rsa
  • copy the public key to the NAS : ssh-copy-id backup@[nas-ip] (you will need to enter the password of the backup user)
  • this is important : connect to the NAS by SSH and check the files permissions :
    • chmod 0711 ~
    • chmod 0711 ~/.ssh
    • chmod 0600 ~/.ssh/authorized_keys
  • now, the authentification should work : from the server, try to log in to the NAS (ssh backup@nas-ip) and check that it logs in without requiring a password
  • if you only want to use rsync with this user (not SSH) you can now remove the backup user from the administrators group

Note : if this still does not work, take a look at the answers in the comments below for troubleshooting ideas.

In order to push data via rsync on the NAS, here are the steps to follow :

  • make sure the rsync service is enabled in Control panel > File Services > rsync > Enable rsync service (do not check Enable rsync account)
  • choose (create if necessary) the shared folder you want to push to, for example Backups
  • fire rsync with something like this : rsync -az /var/www backup@[nas-ip]:/volume1/Backups/

Here is an example of a more complex rsync command :
rsync -az -e "ssh -p 23342" --backup --backup-dir="rsync_bak_`date '+%F_%H-%M'`" --exclude 'tmp*' --exclude 'cache*' --exclude 'logs' /var/www backup@[nas-ip]:/volume1/Backups/

This will :

  • connect to the randomly-chosen port 23342 : this is useful if your NAS is an a local network behind a router/firewall/NAT, you can configure the NAT to redirect the external port 23342 to the port 22 on the NAS (this can make your configuration safer against bots looking for open SSH ports to exploit)
  • keep a copy of the previous version of each modified file in a dedicated folder with the current date, every time the backup is performed
  • exclude some useless directories from the backup

40 thoughts on “Using SSH key authentification on a Synology NAS for remote rsync backups

    1. Hi Neil, indeed that’s one of the important parts that’s easy to miss, I lost hours because of that. Glad you made it work!

  1. After doing all the above, does Security Advisor of Synology give you several warnings, such as:
    1) error with the homes folder
    2) FTR should have default UNIX permissions
    3) change the SSH port

    1. Hi Patrick,
      I don’t think these warnings have to do with the key authentication procedure. I don’t have the first two you mention, and to be honest I don’t know what they are about. The third one is self explanatory, I have too but it doesn’t matter in my case because the port is only available from my local network.

      1. I believe the first warning is because the homes checkbox is not checked in control panel
        User->Advanced->User Home==>Enable user home service for that user

  2. This is the error i have when i try to copy over the server key to the NAS:

    ~/.ssh> # ssh-copy-id rsync@10.223.27.85
    rsync@10.223.27.85‘s password:
    Could not chdir to home directory /var/services/homes/rsync: No such file or directory
    mkdir: cannot create directory ‘.ssh’: Permission denied
    sh: .ssh/authorized_keys: No such file or directory

      1. Can you check that this setting is enabled in your Control Panel ?
        Control Panel > User > tab Advanced > section User Home at the bottom > Enable user home service
        Then maybe disable and re-enable the SSH service, and make sure that the user you want to add keys to is in the Administrators group.

  3. Hi,

    I’ve got a slightly different setup where the Synology NAS is performing an ssh to another machine. I got everything working to the point where the ssh user@host asks for the passphrase of the public key. After entering this, the ssh connection is successfully established, however the next time I do an ssh, I’m asked again for the passphrase.

    Debugging with ssh -vvv user@host mentions the following thing and that’s where I’m stuck:
    debug3: no authentication agent, not adding key

    This appears to be the reason my passphrase is not being stored, but the Synology seems to be incapable of that since it doesn’t have an authentication agent at all?? I have a DS213+ with DSM 6.2.2-24922.

    Any clues?

    Thanks!

    1. Hi Raymond,
      I’m not sure the “debug3” message is the cause of the problem. You mention using “ssh” but not “ssh-copy-id”, have you done that? Does your key appears in ~/.ssh/authorized_keys after that ?
      Best,

      1. Hi foaly,

        The reference to ssh is when you test the connection to see if a password is asked or a passphrase. The synology does not have the command ssh-copy-id, so I copied the public key manually.

        I actually found a workaround of using no passphrase when generating the ssh key, which seems ok since it is local traffic within my house.

        Thanks though!

        1. Hi Raymond,

          I misunderstood your first message, I thought SSH server was still asking for a password even after the keys were added. In your case, it is the SSH client which asks for the passphrase in order to open your local private key, which is expected. If the connection is successful after you enter the passphrase it means your key authentication is working correctly.

          Just to make things clear for anyone reading this with a similar problem, here is a bit more explanation :
          – By default, when a client wants to connect to an ssh server with a specific username, the server asks for the password of this user before allowing the connection.
          – This can be avoided by using key authentication instead of password authentication : a key pair (public and private) is generated on the client side, and the public key is sent to the server and added to a list of authorized keys. Anyone with the corresponding private key stored locally can connect to this username on this server without needing a password anymore. This is a bit like storing the password on the client side and sending it automatically when the server asks it, but way more secure.
          – However, if the private key gets stolen on the client (stolen computer or hacked operating system for example), the thief will be able to use it to connect to the server. In order to prevent that, the private key can be encrypted locally with a passphrase (but it is not mandatory). Without knowing the passphrase, the key is worthless.
          – Now, it looks like we got back to square one : a password/passphrase is asked every time we need to connect. In order to mitigate this inconvenience, ssh provides a software called an ssh agent, which role is to keep your private key in memory once it has been decrypted. This way, you only have to enter your passphrase once per session (of the local client). Further connections later in the day will succeed automatically but if you log out or reboot your computer, the agent will ask for the passphrase again.

          In your case Raymond, using a passphrase doesn’t seem convenient because you don’t want to have to enter it for every connection (as I understand, these are automatic scripted connections of some sort, such as for backups) and I don’t see an easy way to use an agent and give the passphrase every time your NAS reboots. Storing the passphrase on the NAS to use it automatically would defeat the purpose of using a passphrase in the first place. In my opinion the best (and probably only) solution is to not use a passphrase. The connection will still be secure, even through the internet, because the key authentication scheme is strong.
          Your only risk is if someone steals your NAS and recovers the private key. In your set of constraints, this risk cannot be avoided because your NAS needs to know all the information needed to perform a connection, and there is always a way this information can get stolen.
          You can however mitigate this risk. Here are a few ideas :
          – make your NAS as secure as possible, check the file permissions of the private key, avoid opening it to the outside
          – create a dedicated user on the server with permissions restricted to only what is needed by your nas, and associate the key to this user, so that even if the key is stolen the damage won’t spread too far
          – your NAS is probably fixed and hopefully on a network with a static IP address, so you can configure the server to restrict the use of this key to your IP address

          Foaly

  4. Hey Foaly, yes that basically describes my situation! Thanks for the tips on the additional security steps, I will definitely look in to that!

    Thanks again,

    Raymond

  5. I followed this guide up to the chmod of the .ssh folder and authorized_keys file. However my server (Unraid) is still asking for a password when I try to ssh to my Synology with the backup account. I verified that everything was done exactly according to this procedure..

    The default Unraid user is ‘root’. But I named Synology account ‘fsync’. Could that be the issue? Do I have to create a user called ‘fsync’ on the Unraid server also and somehow run the ssh command from that account?

    1. No, this shouldn’t be a problem as long as you specify the user you want to connect with : if you use “ssh fsync@<nas-ip>” instead of simply “ssh <nas-ip>”, the local user name won’t matter, as long as it is the user you used with ssh-copy-id (because this command will authorize only your current user, not your whole system).

      Did ssh-copy-id worked correctly? Can you connect with the fsync account if you type the password?

      If so, here are a few ideas to investigate. Connect to the Syno with the fsync account then :
      – in the home folder, type “ls -al” and “ls -al .ssh” and check that the permissions of “.”, “.ssh” and “.ssh/authorized_keys” are correct according to what you specified with chmod
      – open “.ssh/authorized_keys” and make sure it contains your key. Each key is a line in the file, starting with “ssh-rsa”, then the encoded key, then your host id (Unraid). Check that these look ok.
      If everything looks as it should, try using ssh in verbose mode : “ssh -v fsync@nas-ip” and read through the log to see what authentication methods are used. If everything is setup correctly you should see these lines, among the rest :

      Authenticating to <nas-ip> as ‘fsync’
      Will attempt key: […] <– multiple lines like this, each with a local key that will be attempted to login, there should be at least the “id_rsa” that was generated with “ssh-keygen -t rsa”
      Authentications that can continue: publickey,password
      Next authentication method: publickey
      Offering public key: […]
      Server accepts key: […]
      Authentication succeeded (publickey).

      If you see “Next authentication method: password”, that means that none of your local keys was accepted, check again your keys (on both sides); maybe try to delete them and start again. If “publickey” is not even specified in the authentication methods, check your SSH configuration (again, on both sides).

      Hope this will help you troubleshoot the issue!

      1. Thanks for the extensive reply. I redid the entire thing and it still didn’t work. But then I connected with the verbose parameter, and I noticed that the key that I generated wasn’t even attempted!

        Excerpts of the verbose log:

        debug1: Will attempt key: /root/.ssh/id_rsa
        debug1: Will attempt key: /root/.ssh/id_dsa
        debug1: Will attempt key: /root/.ssh/id_ecdsa
        debug1: Will attempt key: /root/.ssh/id_ed25519
        debug1: Will attempt key: /root/.ssh/id_xmss

        debug1: Next authentication method: publickey
        debug1: Trying private key: /root/.ssh/id_rsa
        debug1: Trying private key: /root/.ssh/id_dsa
        debug1: Trying private key: /root/.ssh/id_ecdsa
        debug1: Trying private key: /root/.ssh/id_ed25519
        debug1: Trying private key: /root/.ssh/id_xmss

        I think what I did wrong was that during the ssh-keygen action, I provided a name, like so:

        root@Crookie-NAS:~/.ssh# ssh-keygen -t rsa
        Generating public/private rsa key pair.
        Enter file in which to save the key (/root/.ssh/id_rsa): unraidkey
        Enter passphrase (empty for no passphrase):
        Enter same passphrase again:
        Your identification has been saved in unraidkey.
        Your public key has been saved in unraidkey.pub.

        So what I did was on the Unraid server I renamed this key to id_rsa and id_rsa.pub. Then I copied them over to the Synology again using ssh-copy-id, and now I can in fact ssh to the Synology from the Unraid server without having to enter a password.

        I suspect this is not the neatest solution, but I’ve been at this for two days now so I’m just happy I can continue with the rest of your tutorial. 🙂

        Thanks a lot for the help!

        1. Ho, I see. Indeed, this would have generated keys with a non-standard name (probably not even in the .ssh folder) and neither ssh-copy-id nor ssh would use them. If you want to use another key file (I do not see a reason but you may have a special configuration), you can specify the key to send with ssh-copy-id using the -i flag, and then you would need to tell the ssh client to use this key as well using the IdentityFile directive in your client-side (Unraid) “ssh_config” config file (not “sshd_config”, which is the server config). However, make sure that your private key is secured by setting appropriate chmod settings.

          Glad to see it works!

          1. Appreciate the assistance very much. There is a lot of information to be found about using rsync with Unraid to another Unraid server, or synching from a Synology to an Unraid server (which for me is the wrong way around), or even synching from Unraid to a local Synology.

            But your article is the only one (!) that I can find which properly explains how to set up rsync over SSH to an offsite Synology. So I just want to thank you again, and let you know your write-up and assistance is very much appreciated. Without it I would have never gotten it to work. 🙂

            1. You’re welcome. If I believe the analytics of this site, according to which more than half the traffic is on this single article, you’re not the only one who has trouble with rsync on their Synology nas 😉
              In fact, I’ve written it mainly to remember it myself, because when I wanted to set up my new NAS in replacement of an older one I had forgotten how I managed to do it the first time and I had to spend hours debugging it again… I’m glad to see it helps others as well. This should be documented by Synology themselves.

  6. Hi,
    I’ve got to step “uncomment the lines PubkeyAuthentication yes and AuthorizedKeysFile .ssh/authorized_keys (make sure not to change anything else, otherwise you could lock yourself out of SSH)”
    I uncomment both lines and saved it wit “:w”
    Then I restarted the SHH Service,and now I’m always getting “Network Error: Connection Refused” if I want to connect via Putty.
    Checked the uncommend Lines probably 5 times.Did I just lcoked myself out , or is there a way to recover from this step.

    Best Regards

    1. Hi,
      You can try enabling the telnet service (the checkbox just above the SSH service). Telnet is similar to SSH except that the connection is not secure (not encrypted), which is why it is usually not recommended to use it, but it should give you temporary access to a command line where you can go back to /etc/ssh/ssd_config to check your config. I believe Putty is compatible with Telnet.
      If the content of the file looks correct, try commenting back the two lines, restarting the service, and see if it works : if yes, that means the problem is with these lines, maybe there is a problem with .ssh/authorized_keys; otherwise, there may be a problem elsewhere in the config file, maybe you appended a character by mistake somewhere else and didn’t notice and that causes a parser error.
      You can also check the logs in case there are clues as to why sshd doesn’t accept connections (for example : “sudo tail -n 100 /var/log/auth.log”, maybe try /var/log/dmesg as well).
      There may also be clues in the output of “synoservice –status”.
      I hope this will help you find the issue!

  7. Hi,
    Thanks a lot for this guide. It was really useful!
    But there is something I do not understand… do you know why we need to *restrict* the permisions on ‘~/.ssh/authorized_keys’ for this to work? Default Synology is 777 for everything… I would have expected this way rsync would have less trouble to work.

    1. Hi,
      This is for security purposes : you don’t want a user to be able to add or modify another user’s keys because that could lead to privilege escalation. I don’t remember exactly the details but I believe that the SSH server considers this to be so important that it won’t even consider the authorized_keys file if it is not sufficiently restricted (because the keys inside cannot be trusted), and that’s why the connection doesn’t work.

      1. Yeah… makes sense… thanks for the quick reply.

        It is so sad that Synology does not use UNIX permissions properly.
        I am used to mounting my Synology’s user home using SMB and this more restrictive permissions break that.

  8. Hi,
    really apreciate Your well written How To. I’m trying to get rsync working again after we had to change to a new server. We had everything running and fine, but actually we alsways end up with an ‘Host key verification failed.’ This appeared first when we tried to copy the public key to the Synology:
    ssh-copy-id backup@[nas-ip].
    So we copied the public key manually to the Syno, renamed the file to authorized_keys and moved it to ~/.ssh/. Still the ‘Host key verification failed.’ persists. We did:
    ssh-keygen -R [nas-ip]
    to ‘clean’ the known_hosts file.
    We’ve tried already a lot of things (removing known_hosts, authorized-keys), but we end up always with ‘Host key verification failed.’
    Just trying to ssh to the server in verbose mode shows, that

    – the connection is established,

    – debug1: identity file /root/.ssh/id_rsa type 0 is recognized,
    … after autentication to [nas-ip] as ‘USERNAME’
    … and a few lines the connection ends with
    debug1: read_passphrase: can’t open /dev/tty: No such device or address
    Host key verification failed.
    We can access the Synology trough ssh from terminal on our Macbook with the same credentials without any issues.

    1. Hi Georges,

      Just to be sure I understood your setup correctly : you have a Syno NAS that a distant server uses as a backup target; the NAS hasn’t changed, but the server has, and you want to configure the backup on the new server. Is that correct?

      I believe that the “Host key verification failed” error is generated by the server’s SSH client : it means that it (the client) detected that the host you are trying to connect to is known, so it checks that its fingerprint (its key, that is sent by the SSH server on the host) matches the one stored locally in the known_host file. So if the error first appeared when you tried to use ssh-copy-id, it may mean that there was already a signature in the known_hosts.

      Maybe try everything from the beginning : on your server, do the following :
      1/ backup your .ssh directory ( cp -R ~/.ssh ~/.ssh.bak ) and empty it ( rm ~/.ssh/* )
      2/ generate new RSA keys ( ssh-keygen -t rsa )
      3/ make sure you are able to connect to the NAS via SSH with a password ( ssh backup@[nas-ip] ) -> you should be prompted with the Host key and asked to confirm it because it is new
      4/ if it works, install your public key ( ssh-copy-id backup@[nas-ip] )
      5/ follow the rest of the guide

      If you still have “Host key verification failed” at step 3, it may mean that the server is not able to prompt you the confirmation message (which may be the meaning of “can’t open /dev/tty: No such device or address”), and therefore rejects the key by default. In this case, try disabling the check :
      ssh -o StrictHostKeyChecking=no backup@[nas-ip]
      If now it works, confirm that the server’s key was automatically added to your known_hosts. If so, “ssh-copy-id” should now work as expected, and you should be able to continue the procedure.

  9. Hi,
    thanks for your quick answer.
    You’re right the Syno NAS is used as backup target and hasn’t changed. We had to migrate to a new server from which we want to send backups (PG_dump for the databases and rsync for files).
    We followed step 1-2 and also deleted the ~/.ssh/authorized_keys on the NAS.
    When we try to ssh backup@[nas-ip] we still get the same behaviour (no prompt for a password)?
    Here’s the entire answer when trying to ssh from the new server to the Syno NAS:
    [user@map root]# ssh -v user@xxxxx /bin/bash
    OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017
    debug1: Reading configuration data /etc/ssh/ssh_config
    debug1: /etc/ssh/ssh_config line 18: Applying options for *
    debug1: Connecting to xxxxx [88.xxx.xxx.xxx] port 22.
    debug1: Connection established.
    debug1: permanently_set_uid: 0/0
    debug1: identity file /root/.ssh/id_rsa type 0
    debug1: key_load_public: No such file or directory
    debug1: identity file /root/.ssh/id_rsa-cert type -1
    debug1: key_load_public: No such file or directory
    debug1: identity file /root/.ssh/id_dsa type -1
    debug1: key_load_public: No such file or directory
    debug1: identity file /root/.ssh/id_dsa-cert type -1
    debug1: key_load_public: No such file or directory
    debug1: identity file /root/.ssh/id_ecdsa type -1
    debug1: key_load_public: No such file or directory
    debug1: identity file /root/.ssh/id_ecdsa-cert type -1
    debug1: key_load_public: No such file or directory
    debug1: identity file /root/.ssh/id_ed25519 type -1
    debug1: key_load_public: No such file or directory
    debug1: identity file /root/.ssh/id_ed25519-cert type -1
    debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
    debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
    debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
    debug1: Authenticating to xxxxx:22 as ‘user’
    debug1: SSH2_MSG_KEXINIT sent
    debug1: SSH2_MSG_KEXINIT received
    debug1: kex: algorithm: curve25519-sha256
    debug1: kex: host key algorithm: ecdsa-sha2-nistp256
    debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: compression: none
    debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: compression: none
    debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
    debug1: Server host key: ecdsa-sha2-nistp256 SHA256:xxxxxxxxxxxx…
    debug1: read_passphrase: can’t open /dev/tty: No such device or address
    Host key verification failed.

    No idea what to do next.

    1. Hi,
      Have you tried with the StrictHostKeyChecking=no option (cf end of my answer)? If there is no prompt for a password or a host key confirmation I believe it might be the solution to your problem.

  10. Hi, sorry, but I forgot to give it a try.

    ssh -o StrictHostKeyChecking=no user@abc.myfritz.net
    Pseudo-terminal will not be allocated because stdin is not a terminal.
    Warning: Permanently added ‘abc.myfritz.net,88.xxx.xxx.xxx’ (ECDSA) to the list of known hosts.
    Permission denied, please try again.
    Permission denied, please try again.
    user@abc.myfritz.net: Permission denied (publickey,password).

    So still no chance to connect

    1. Ok, I think we are on the right track : “Warning: Permanently added ‘xxxxx,88.xxx.xxx.xxx’ (ECDSA) to the list of known hosts.”. It appears that, for some reason, your SSH client cannot use your terminal in interactive mode : it was not able to ask you for a confirmation for the host key, so you forced it to accept it anyway with the option (you should see the key in know_hosts, make sure to keep it); and now, it can’t ask you for the password. How are you connected to your server to launch these commands? Is it a “normal” SSH connection or are you using some kind of web-based command line tool?
      I’d say you have two options here :
      – either manage to get an interactive shell on your server which will allow you to enter the password and follow the tutorial
      – or install your auth keys by hand on the NAS (now that the Host key stuff is taken care of on the server side), after which there shouldn’t be a need for an interactive shell anymore and you should be fine.

  11. OK, the really important question was if it’s a “normal” SSH connection. No. it wasn’t. I was using the build in web-based tool inside Webmin. I’ve read a lot of different problems that could occur, but I didn’t realize, that I just could ssh from my Macbook’s terminal to the server and send the ssh commands then to the NAS. I managed now both connections to the server and to the Syno NAS trough the terminal and worder o wonder, everything worked like expected. I finally can access the NAS from my server and user all the magic of Cron Jobs to do the rest. Thank You for the help. Might be worth using such an advise in Your tutorial for guys like me, wo do not realize the difference beetween this web-based tool that look like a terminal window, but has in some cases essential restrictions.

  12. Nice article, thanks so much for taking the time to post this. I was stuck until I ran the chmod commands against the user setup to be the backup user, that sorted it for me 🙂

  13. I have set up SSH connection to my Synology DS1618+ as found in the above tutorial. When connecting (I am using MobaXterm client) to my disk station with SSH key authentication enabled, and I disable PasswordAuthentication in /etc/ssh/sshd_config file, I am not able to access the device at all. It says “Server refused our key”. Then I need to allow Telnet, re-enable PasswordAuthentication, and I can logon again. However the message “Server refused our key” is still there before terminal window opens. I just want to have SSH key authentication enabled only, password enabled access is inacceptable duo to security reasons. What am I doing wrong? Could you point me to where shall I look for to make SSH authentication with keys working as wanted? Many thanks in advance for your nice support.

    1. Hi Joe,
      In order to understand better why the server refuse the key, try enabling some some of verbose output in your SSH software (I’ve never used MobaXterm so I don’t know how precisely you can do it). This should give you detailed information of the negotiation between the client and the server, just as in the discussion with Georges above. If MobaXterm doesn’t offer this feature, maybe try finding a Linux computer or VM and try “ssh -v”, or maybe Putty on Windows has a verbose mode as well. Then try comparing with the extracts from George above and see if something comes up. Copy paste the output here if you need help understanding it.
      Best,

  14. Thanks foaly. I will definitely do what you suggest. However, if I am not wrong, SSH with key authentication had worked correctly in the past. I am not sure, unfortunately. It must have been some months ago, maybe a year or so when I was messing around with it. Then in the far past I disabled the SSH access after I got acquainted with it. At that time I did not need it. Now I would like to have it working for rsync to run smoothly. In the meantime 2 or 3 upgrades of the DMS were installed. My suspicion is this kind of update of the system. Might there be a bug in the newest version of DMS? If so, that’s some kind of user misguidance. My version is 6.2.3-25426 Update2 now. What’s your opinion?

Leave a Reply

Your email address will not be published. Required fields are marked *