## GLOBAL PARAMETERS
The first parameters in the file (before a [module] header) are the global
-parameters. Rsync also allows for the use of a "[global]" module name to
-indicate the start of one or more global-parameter sections (the name must be
-lower case).
-
-You may also include any module parameters in the global part of the config
-file in which case the supplied value will override the default for that
-parameter.
-
-You may use references to environment variables in the values of parameters.
-String parameters will have %VAR% references expanded as late as possible (when
-the string is first used in the program), allowing for the use of variables
-that rsync sets at connection time, such as RSYNC_USER_NAME. Non-string
-parameters (such as true/false settings) are expanded when read from the config
-file. If a variable does not exist in the environment, or if a sequence of
-characters is not a valid reference (such as an un-paired percent sign), the
-raw characters are passed through unchanged. This helps with backward
-compatibility and safety (e.g. expanding a non-existent %VAR% to an empty
-string in a path could result in a very unsafe path). The safest way to insert
-a literal % into a value is to use %%.
+parameters:
[comment]: # (An OL starting at 0 is converted into a DL by the parser.)
You can override the default backlog value when the daemon listens for
connections. It defaults to 5.
+You may also include any [MODULE PARAMETERS](#) in the global part of the
+config file, in which case the supplied value will override the default for
+that parameter.
+
+You may use references to environment variables in the values of parameters.
+String parameters will have %VAR% references expanded as late as possible (when
+the string is first used in the program), allowing for the use of variables
+that rsync sets at connection time, such as RSYNC_USER_NAME. Non-string
+parameters (such as true/false settings) are expanded when read from the config
+file. If a variable does not exist in the environment, or if a sequence of
+characters is not a valid reference (such as an un-paired percent sign), the
+raw characters are passed through unchanged. This helps with backward
+compatibility and safety (e.g. expanding a non-existent %VAR% to an empty
+string in a path could result in a very unsafe path). The safest way to insert
+a literal % into a value is to use %%.
+
## MODULE PARAMETERS
After the global parameters you should define a number of modules, each module
module. The module name cannot contain a slash or a closing square bracket.
If the name contains whitespace, each internal sequence of whitespace will be
changed into a single space, while leading or trailing whitespace will be
-discarded. Also, the name cannot be "global" as that exact name indicates that
-global parameters follow (see above).
+discarded.
+
+There is also a special module name of "[global]" that does not define a module
+but instead switches back to the global settings context where default
+parameters can be specified. Because each defined module gets its full set of
+parameters as a combination of the default values that are set at that position
+in the config file plus its own parameter list, the use of a "[global]" section
+can help to maintain shared config values for multiple modules.
-As with GLOBAL PARAMETERS, you may use references to environment variables in
-the values of parameters. See the GLOBAL PARAMETERS section for more details.
+As with [GLOBAL PARAMETERS](#), you may use references to environment variables
+in the values of parameters. See that section for details.
0. `comment`
divider in it -- this causes an unset value to be treated as true for that
module.
- Prior to rsync 3.2.7, the default value was "true". The new default makes
- it easier to setup an rsync daemon as a non-root user or to run a daemon on
- a system where chroot fails. Explicitly setting the value to true in the
- rsyncd.conf file will always require the chroot to succeed.
+ Prior to rsync 3.2.7, the default value was "true". The new "unset"
+ default makes it easier to setup an rsync daemon as a non-root user or to
+ run a daemon on a system where chroot fails. Explicitly setting the value
+ to "true" in rsyncd.conf will always require the chroot to succeed.
It is also possible to specify a dot-dir in the module's "[path](#)" to
indicate that you want to chdir to the earlier part of the path and then
- serve files from inside the latter part of the path (with default
- sanitizing and symlink munging). This can be useful if you need some
- library dirs inside the chroot (typically for uid & gid lookups) but don't
- want to put the lib dir into the top of the served path (even though they
- can be hidden with an [`exclude`](#) directive). However, a better choice
- for a modern rsync setup is to use a [`name converter`](#)" and try to
- avoid inner lib dirs altogether. See also the [`daemon chroot`](#)
- parameter, which causes rsync to chroot into its own chroot area before
- doing any path-related chrooting.
+ serve files from inside the latter part of the path (with sanitizing and
+ default symlink munging). This can be useful if you need some library dirs
+ inside the chroot (typically for uid & gid lookups) but don't want to put
+ the lib dir into the top of the served path (even though they can be hidden
+ with an [`exclude`](#) directive). However, a better choice for a modern
+ rsync setup is to use a [`name converter`](#)" and try to avoid inner lib
+ dirs altogether. See also the [`daemon chroot`](#) parameter, which causes
+ rsync to chroot into its own chroot area before doing any path-related
+ chrooting.
If the daemon is serving the "/" dir (either directly or due to being
- chrooted to the module's path), rsync does not do any extra path sanitizing
- or (default) munging. When it has to limit access to a particular subdir
- (either due to chroot being disabled or having an inside-chroot path set),
- rsync will munge symlinks (by default) and sanitize paths. Those that
- dislike munged symlinks (and really, really trust their users to not break
- out of the subdir) can disable the symlink munging via the "[munge
- symlinks](#)" parameter. Sanitizing paths trims ".." path elements from
- args that rsync believes would escape the module hierarchy, and also
- substitutes leading slashes in absolute paths with the module's path (so
- that options such as `--backup-dir` & `--compare-dest` interpret an
- absolute path as rooted in the module's "[path](#)" dir).
+ chrooted to the module's path), rsync does not do any path sanitizing or
+ (default) munging.
+
+ When it has to limit access to a particular subdir (either due to chroot
+ being disabled or having an inside-chroot path set), rsync will munge
+ symlinks (by default) and sanitize paths. Those that dislike munged
+ symlinks (and really, really trust their users to not break out of the
+ subdir) can disable the symlink munging via the "[munge symlinks](#)"
+ parameter.
+
+ When rsync is sanitizing paths, it trims ".." path elements from args that
+ it believes would escape the module hierarchy. It also substitutes leading
+ slashes in absolute paths with the module's path (so that options such as
+ `--backup-dir` & `--compare-dest` interpret an absolute path as rooted in
+ the module's "[path](#)" dir).
When a chroot is in effect *and* the "[name converter](#)" parameter is
*not* set, the "[numeric ids](#)" parameter will default to being enabled
git.samba.org / rsync.git / blobdiff