BiT with Synology DSM 6 (and 7) - passwordless login (via SSH)

[jnuernberg]

I was just setting up BiT with my Synology NAS (running DSM 7) and followed the instructions from the FAQ. Strictly following the instructions there did not result in success: I still had to enter the backup users password when trying to login via ssh. To overcome this, I had to change the backup users home directory rights to 755 / drwxr-xr-x where Synology by default uses 777 / drwxrwxrwx.

So it may be helpful to add one line in the according FAQ section mentioning to run the following comand once on the backup users home directors: chmod 755 /var/services/homes/backup

Albeit this is not strictly a BiT issue, it's nice to have it noted here.

[buhtz]

Thanks a lot for bringing this up. We will add this to the FAQ.

[aryoda]

I am trying to understand why removing rights (777 to 755) from the home folder is required for a password-less PPK login. I have a Synology NAS available and will check this in the next days.

[aryoda]

@jnuernberg

Thanks for reporting this! The ssh server does indeed check the home folder rights to ensure that only the user (but not everyone) has write permissions to avoid injecting a "manipulated" key file.

We will add this to our FAQ!

[jnuernberg]

@aryoda

Thanks for testing, this took me some time to figure this out last night. Well, at least the passwordless login is working fine now.

However, I ran into another issue afterwards: Once BiT starts backing up using rsync, the permissions of the users on the NAS change! I have a user "Backup" (member of admin group) setup such that its sftp home directory is a shared folder on my DS420 (running DSM 7), which I made sure it has access to (Control Center -> Users -> Edit -> Permissions). Once I start a BiT snapshot, permissions are reset to "No Access".

I don't believe, that this is a BiT issue, but rather somehow related to DSM. I will run some more tests tonight and let you know, what I can figure out.

[jnuernberg]

So I figured out, that putting the backup not in the home directory of the user causes the issue with the permissions. All of that is roughly described in issue #553.

But from my point of view, this yields an issue: The backup user has to belong to the admin group and is thus not bound to any storage space quotas. On the other hand, you wouldn't want your backups to indefinitely grow and occupy all space on your Syno NAS. Currently, I circumvent this with a rather strict retention policy. But would it be possible to add a "Delete when backup size exceeds XXX GB" option in BiT?

btw. from my PoV, this issue is solved and can be closed.

[aryoda]

@jnuernberg FYI: I am reviewing the FAQ section for the Synology with the latest DSM 7.1.1 version currently. I will close this issue after updating the FAQ section...

this yields an issue: The backup user has to belong to the admin group and is thus not bound to any storage space quotas.

For me it was also surprising that the backup user must be member of the admin group (I'd consider this as a security risk). Perhaps this is no longer (or not at all) required. I try to figure this out...

But would it be possible to add a "Delete when backup size exceeds XXX GB" option in BiT?

I will add a new issue with this feature request (or you do it yourself - as you want).

[jnuernberg]

Thanks, @aryoda,

In case you want me to read through the DSM 7.1.1 FAQs and test them, let me know.

I am reaching out to Synology with this issue and ask them what their take on this matter is. Nonetheless, I would like to understand the workings of BiT a bit better in the meantime.

As far as I can see, BiT uses the SSH passwordless login to establish an sftp connection to the share, and then uses rsync to create the backup. I found this article in the Synology Knowledge base, that explains the rsync part fairly well. However in the end, they state You may need to mount the folder on the Synology NAS to your Linux device using CIFS or NFS mount beforehand. This sounds like they do not support the passwordless SFTP login by default.

To my understanding, only the SSH/SFTP part requires administrator privileges on the Synology NAS, causing the hastle with quotas and security risks. The final thing, that I don't understand yet, is why DSM doesn't allow to SFTP/rsync to a shared folder but only to the home folder of the backup user.

Did I miss anything here or am I entirely on the wrong path?

But would it be possible to add a "Delete when backup size exceeds XXX GB" option in BiT?

I will add a new issue with this feature request (or you do it yourself - as you want).

I think this is a "nice to have", no matter what the Synology answer states. I consider adding it later.

Best regards, Jacob

[jnuernberg]

So in short: Synology support cannot provide any help on this.

I received an answer essentially stating that they cannot offer "any advice on working via CLI/SSH since the terminal is only for maintenance purposes" and that they do not recomment working via SSH. Also, they write, that they cannot supply any support to third party software (understandable) and have to stick to their guidelines (absolutely okay).

So big shout out to synology here, for a good, informative, and quick answer, but I think we are on our own on this one!

I, for my part, resorted to mounting the drive for backups and not using SSH on the Synology NAS/BiT anymore.

[aryoda]

Related to #1674 (incorporate the FAQ updates requested here into that issue's PR)...

DSM 7.x can be configured to work with BiT but only for the home folder of the "backup" user (the Synology user you must create and assign ssh permissions).

Synology's questionable decisions to allow ssh logins only for users of the admin group is required (with all risks).

A good (but untested) solution could be to install openssh via a docker container on the Synology so that you can configure everything as you want...

[buhtz]

Might PR #1843 be relevant here or fixing it?

[buhtz]

Can someone please have a look into the FAQ. There are still some Synology related entries. Do they cover the topic described in this issue? Or can we add new info to that FAQ.

I am not a Synology user. Maybe @jnuernberg would like to provide some sentences? You can add them here in the issue as a comment if you don't want to edit the FAQ file and open a PR.

Thanks in advance, Christian

[jnuernberg]

Hi @buhtz,

Well, I have to admit, I think I cannot provide more insight, than what's already in the FAQ. After Synologies rather unsatisfactory replies, I rethought my backup and data safety solutions and decided not to use BiT with my Syno NAS anymore. The main reason is the poor and maintenance heavy out-of-the-box support from Synology for this.

So, my current setup is the following:

1. I use BiT with a second internal harddrive to generate hourly, daily, weekly...and so on snapshots for data integrity right there in the system with a suitable data retention policy in place.
2. I use BiT with a "cold store" hard drive on a monthly basis. I.e. I use an external harddrive, that I use once a month to create a "cold backup" of my data. Here again, data retention policy through BiT.
3. I resorted to using syncthing to have an up to date copy of my data, without any snapshots, on my NAS for general accessibility.

Now personally for me, both the NAS and the cold storage are off-site, giving me, what I believe is a pretty solid data safety.

In general, for future users, I think I would not recommend using BiT with a Synology NAS due to the poor out of the box support. This would be the only sentence or recommendation, that I would add to the FAQ. Do you want to take care of this or shall I add this later on my own? Please don't get me wrong: I definitely recommend using BiT and keep doing so myself. I also find my Syno NAS very suitable for my purpose. But they don't fit together.

I hope this helps a litte.

Best regards, Jacob

[buhtz]

Thank you for the reply. I appreciate that.

[buhtz]

Closing this ticket based on the comment above. Feel free to reopen if the problem still exists. Thank you for your efforts. If you have any further questions, ideas or encounter any other issues, please don't hesitate to let us know.

Best regards,