Instead of nfs or Samba, if you just need to sync files periodically between two systems, you can use rsync in daemon mode. This is an alternative to file transfer using sshfs or scp, as it doesn't use ssh and has the least overhead (ssh requires encryption which adds cpu overhead).
Of course rsync can itself also use ssh, and whenever transferring files to a remote system I'd absolutely use that (and not the daemon mode). Daemon mode has no encryption and is only suitable when both systems are on a local network which you control and trust.
Enable rsync daemon on the server
The server is usually the source of files (though it can work the other way as well)
Create a file called /etc/rsyncd.conf
uid = root
gid = root
use chroot = no
# max connections = 4
pid file = /var/run/rsyncd.pid
exclude = lost+found/
transfer logging = no
timeout = 900
ignore nonreadable = yes
dont compress = *.gz *.tgz *.zip *.z *.Z *.rpm *.deb *.bz2
# Media files to share
[media]
path = /media
hosts allow = 192.168.192.168
hosts deny = *
list = true
read only = true
strict modes = false
The beginning of the file includes global parameters. Here the uid and gid basically do id mapping and allow the rsync client to run as this user, in this case root. (id mapping can only work if the rsync daemon is being run as root or a user with enough privileges of course).
My configuration of uid =root and gid = root might seem insecure, however I run this rsync daemon in a incus container itself. I also ensure that this incus container has mounted the source files (here /media) read only.
You can achieve similar results by restricting uid and gid and using the chhroot parameter in the rsync daemon, however I think something like an incus/lxc container is a bit more battle tested in this regard and it also really makes the service visible for me on a network level.
The rest of the global parameters are more or less self explanatory. You define multiple modules, such as [media] here which you can think of as nfs or samba shares.
The hosts allow and hosts deny specify which clients can access this daemon. Here I have restricted this daemon to only be accessible from 192.168.192.168. An alternate way to secure it is by using username and passwords, but because that authentication is done in plain text (remember no encryption here) I don't think it's particularly secure, so I prefer to restrict access to specific clients.
If you want to write to a directory which the rsync daemon is exposing, your share section can look like this:
# Media files to share
[media]
path = /media
hosts allow = 192.168.192.168/24
hosts deny = *
list = true
read only = false
strict modes = false
incoming chmod = 2777
file permissions = 2777
directory permissions = 2777
This would set the permissions for all incoming files.
After the rsyncd.conf file is created, make sure the rsync daemon is started by your task runner. On a system which uses systemd:
systemctl enable rsync
systemctl start rsync
Accessing the daemon from the client
From the client, you can then run something like
rsync -aqAXUH --delete rsync://192.168.100.100/media/ /local/path
Or your favourite rsync options. Here 192.168.100.100 is the ip address of the server. This would sync the contents of /media on the server with /local/path on the client
If you don't care about permissions (maybe applying chmod on the server) then you can do something like this:
rsync -rltvhX --info=progress2 --stats /local/dir / rsync://192.168.100.100/media/
Which would still maintain the directory structure, symlinks, timestamps and extended attributes but ignores devices, permissions, ownership, hard links, and ACLs (useful for a single user media setup for example).
If you want to run this periodically, use cron or create a systemd service unit. If using cron, (and cron is enabled), you can add this to cron:
@hourly /usr/bin/rsync -aqAXUH --delete rsync://192.168.100.100/media/ /local/path
replace @hourly with the desired frequency. You can use crontab -e to edit cron jobs. use crontab -l to view the current list of cron jobs for the user.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.