rsyncd.conf.yo

Rsync 3.0.5 source code

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.

dit(bf(log file)) When the "log file" parameter is set to a non-empty
string, the rsync daemon will log messages to the indicated file rather
than using syslog. This is particularly useful on systems (such as AIX)
where code(syslog()) doesn't work for chrooted programs.  The file is
opened before code(chroot()) is called, allowing it to be placed outside
the transfer.  If this value is 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 specified file, it will fall back to
using syslog and output an error about the failure.  (Note that the
failure to open the specified log file used to be a fatal error.)

dit(bf(syslog facility)) This parameter allows you to
specify the syslog facility name to use when logging messages from the
rsync daemon. You may use any standard syslog facility name which is
defined on your system. 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.  This setting has no effect if the "log file" setting is a
non-empty string (either set in the per-modules settings, or inherited
from the global settings).

dit(bf(max verbosity)) This parameter allows you to control
the maximum amount of verbose information that you'll allow the daemon to
generate (since the information goes into the log file). The default is 1,
which allows the client to request one level of verbosity.

dit(bf(lock file)) This parameter specifies the file to use 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.
The default is tt(/var/run/rsyncd.lock).

dit(bf(read only)) This parameter determines whether clients
will be able to upload files or not. If "read only" is true then any
attempted uploads will fail. If "read only" is false then uploads will
be possible if file permissions on the daemon side allow them. The default
is for all modules to be read only.

dit(bf(write only)) This parameter determines whether clients
will be able to download files or not. If "write only" is true then any
attempted downloads will fail. If "write only" is false then downloads
will be possible if file permissions on the daemon side allow them.  The
default is for this parameter to be disabled.

dit(bf(list)) This parameter determines if this module should be
listed when the client asks for a listing of available modules. By
setting this to false you can create hidden modules. The default is
for modules to be listable.

dit(bf(uid)) This parameter specifies the user name or user ID that
file transfers to and from that module should take place as when the daemon
was run as root. In combination with the "gid" parameter this determines what
file permissions are available. The default is uid -2, which is normally
the user "nobody".

dit(bf(gid)) This parameter specifies the group name or group ID that
file transfers to and from that module should take place as when the daemon
was run as root. This complements the "uid" parameter. The default is gid -2,
which is normally the group "nobody".

dit(bf(fake super)) Setting "fake super = yes" for a module causes the
daemon side to behave as if the bf(--fake-user) command-line option had
been specified.  This allows the full attributes of a file to be stored
without having to have the daemon actually running as root.

dit(bf(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
the daemon filter chain (bf(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.  You can use daemon filters to prevent clients from downloading or
tampering 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, for example, "/secret", you em(must) exclude everything in the
subtree; the easiest way to do this is with a triple-star pattern like
"/secret/***".

The "filter" parameter takes a space-separated list of daemon filter rules,
though it is smart enough to know not to split a token at an internal space in
a rule (e.g. "- /foo  - /bar" is parsed as two rules).  You may 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 bf(--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.

dit(bf(exclude)) This parameter takes a space-separated list of daemon
exclude patterns.  As with the client bf(--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.

dit(bf(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.

dit(bf(exclude from)) This parameter specifies the 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.

dit(bf(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.

dit(bf(incoming chmod)) This parameter allows you to 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 bf(--perms).
See the description of the bf(--chmod) rsync option and the bf(chmod)(1)
manpage for information on the format of this string.

dit(bf(outgoing chmod)) This parameter allows you to 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 bf(--chmod) rsync option and the bf(chmod)(1)
manpage for information on the format of this string.

dit(bf(auth users)) This parameter specifies 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 also 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. The default is for all users to be able to
connect without a password (this is called "anonymous rsync").

See also the "CONNECTING TO AN RSYNC DAEMON OVER A REMOTE SHELL
PROGRAM" section in bf(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.

dit(bf(secrets file)) This parameter specifies the 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. The file is line based and contains
username:password pairs separated by a single colon. Any line starting
with a hash (#) is considered a comment and is skipped. 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, so
you may find that passwords longer than 8 characters don't work.

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

dit(bf(strict modes)) This parameter determines whether or not
the permissions on the secrets file will be checked.  If "strict modes" is
true, then the secrets file must not be readable by any user ID other
than the one that the rsync daemon is running under.  If "strict modes" is
false, the check is not performed.  The default is true.  This parameter
was added to accommodate rsync running on the Windows operating system.

dit(bf(hosts allow)) This parameter allows you to specify a
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 one of five forms:

quote(itemization(
  it() 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.
  it() 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.
  it() 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.
  it() 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.
  it() 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:

quote(
tt(    fe80::1%link1)nl()
tt(    fe80::%link1/64)nl()
tt(    fe80::%link1/ffff:ffff:ffff:ffff::)nl()
)

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.

dit(bf(hosts deny)) This parameter allows you to specify a
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.

dit(bf(ignore errors)) This parameter tells rsyncd to
ignore I/O errors on the daemon when deciding whether to run the delete
phase of the transfer. Normally rsync skips the bf(--delete) step if any
I/O errors have occurred in order to prevent disastrous deletion due
to a temporary resource shortage or other I/O error. In some cases this
test is counter productive so you can use this parameter to turn off this
behavior.

dit(bf(ignore nonreadable)) This tells the rsync daemon to completely
ignore files that are not readable by the user. This is 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.

dit(bf(transfer logging)) This parameter 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.