rsyncd.conf

Configuration file for rsync daemon

Parameters are of the form name = value.

Whitespace within a value is retained.
Lines ending in a \ are continued on the next line
Values may be:

  1. boolean: yes|no , true|false ( although 0|1 are permitted, they should be avoided for clarity)
  2. string: (no quotes) with case preserved.

GLOBAL PARAMETERS

Parameters before the first [module] header are global and override the default.

motd file=file "message of the day" to display to clients on connect. This usually contains site information and any legal notices. default is no motd file.
pid file=file If the file exists, the rsync daemon aborts to prevent multiple instances from running. Left over versoins may be a reason that rsync daemon appears not to start.
port=pppp Ignored when run by inetd since the port is defined in /etc/services, superseded by --port (default 873 (priviledged)).
IPaddress=ddd.ddd.ddd.ddd ignored if run by inetd,, superseded by --address
socket options=oooooo see setsockopt(), superceeded by --sockopts

Module Specific Parameters

A "module" exports a directory tree as a symbolic name with restrictions, permissions etc.

[moduleName] (no slash)

path=directory directory in the daemon's filesystem available to the client by referencing moduleName.
Required for each module.
comment=string description displayed when clients list available modules using
rsync host::
use chroot=true | false If true, rsyncd will chroot to directory
This protects against possible implementation security holes.
Disadvantages:
  1. requires super-user privileges,
  2. not able to follow symbolic links outside of the new root path or are absolute and of
  3. complicating the preservation of users and groups by name (see below).

