You are not logged in.
Hello:
I have discovered that the only way to get a half decent link between my Devuan box (GbE port) and my NAS (GbE port) is to use the rsync protocol.
ie: no compression/no encryption with a daemon ie: rsyncd running on one end.
Anyone curious about the details see Can a pocket router go fast?
The problem is that the now ubiquous ssh is only seen a half of what it is: very secure cryptographic network protocol.
What it really is (YMMV) is a very flexible, efficient and easy to use network protocol which also has the ability to be very secure.
Hence the difficulty of being able to use it without encryption.
But I digress.
After a lot of tinkering I have managed to set up an rsync daemon on the NAS as well as the modules required by what I want to do.
eg:
The user is member of the right groups:
:~$ groups
daemon adm mail ftp users network ntp groucho
:~$
The modules relate to the directories receiving the data are all owned by the user:
:/mnt/sda3$ ls -l
drwxrwxrwx 4 groucho groucho 4096 Apr 25 19:03 bkups
drwxrwxrwx 2 groucho groucho 4096 Apr 29 18:47 stuff
drwxrwxrwx 2 groucho groucho 4096 Apr 28 17:53 testdir
:/mnt/sda3$
The directories from where the data is sent (Devuan box) are all owned by the user:
groucho@devuan:/media$ ls -l /media
total 24
drwxr-x--- 2 groucho groucho 4096 Feb 9 19:46 300Gb
drwxr-x--- 5 groucho groucho 4096 Jan 30 18:07 bkups
drwxr-x---+ 2 root root 4096 Apr 21 19:57 groucho
drwxr-xr-x 9 groucho groucho 4096 Apr 28 07:25 storage
drwxr-xr-x 25 groucho groucho 4096 Apr 28 07:32 stuff
groucho@devuan:/media$
The daemon is running:
:~# service rsyncd status
running
:~#
The command line is, as far as I can see, correct:
groucho@devuan:~$ rsync -av /media/stuff/firefox.oldfile rsync://groucho@192.168.1.3:/stuff
But, much to my chagrin, the result is not the expected one:
groucho@devuan:~$ rsync -av /media/stuff/firefox.oldfile rsync://groucho@192.168.1.3:/stuff
sending incremental file list
firefox.oldfile
rsync: [receiver] mkstemp "/.firefox.oldfile.pPHKBp" (in stuff) failed: Permission denied (13)
sent 85,833,476 bytes received 134 bytes 24,523,888.57 bytes/sec
total size is 85,812,416 speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]
groucho@devuan:~$
But not all is bad news: 24,523,888.57 bytes/sec is 3.5x what I was getting using the NAS's native dropbear application.
The /var/log/rsyncd.log file on the NAS reads:
groucho@OpenWrt:~$ cat /var/log/rsyncd.log
2022/04/29 21:35:42 [2557] connect from UNDETERMINED (192.168.1.2)
2022/04/29 21:35:42 [2557] rsync allowed access on module stuff from UNDETERMINED (192.168.1.2)
2022/04/30 00:35:42 [2557] rsync to stuff/ from UNDETERMINED (192.168.1.2)
2022/04/30 00:35:42 [2557] receiving file list
2022/04/30 00:35:42 [2557] rsync: [receiver] mkstemp "/.firefox.oldfile.lNbFmM" (in stuff) failed: Permission denied (13)
groucho@OpenWrt:~$
The connection is established, rsync is allowed access to the target folder but when rsync attempts to (having received the file) write a temporary copy at destination, for some reason it it fails and the link is cut
Funny that it does not do a premission check before actually sending the file.
In any case, this seems to be a premission issue, probably the most common one rsync can have.
But I have not been able to find a solution.
Could someone shed some light on this for me?
Thanks in advance.
Best,
A.
Last edited by Altoid (2022-04-30 14:59:40)
Offline
First try ls -ld /stuff on groucho (I suspect you are trying to access a dir in the root directory). If it looks as if the ID should be able to write there then try touch /stuff/test1 as that ID to make sure.
If you want to put things into somewhere under the ID's home directory then try rsync -av /media/stuff/firefox.oldfile rsync://groucho@192.168.1.3:stuff (assuming stuff is in your home dir on groucho).
Chris
Offline
Hello:
First try ls -ld /stuff on groucho (I suspect you are trying to access a dir in the root directory). If it looks as if the ID should be able to write there then try touch /stuff/test1 as that ID to make sure.
I may be confusing you as my user groucho gets used everywhere.
My Devuan box:
groucho@devuan:~$ ls -ld /media/
drwxr-xr-x 8 root root 4096 Mar 16 16:38 /media/
groucho@devuan:~$
groucho@devuan:~$ ls -ld /media/stuff
drwxr-xr-x 25 groucho groucho 4096 Apr 28 07:32 /media/stuff
groucho@devuan:~$
groucho@devuan:~$ touch /media/stuff/test1
groucho@devuan:~$ ls -ld /media/stuff/test1
-rw-r--r-- 1 groucho groucho 0 Apr 30 13:42 /media/stuff/test1
groucho@devuan:~$
The NAS:
groucho@OpenWrt:~$ ls -ld /mnt/sda3
drwxr-xr-x 5 root root 4096 Apr 28 17:53 /mnt/sda3
groucho@OpenWrt:~$
groucho@OpenWrt:~$ ls -ld /mnt/sda3/stuff
drwxrwxrwx 2 groucho groucho 4096 Apr 29 18:47 /mnt/sda3/stuff
groucho@OpenWrt:~$
groucho@OpenWrt:~$ touch /mnt/sda3/stuff/test1
groucho@OpenWrt:~$ ls -ld /mnt/sda3/stuff/test1
-rw-r--r-- 1 groucho groucho 0 Apr 30 13:44 /mnt/sda3/stuff/test1
groucho@OpenWrt:~$
... then try rsync -av /media/stuff/firefox.oldfile rsync://groucho@192.168.1.3:stuff (assuming stuff is in your home dir on groucho).
No.
The /home/groucho dir on the NAS is very limited, just for admin use.
Actually, OpenWRT (mostly used in routers) by default only has root access, no users.
The /mnt/sda3/ partition (~1TB) is where everything gets sent.
root@OpenWrt:~# blkid
/dev/sda1: UUID="xxx" BLOCK_SIZE="1024" TYPE="ext2" PARTUUID="xxx"
/dev/sda2: LABEL="rootfs" UUID="yyy" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="yyy"
/dev/sda3: LABEL="data" UUID="zzz" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="zzz"
root@OpenWrt:~#
root@OpenWrt:~# mount
--- snip ---
/dev/sda3 on /mnt/sda3 type ext4 (rw,relatime)
--- snip ---
root@OpenWrt:~#
Thanks for your input.
Best,
A.
Last edited by Altoid (2022-04-30 17:00:54)
Offline
Afaiui a destination phrase rsync://groucho@192.168.1.3:/stuff tells the rsync server to become user groucho and then interpret what the "stuff" module is. As man rsync tells me at (my) lilne 202: the first word of the "path" is actually a module name.
To that end rsync will want a declaration in the applicable rsyncd.conf at the server end which in particular would provide the desired path prefix /stuff for the stuff module, but presumably that doesn't exist. But from the log file, it looks like it results in the /stuff bit (the module bit) is consumed and then a destination path prefix / is used.
In short, you might have some luck using rsync://groucho@192.168.1.3:/stuff/stuff as destination path, on the idea that the first /stuff bit nominates the module and the second /stuff bit nominates the path suffix relative to the default module path prefix, /. Of course, if the server is happy with more random module name, you should use something else than /stuff just to reduce the confusion, maybe rsync://groucho@192.168.1.3:/X/stuff
Offline
Hello:
You were on the right track.
Just before dinner I was able to solve the problem via an answer to a post at Stack Exchange.
The problem was in the path for the module/s: it was missing the lowest level.
I had this:
[stuff]
--- snip ---
path = /mnt/sda3
--- snip ---
But it should have been this:
[stuff]
--- snip ---
path = /mnt/sda3/stuff
--- snip ---
ie: /mnt/sda3/stuff instead of /mnt/sda3
After I fixed it and rsync was working properly, I am getting a ~19MiB transfer rate.
It is not much to write about as this NAS would get 2x that with the original firmware, but ~2.5x what I was getting via ssh.
Thank you very much for your input.
Best,
A.
Last edited by Altoid (2022-05-01 02:19:54)
Offline