Allow rsync task with / as remote host
As posted on the forum: https://forums.freenas.org/index.php?threads/cant-create-an-rsync-task-with-as-remote-host.54379
I'm trying to setup an rsync task. The task should pull from a remote Linux server. The Linux server use the rrsync script to restrict rsync access. It usualy work very well!
Because I use rrsync, I use "/" as remote path. rrsync translate that into my real directory on my Linux server.
First thing, when I create the rsync task with that remote path, it complains the remote path cannot be found. I unchecked the checkbox to disable the validation in order to be able to create the rule.
Then, I try to run the task from the web GUI. It fails silently.
So, I open the /etc/crontab file on my FreeNAS box to see what it is doing and try to replicate manually on the command line.
[rsync@freenas] ~ % /usr/bin/lockf -s -t 0 -k "/mnt/pool0/BACKUP_COPY/Postgresql" /usr/local/bin/rsync -r -t -z -e "ssh -p 22 -o BatchMode=yes -o StrictHostKeyChecking=yes" email@example.com:\""/"\" "/mnt/pool0/BACKUP_COPY/Postgresql" rsync: change_dir "/to/my/real/remote/path//"" failed: No such file or directory (2) rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1664) [Receiver=3.1.2] rsync: [Receiver] write error: Broken pipe (32)
Seem like there is a double escaping on the remote path and this is being translated as a double slash on the remote host.
If I replace
But I cannot just change the crontab manually, because the change would be eventually lost. How can I fix my problem using the web GUI?
fix(gui): Don't do double-escaping for safe rsync remote paths
#7 Updated by 0 4242 over 1 year ago
After creating a new task, I found the problem is not only when creating a task with / as remote. It also fails when I try to pull from a subdirectory (example: /server1) because of double quoting. When rsync receive directly the request I assume this work fine, but it fails with the use of rrsync between.
I don't know if the current issue is a feature or a bug. The remote path is double quoted but you don't double quote the local path. If the local path doesn't need to be double quoted, I wonder why the remote path should be.
Meanwhile I updated my workaround in order it work in all situation.
#9 Updated by Vladimir Vinogradenko about 1 year ago
- Status changed from Fix In Progress to 15
I think this double-escaping is an attempt to mimic
-s, --protect-args option behavior:
-s, --protect-args This option sends all filenames and most options to the remote rsync without allowing the remote shell to interpret them. This means that spaces are not split in names, and any non-wildcard special characters are not translated (such as ~, $, ;, &, etc.). Wildcards are expanded on the remote host by rsync (instead of the shell doing it).
The problem with just adding this option and removing double-escaping is that this must be supported by remote side:
Since this option was first introduced in 3.0.0, you’ll need to make sure it’s disabled if you ever need to interact with a remote rsync that is older than that.
Rsync 3.0.0 was released at 2008-Mar-01.
I see two options here:
1) Don't do double-escaping for safe paths (python test:
pipes.quote(s) == s)
-s and don't do double quoting, add option «Remote side is rsync<3.0» with fallback to double quoting
- File rysnc task does not let you browse for path.png rysnc task does not let you browse for path.png added
- Priority changed from Nice to have to Blocks Until Resolved
See the attached screenshot. I believe that as a side effect of this fix we can now longer browse for local path for an rsync task. 10.231.3.1 root abcd1234 can be used to see the issue.