rsync job password issue - shell works fine

[chris1284]

Hi,

i have created a rsync job to PULL files from my old storage 192.168.2.12 .
On 192.168.2.12 there is a modul, with options

secrets file = /etc/rsyncd.secrets
auth users = admin:ro christian:ro

the secrets file is filled with the users

admin:pw
christian:pw

if i try to connect in shell on truenas server (up to date) , i can connect to the rsync module on 192.168.2.12.
The job runs into the error

Truenas

Password: u/ERROR: auth failed on module daten rsync error: error starting client-server protocol (code 5) at main.c(1863) [Receiver=3.2.7]

Server

2023/10/27 20:56:38 [151186] rsync allowed access on module daten from UNKNOWN (192.168.2.71)
2023/10/27 20:56:38 [151186] auth failed on module daten from UNKNOWN (192.168.2.71) for admin: password mismatch

Truenas rsync job created via gui must do something wrong i think. or i have other problems/mistakes in the jobconfig (see attached files).

thx for your help

 

[winnielinnie]

I don't understand the first screenshot?


1. Are you using "strict modes" on the rsyncd server? (It's enabled by default.)
If so, what are the permissions/ownership on your secrets file?

2. Are you using any special characters for the password?

 

[chris1284]

the first screenshot is the test of rsync connection from the truenas to the source. it works fine in shell.
.cmd1

rsync admin@192.168.2.12::daten

password prompt -> input secret -> success, module file can be listed
cmd2

rsync 192.168.2.12::daten

is the same, only without user, so it chooses the user of shell.
test with user christian also ok

1. yes, strict modes on and the rights are ok
permissions on secret file is ok, authentication in shell of truenas works

root@srv00:~# ls -l /etc/rsyncd.*
-rw-r--r-- 1 root root 671 27. Okt 20:57 /etc/rsyncd.conf
-rw------- 1 root root 128 27. Okt 20:56 /etc/rsyncd.secrets

2. no, for admin only lowercase and digits
yes for user christian, both is working in shell via rsync cmd

i think there is a difference between the execution in shell and as a job started from truenas.

 

[winnielinnie]

i think there is a difference between the execution in shell and as a job started from truenas.

Did you successfully run an rsync transfer using the command-line? (Or only just test the connection?)

Is the other server also TrueNAS SCALE?

 

[chris1284]

Did you successfully run an rsync transfer using the command-line? (Or only just test the connection?)

Is the other server also TrueNAS SCALE?

command-line sync runs perfect, permission on the source rsync module are ok. Local permissions on truenas to write the data also ok.
the source / server@192.168.2.12 is a debian 12.2 with "rsync version 3.2.7 protocol version 31". other debian servers also pull and push data via rsync to the server@192.168.2.12 so it must be something with the job execution

 

[chris1284]

where can i find the rsynctask.run file that is triggered by cron?

truenas CRON[56732]: (root) CMD (PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/root/bin" midclt call rsynctask.run 1 > /dev/null 2> /dev/null)

 

[winnielinnie]

where can i find the rsynctask.run file that is triggered by cron?

I don't think it's a naked file. I think it's parsed from the database file.

It probably constructs the rysnc command on-the-fly from you're configured task.

 

[winnielinnie]

Wait, did you specify a secrets file (that has the matching password) on the auxiliary parameters in the Rsync Task?

(Your screenshot is cropped.)

 

[chris1284]

Wait,..... what a stupid failure. for whatever reason, i thought the task uses some integrated auth methods.
With option password-file it works. thank you for help!

 

[chris1284]

one additional question: in the auxiliary parameters, can i use a environment variable for date time in filename of log file for example?

 

[winnielinnie]

can i use a environment variable for date time in filename of log file for example?

Not sure. You may or may not have to "escape" it properly. You can try adding the date variable, as you would in a standard sh/csh session.

 

[winnielinnie]

Don't forget to use the --inplace and --no-whole-file parameters, since you are writing to ZFS storage.