Specify a dot-dir as directory to guard against unintended library loading (since those absolute paths will not be inside the transfer hierarchy, and permits setup of libraries for the chroot that are outside of the transfer.
For example, the client specifies "/var/rsync/./module1" chroot will go to /var/rsync and set the inside-chroot path to "/module1". Without the dot-dir, the chroot would have used the whole path, and the inside-chroot path would have been "/".

When false or the inside-chroot path is not "/", rsync will:

  1. munge symlinks by default for security reasons (see munge symlinks to turn this off)
  2. cause client usage of an absolute path to be relative to the module's path
  3. remove ".." in the client's path specification if they would escape the module hierarchy.

The default is true.

When use chroot is enabled, rsync will not attempt to map users and groups by name (by default), but copies IDs as though --numeric-ids had been specified danger! if IDs are not the same names this will cause different owners on destination system.
To enable name-mapping, rsync needs to be able to use the standard library functions for looking up names and IDs (i.e. getpwuid() , getgrgid() , getpwname() , and getgrnam() ). The rsync process in the chroot hierarchy needs access to the resources used by these library functions (traditionally /etc/passwd and /etc/group, but perhaps additional dynamic libraries as well).

Copy the necessary resources into the module's chroot area, protect them through the OS's user/group or ACL settings (to prevent the rsync module's user from being able to change them), and then hide them from the user's view via exclude. ). At that point it will be safe to enable the mapping of users and groups by name using the numeric ids daemon parameter

Custom user/group information in the chroot area is optional that is different from your normal system. For example, abbreviatons for users and groups.

numeric ids=true|false Enabling this parameter disables the mapping of users and groups by name for the current daemon module, preventing the daemon from loading user/group-related files or libraries.
This makes the transfer behave as if the client had passed --numeric-ids .

Default : for chroot modules enabled

Ensure that the module has the resources to translate names, and that it is not possible for a user to replace them.

munge symlinks = true|false modify incoming symlinks to make them unusable but recoverable (see below).
Protect files from user trickery when daemon module is writable.
Default when "use chroot" is false and the inside-chroot path is "/".

If munge symlinks disabled on a daemon that is not read-only, there are security issues a user can perform with uploaded symlinks to access daemon-excluded items if "use chroot" is off, rsync can show or change data that is outside the module's path (as access-permissions allow).

Symlinks are prefixed with /rsyncd-munged/ preventing the links from being used as long as that directory does not exist.
When enabled,rsync aborts if that path is a directory or a symlink to a directory.
When using munge symlinks in a chroot area with an inside-chroot path of "/",
add /rsyncd-munged/ to the excludes for the module so a user can't create it.

No attempt is made to verify that any pre-existing symlinks in the module's hierarchy are as safe (unless, of course, it just copied in the whole hierarchy).
When setting up an rsync daemon on a new area or locally,
add symlinks, manually protect your symlinks from being abused by prefixing "/rsyncd-munged/" to the start of every symlink's value. munge-symlinks is a perl script in the support directory that adds or removes this prefix from symlinks.

When munge symlinks is disabled on a writable module and "use chroot" is off (or the inside-chroot path is not "/"), incoming symlinks will be modified to drop a leading slash and to remove ".." path elements that rsync believes will allow a symlink to escape the module's hierarchy. There are ways to work around this!

charset specifies the name of the character set in which the module's filenames are stored. If the client uses an --iconv option, the daemon will use the value of the "charset" parameter regardless of the character set the client actually passed. This allows the daemon to support charset conversion in a chroot module without extra files in the chroot area, and also ensures that name-translation is done in a consistent manner.
If charset is not set, the --iconv option is refused, just as if "iconv" had been specified via "refuse options".

To force users to always use --iconv for a particular module, add "no-iconv" to the "refuse options" parameter.

max connections specify the maximum number of simultaneous connections
Any clients connecting when the maximum has been reached will receive a message telling them to try later. The default is 0, which means no limit. A negative value disables the module. See also the "lock file" parameter.
log file log messages to the file rather than using syslog.
The file is opened before chroot() is called, allowing it to be placed outside the transfer. If set on a per-module basis instead of globally, the global log will still contain any authorization failures or config-file error messages.

If the daemon fails to open the log file, it will use syslog and output an error about the failure.

syslog facility Common names are auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6 and local7.
The default is daemon.
max verbosity to the log . The default is 1, which allows the client to request one level of verbosity.
lock file to support the "max connections" parameter. The rsync daemon uses record locking on this file to ensure that the max connections limit is not exceeded for the modules sharing the lock file. default /var/run/rsyncd.lock.
read only if true clients are not able to upload files.
If false uploads will be possible if file permissions on the daemon side allow them. The default is for all modules to be read only.
write only true downloads are prohibited .
false then downloads will be possible if file permissions on the daemon side allow them. default disabled.

list this module should be listed when the client asks for a listing of available modules.
Setting this to false creates hidden modules. The default is listable.
uid=uname or ID# to assume when the started as root.
In combination with the "gid" parameter this determines what file permissions are available. default -2, normally the user "nobody".
gid group name or group ID that file transfers to and from that module should take place as when the daemon was run as root. complements "uid" . The default is gid -2, normally the group "nobody".
fake super causes the daemon to behave as if the --fake-user command-line option had been specified. allows full attributes of a file to be stored without having to have the daemon actually running as root.
filter The daemon has its own filter chain that determines what files it will let the client access. This chain is not sent to the client and is independent of any filters the client may have specified. Files excluded by (daemon-excluded files) are treated as non-existent if the client tries to pull them, are skipped with an error message if the client tries to push them (triggering exit code 23), and are never deleted from the module. filters prevent clients from accessing with private administrative files, such as files you may add to support uid/gid name translations.

The daemon filter chain is built from the "filter", "include from", "include", "exclude from", and "exclude" parameters, in that order of priority. Anchored patterns are anchored at the root of the module. To prevent access to an entire subtree, , "/secret", exclude everything in the subtree; using a triple-star pattern like "/secret/***".

The "filter" parameter takes a space-separated list of daemon filter rules, It will split a token at an internal space in a rule (e.g. "- /foo - /bar" is parsed as two rules).
specify one or more merge-file rules using the normal syntax.
Only one "filter" parameter can apply to a given module in the config file, so put all the rules you want in a single parameter. Note that per-directory merge-file rules do not provide as much protection as global rules, but they can be used to make --delete work better during a client download operation if the per-dir merge files are included in the transfer and the client requests that they be used.

exclude takes a space-separated list of daemon exclude patterns. As with the client --exclude option, patterns can be qualified with "- " or "+ " to explicitly indicate exclude/include. Only one "exclude" parameter can apply to a given module. See the "filter" parameter for a description of how excluded files affect the daemon.
include Use an "include" to override the effects of the "exclude" parameter. Only one "include" parameter can apply to a given module. See the "filter" parameter for a description of how excluded files affect the daemon.
exclude from name of a file on the daemon that contains daemon exclude patterns, one per line. Only one "exclude from" parameter can apply to a given module; if you have multiple exclude-from files, you can specify them as a merge file in the "filter" parameter. See the "filter" parameter for a description of how excluded files affect the daemon.
include from Analogue of "exclude from" for a file of daemon include patterns. Only one "include from" parameter can apply to a given module. See the "filter" parameter for a description of how excluded files affect the daemon.
incoming chmod specify a set of comma-separated chmod strings that will affect the permissions of all incoming files (files that are being received by the daemon). These changes happen after all other permission calculations, and this will even override destination-default and/or existing permissions when the client does not specify --perms. See the description of the --chmod rsync option and the chmod(1) manpage for information on the format of this string.
outgoing chmod specify a set of comma-separated chmod strings that will affect the permissions of all outgoing files (files that are being sent out from the daemon). These changes happen first, making the sent permissions appear to be different than those stored in the filesystem itself. For instance, you could disable group write permissions on the server while having it appear to be on to the clients. See the description of the --chmod rsync option and the chmod(1) manpage for information on the format of this string.
auth users a comma and space-separated list of usernames that will be allowed to connect to this module.
The usernames do not need to exist on the local system.
The usernames may contain shell wildcard characters.
If "auth users" is set then the client will be challenged to supply a username and password to connect to the module. A challenge response authentication protocol is used for this exchange. The plain text usernames and passwords are stored in the file specified by the "secrets file" parameter.
default allow connect without a password (this is called "anonymous rsync").

See also the section entitled "USING RSYNC-DAEMON FEATURES VIA A REMOTE SHELL CONNECTION" in rsync(1) for information on how handle an rsyncd.conf-level username that differs from the remote-shell-level username when using a remote shell to connect to an rsync daemon.

secrets file name of a file that contains the username:password pairs used for authenticating this module. This file is only consulted if the "auth users" parameter is specified.
line based and contains username:password pairs separated by a single colon. The passwords can contain any characters but be warned that many operating systems limit the length of passwords that can be typed at the client end, passwords longer than 8 characters may not work.

There is no default for the "secrets file" , choose a name (such as /etc/rsyncd.secrets). The file must normally not be readable by "other"; see "strict modes".

strict modes whether or not the permissions on the secrets file will be checked.
true the secrets file must not be readable by any user ID other than the one that the rsync daemon is running under.
false, the check is not performed. The default is true.
was added to accommodate rsync running on the MS Windows

hosts allow list of patterns that are matched against a connecting clients hostname and IP address. If none of the patterns match then the connection is rejected.

Each pattern can be in forms:

  1. a dotted decimal IPv4 address of the form a.b.c.d, or an IPv6 address of the form a:b:c::d:e:f. In this case the incoming machine's IP address must match exactly.
  2. an address/mask in the form ipaddr/n where ipaddr is the IP address and n is the number of one bits in the netmask. All IP addresses which match the masked IP address will be allowed in.
  3. an address/mask in the form ipaddr/maskaddr where ipaddr is the IP address and maskaddr is the netmask in dotted decimal notation for IPv4, or similar for IPv6, e.g. ffff:ffff:ffff:ffff:: instead of /64. All IP addresses which match the masked IP address will be allowed in.
  4. a hostname. The hostname as determined by a reverse lookup will be matched (case insensitive) against the pattern. Only an exact match is allowed in.
  5. a hostname pattern using wildcards. These are matched using the same rules as normal unix filename matching. If the pattern matches then the client is allowed in.

Note IPv6 link-local addresses can have a scope in the address specification:

fe80::1%link1
fe80::%link1/64
fe80::%link1/ffff:ffff:ffff:ffff::

You can also combine "hosts allow" with a separate "hosts deny" parameter. If both parameters are specified then the "hosts allow" parameter is checked first and a match results in the client being able to connect. The "hosts deny" parameter is then checked and a match means that the host is rejected. If the host does not match either the "hosts allow" or the "hosts deny" patterns then it is allowed to connect.

The default is no "hosts allow" parameter, which means all hosts can connect.

hosts deny list of patterns that are matched against a connecting clients hostname and IP address. If the pattern matches then the connection is rejected. See the "hosts allow" parameter for more information.

The default is no "hosts deny" parameter, which means all hosts can connect.

ignore errors ignores I/O errors when deciding whether to run the delete phase of the transfer.
Normally rsync skips the --delete step if any I/O errors have occurred in order to prevent disastrous deletion due to a temporary resource shortage (no remaining spave) or other I/O error.
ignore nonreadable ignore files that are not readable by the user. useful for public archives that may have some non-readable files among the directories, and the sysadmin doesn't want those files to be seen at all.
transfer logging enables per-file logging of downloads and uploads in a format somewhat similar to that used by ftp daemons. The daemon always logs the transfer at the end, so if a transfer is aborted, no mention will be made in the log file.

To customize the log lines, see the "log format" parameter.

log format format used for logging file transfers when transfer logging is enabled. a text string containing embedded single-character escape sequences prefixed with a percent (%) character. An optional numeric field width may also be specified between the percent and the escape letter (e.g. "%-50n %8l %07p").

The default log format is "%o %h [%a] %m (%u) %f %l", and a "%t [%p] " is always prefixed when using the "log file" parameter. (A perl script that will summarize this default log format is included in the rsync source code distribution in the "support" subdirectory: rsyncstats.)

The single-character escapes that are understood are as follows:

  • %a the remote IP address
  • %b the number of bytes actually transferred
  • %B the permission bits of the file (e.g. rwxrwxrwt)
  • %c the total size of the block checksums received for the basis file (only when sending)
  • %f the filename (long form on sender; no trailing "/")
  • %G the gid of the file (decimal) or "DEFAULT"
  • %h the remote host name
  • %i an itemized list of what is being updated
  • %l the length of the file in bytes
  • %L the string " -> SYMLINK", " => HARDLINK", or "" (where SYMLINK or HARDLINK is a filename)
  • %m the module name
  • %M the last-modified time of the file
  • %n the filename (short form; trailing "/" on dir)
  • %o the operation, which is "send", "recv", or "del." (the latter includes the trailing period)
  • %p the process ID of this rsync session
  • %P the module path
  • %t the current date time
  • %u the authenticated username or an empty string
  • %U the uid of the file (decimal)

For a list of what the characters mean that are output by "%i", see the --itemize-changes option in the rsync manpage.

Note that some of the logged output changes when talking with older rsync versions. For instance, deleted files were only output as verbose messages prior to rsync 2.6.4.

timeout override the clients choice for I/O timeout for this module. Using this parameter you can ensure that rsync won't wait on a dead client forever. The timeout is specified in seconds. A value of zero means no timeout and is the default. A good choice for anonymous rsync daemons may be 600 (giving a 10 minute timeout).

refuse options specify a space-separated list of rsync command line options that will be refused by your rsync daemon. You may specify the full option name, its one-letter abbreviation, or a wild-card string that matches multiple options. For example, this would refuse --checksum (-c) and all the various delete options:

refuse options = c delete

The reason the above refuses all delete options is that the options imply --delete, and implied options are refused just like explicit options. As an additional safety feature, the refusal of "delete" also refuses remove-source-files when the daemon is the sender; if you want the latter without the former, instead refuse "delete-*" -- that refuses all the delete modes without affecting --remove-source-files.

When an option is refused, the daemon prints an error message and exits. To prevent all compression when serving files, you can use "dont compress = *" (see below) instead of "refuse options = compress" to avoid returning an error to a client that requests compression.

dont compress select filenames based on wildcard patterns that should not be compressed when pulling files from the daemon (no analogous parameter exists to govern the pushing of files to a daemon). Compression is expensive in terms of CPU usage, so it is usually good to not try to compress files that won't compress well, such as already compressed files.

The "dont compress" parameter takes a space-separated list of case-insensitive wildcard patterns. Any source filename matching one of the patterns will not be compressed during transfer.

See --skip-compress parameter in the rsync(1) manpage for the list of file suffixes that are not compressed by default. Specifying a value for the "dont compress" parameter changes the default when the daemon is the sender.

pre-xfer exec, post-xfer exec You may specify a command to be run before and/or after the transfer. If the pre-xfer exec command fails, the transfer is aborted before it begins.

The following environment variables will be set, though some are specific to the pre-xfer or the post-xfer environment:

  • RSYNC_MODULE_NAME: The name of the module being accessed.
  • RSYNC_MODULE_PATH: The path configured for the module.
  • RSYNC_HOST_ADDR: The accessing host's IP address.
  • RSYNC_HOST_NAME: The accessing host's name.
  • RSYNC_USER_NAME: The accessing user's name (empty if no user).
  • RSYNC_PID: A unique number for this transfer.
  • RSYNC_REQUEST: (pre-xfer only) The module/path info specified by the user (note that the user can specify multiple source files, so the request can be something like "mod/path1 mod/path2", etc.).
  • RSYNC_ARG#: (pre-xfer only) The pre-request arguments are set in these numbered values. RSYNC_ARG0 is always "rsyncd", and the last value contains a single period.
  • RSYNC_EXIT_STATUS: (post-xfer only) the server side's exit value. This will be 0 for a successful run, a positive value for an error that the server generated, or a -1 if rsync failed to exit properly. Note that an error that occurs on the client side does not currently get sent to the server side, so this is not the final exit status for the whole transfer.
  • RSYNC_RAW_STATUS: (post-xfer only) the raw exit value from waitpid() .

commands can be associated with a particular module, they are run using the permissions of the user that started the daemon (not the module's uid/gid setting) without any chroot restrictions.

Encryption

Authentication uses a 128 bit MD4 based challenge response.
For a more secure environment, run rsync over ssh.

rsync protocol does not currently provide encryption
Use ssh as the transport for encryption.

EXAMPLES

A simple rsyncd.conf file allowing anonymous rsync to a ftp area at /home/packages/ftp would be:
 
[ftp]
        path = /home/packages/ftp
        comment = ftp export area 

A sophisticated example:

 
uid = nobody
gid = nobody
use chroot = yes
max connections = 4
syslog facility = local5
pid file = /var/run/rsyncd.pid

[ftp]
        path = /var/ftp/./pub
        comment = whole ftp area (approx 6.1 GB)

[samba]
        path = /var/ftp/./pub/samba
        comment = Samba ftp area (approx 300 MB)

[rsync]
        path = /var/ftp/./pub/rsync
        comment = rsync ftp area (approx 6 MB)

[sambawww]
        path = /public_html/samba
        comment = Samba WWW pages (approx 240 MB)

[cvs]
        path = /data/cvs
        comment = CVS repository (requires authentication)
        auth users = tridge, susan
        secrets file = /etc/rsyncd.secrets

/etc/rsyncd.secrets would look like this:

tridge:mypass
susan:herpass

See also: rsync

Running rsync as a daemon

  1. The log and lock files must be writable by the user rsync daemon runs as.
  2. The exported directory must be readable and perhaps writeable.
  3. Root privileges are required to use chroot or to set file ownership.
    Avoid using root by specifing a port over 1024 (default 873).

    Launched
  1. as a stand-alone daemon ( include --daemon, or
  2. via a remote shell.(rsyncd.config is taken from the user's home)
  3. from inetd,

To run via inetd, include a port declaration in /etc/services:

rsync           873/tcp 
and a line in /etc/inetd.conf:
  rsync   stream  tcp     nowait  root   /usr/bin/rsync rsyncd --daemon
Send inetd a HUP signal to tell it to reread its config file. kill -hup `cat /var/run/xinetd.pid`

rsync reads rsyncd.conf on each connection so signaling it is unnecessary.

DIAGNOSTICS

This man page is current for version 3.0.7 of rsync.

The original information (and the TRUE story) is at