Rsync password file

I am using latest SCALE stable build.
I am trying to set up an rsync task FROM the truenas TO a qnap.

I have everything working if I run the rsync command as sudo from the shell, but trying to use a password file I either get 1 of 2 errors.
either “permission denied” or “password file must not be other-accessible”

this works when run manually in the sell:

sudo rsync -az --dry-run --password-file=/mnt/nvme/rsync/rsync.pwd username@10.128.1.106::archive

admin@truenas[/mnt/nvme/rsync]$ ls -l                                                                                       
total 1
-rw------- 1 root root 13 May 23 01:29 rsync.pwd


if I chown the rsync password file as the ‘admin’ user instead of root it still doesn’t work. What account is the truenas gui running rsync as?

any guidance?

Maybe an rsync user account? You can check the list of all users (even “system” ones) with cat /etc/passwd

I think rsync tasks run as the admin user (or root if admin is not set).
I’m guessing what’s happening here is that you are chowning it properly, but your file permissions are wrong. Rsync probably expects the file it’s reading to be chmod to 600 otherwise it might kick off about security - just based off of the “password file must not be other-accessible” warning/error.

On second thought, don’t you define the “Run As” user in the Task’s configuration? That’s how it is with TrueNAS Core.

Ignore me. Yes, you can:

that’s my problem. I am specifying ‘user1’ in the gui, but the file is chown with either root or admin. neither of those are ‘user1’ which is why I’m getting the permission denied.

I changed the chown to user1:user1 and now the rsync job is running as expected.

I find it fascinating that the Rsync Service (Modules) was removed from TrueNAS SCALE, due to being “insecure”. Yet at the same time they allow you to create Rsync Tasks using the “insecure” protocol of sending unencrypted data to another server.

Hopefully iX will remove this option from Rsync Tasks, forcing SCALE users to only use an SSH transport. (Surely we don’t want users exposing their NAS files/folders over an insecure, unencrypted connection?)

Less sarcastically: It’s still not clear why “Rsync Service” was removed, when things like NFS get to stay, as do insecure/unencrypted transfers via Rsync Tasks over the rsync:// protocol.