-was run as root. This complements the "uid" option. The default is gid -2,
-which is normally the group "nobody".
-
-dit(bf(filter)) The "filter" option allows you to specify a space-separated
-list of filter rules that the server will not allow to be read or written.
-This is only superficially equivalent to the client specifying these
-patterns with the --filter option. Only one "filter" option may be
-specified, but it may contain as many rules as you like, including
-merge-file rules. 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 when a client downloads the server's files (if the per-dir
-merge files are included in the transfer).
-
-dit(bf(exclude)) The "exclude" option allows you to specify a
-space-separated list of patterns that the server will not allow to be read
-or written. This is only superficially equivalent to the client
-specifying these patterns with the --exclude option. Only one "exclude"
-option may be specified, but you can use "-" and "+" before patterns to
-specify exclude/include.
-
-Because this exclude list is not passed to the client it only applies on
-the server: that is, it excludes files received by a client when receiving
-from a server and files deleted on a server when sending to a server, but
-it doesn't exclude files from being deleted on a client when receiving
-from a server.
-
-dit(bf(exclude from)) The "exclude from" option specifies a filename
-on the server that contains exclude patterns, one per line.
-This is only superficially equivalent
-to the client specifying the --exclude-from option with an equivalent file.
-See the "exclude" option above.
-
-dit(bf(include)) The "include" option allows you to specify a
-space-separated list of patterns which rsync should not exclude. This is
-only superficially equivalent to the client specifying these patterns with
-the --include option because it applies only on the server. This is
-useful as it allows you to build up quite complex exclude/include rules.
-Only one "include" option may be specified, but you can use "+" and "-"
-before patterns to switch include/exclude. See the "exclude" option
-above.
-
-dit(bf(include from)) The "include from" option specifies a filename
-on the server that contains include patterns, one per line. This is
-only superficially equivalent to the client specifying the
---include-from option with a equivalent file.
-See the "exclude" option above.
-
-dit(bf(auth users)) The "auth users" option specifies a comma and
+was run as root. In combination with the "gid" parameter this determines what
+file permissions are available. The default when run by a super-user is to
+switch to the system's "nobody" user. The default for a non-super-user is to
+not try to change the user. See also the "gid" parameter.
+
+dit(bf(gid)) This parameter specifies one or more group names/IDs that will be
+used when accessing the module. The first one will be the default group, and
+any extra ones be set as supplemental groups. You may also specify a "*" as
+the first gid in the list, which will be replaced by all the normal groups for
+the transfer's user (see "uid"). The default when run by a super-user is to
+switch to your OS's "nobody" (or perhaps "nogroup") group with no other
+supplementary groups. The default for a non-super-user is to not change any
+group attributes (and indeed, your OS may not allow a non-super-user to try to
+change their group settings).
+
+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