1rsyncd.conf(5) User Commands rsyncd.conf(5)
2
3
4
6 rsyncd.conf - configuration file for rsync in daemon mode
7
9 rsyncd.conf
10
11 The online version of this manpage (that includes cross-linking of top‐
12 ics) is available at https://down‐
13 load.samba.org/pub/rsync/rsyncd.conf.5.
14
16 The rsyncd.conf file is the runtime configuration file for rsync when
17 run as an rsync daemon.
18
19 The rsyncd.conf file controls authentication, access, logging and
20 available modules.
21
23 The file consists of modules and parameters. A module begins with the
24 name of the module in square brackets and continues until the next mod‐
25 ule begins. Modules contain parameters of the form name = value.
26
27 The file is line-based -- that is, each newline-terminated line repre‐
28 sents either a comment, a module name or a parameter.
29
30 Only the first equals sign in a parameter is significant. Whitespace
31 before or after the first equals sign is discarded. Leading, trailing
32 and internal whitespace in module and parameter names is irrelevant.
33 Leading and trailing whitespace in a parameter value is discarded. In‐
34 ternal whitespace within a parameter value is retained verbatim.
35
36 Any line beginning with a hash (#) is ignored, as are lines containing
37 only whitespace. (If a hash occurs after anything other than leading
38 whitespace, it is considered a part of the line's content.)
39
40 Any line ending in a \ is "continued" on the next line in the customary
41 UNIX fashion.
42
43 The values following the equals sign in parameters are all either a
44 string (no quotes needed) or a boolean, which may be given as yes/no,
45 0/1 or true/false. Case is not significant in boolean values, but is
46 preserved in string values.
47
49 The rsync daemon is launched by specifying the --daemon option to
50 rsync.
51
52 The daemon must run with root privileges if you wish to use chroot, to
53 bind to a port numbered under 1024 (as is the default 873), or to set
54 file ownership. Otherwise, it must just have permission to read and
55 write the appropriate data, log, and lock files.
56
57 You can launch it either via inetd, as a stand-alone daemon, or from an
58 rsync client via a remote shell. If run as a stand-alone daemon then
59 just run the command "rsync --daemon" from a suitable startup script.
60
61 When run via inetd you should add a line like this to /etc/services:
62
63 rsync 873/tcp
64
65 and a single line something like this to /etc/inetd.conf:
66
67 rsync stream tcp nowait root /usr/bin/rsync rsyncd --daemon
68
69 Replace "/usr/bin/rsync" with the path to where you have rsync in‐
70 stalled on your system. You will then need to send inetd a HUP signal
71 to tell it to reread its config file.
72
73 Note that you should not send the rsync daemon a HUP signal to force it
74 to reread the rsyncd.conf file. The file is re-read on each client con‐
75 nection.
76
78 The first parameters in the file (before a [module] header) are the
79 global parameters. Rsync also allows for the use of a "[global]" mod‐
80 ule name to indicate the start of one or more global-parameter sections
81 (the name must be lower case).
82
83 You may also include any module parameters in the global part of the
84 config file in which case the supplied value will override the default
85 for that parameter.
86
87 You may use references to environment variables in the values of param‐
88 eters. String parameters will have %VAR% references expanded as late
89 as possible (when the string is first used in the program), allowing
90 for the use of variables that rsync sets at connection time, such as
91 RSYNC_USER_NAME. Non-string parameters (such as true/false settings)
92 are expanded when read from the config file. If a variable does not
93 exist in the environment, or if a sequence of characters is not a valid
94 reference (such as an un-paired percent sign), the raw characters are
95 passed through unchanged. This helps with backward compatibility and
96 safety (e.g. expanding a non-existent %VAR% to an empty string in a
97 path could result in a very unsafe path). The safest way to insert a
98 literal % into a value is to use %%.
99
100 motd file
101 This parameter allows you to specify a "message of the day"
102 (MOTD) to display to clients on each connect. This usually con‐
103 tains site information and any legal notices. The default is no
104 MOTD file. This can be overridden by the --dparam=motdfile=FILE
105 command-line option when starting the daemon.
106
107 pid file
108 This parameter tells the rsync daemon to write its process ID to
109 that file. The rsync keeps the file locked so that it can know
110 when it is safe to overwrite an existing file.
111
112 The filename can be overridden by the --dparam=pidfile=FILE com‐
113 mand-line option when starting the daemon.
114
115 port You can override the default port the daemon will listen on by
116 specifying this value (defaults to 873). This is ignored if the
117 daemon is being run by inetd, and is superseded by the --port
118 command-line option.
119
120 address
121 You can override the default IP address the daemon will listen
122 on by specifying this value. This is ignored if the daemon is
123 being run by inetd, and is superseded by the --address command-
124 line option.
125
126 socket options
127 This parameter can provide endless fun for people who like to
128 tune their systems to the utmost degree. You can set all sorts
129 of socket options which may make transfers faster (or slower!).
130 Read the manpage for the setsockopt() system call for details on
131 some of the options you may be able to set. By default no spe‐
132 cial socket options are set. These settings can also be speci‐
133 fied via the --sockopts command-line option.
134
135 listen backlog
136 You can override the default backlog value when the daemon lis‐
137 tens for connections. It defaults to 5.
138
140 After the global parameters you should define a number of modules, each
141 module exports a directory tree as a symbolic name. Modules are ex‐
142 ported by specifying a module name in square brackets [module] followed
143 by the parameters for that module. The module name cannot contain a
144 slash or a closing square bracket. If the name contains whitespace,
145 each internal sequence of whitespace will be changed into a single
146 space, while leading or trailing whitespace will be discarded. Also,
147 the name cannot be "global" as that exact name indicates that global
148 parameters follow (see above).
149
150 As with GLOBAL PARAMETERS, you may use references to environment vari‐
151 ables in the values of parameters. See the GLOBAL PARAMETERS section
152 for more details.
153
154 comment
155 This parameter specifies a description string that is displayed
156 next to the module name when clients obtain a list of available
157 modules. The default is no comment.
158
159 path This parameter specifies the directory in the daemon's filesys‐
160 tem to make available in this module. You must specify this pa‐
161 rameter for each module in rsyncd.conf.
162
163 If the value contains a "/./" element then the path will be di‐
164 vided at that point into a chroot dir and an inner-chroot sub‐
165 dir. If use chroot is set to false, though, the extraneous dot
166 dir is just cleaned out of the path. An example of this idiom
167 is:
168
169 path = /var/rsync/./module1
170
171 This will (when chrooting) chroot to "/var/rsync" and set the
172 inside-chroot path to "/module1".
173
174 You may base the path's value off of an environment variable by
175 surrounding the variable name with percent signs. You can even
176 reference a variable that is set by rsync when the user con‐
177 nects. For example, this would use the authorizing user's name
178 in the path:
179
180 path = /home/%RSYNC_USER_NAME%
181
182 It is fine if the path includes internal spaces -- they will be
183 retained verbatim (which means that you shouldn't try to escape
184 them). If your final directory has a trailing space (and this
185 is somehow not something you wish to fix), append a trailing
186 slash to the path to avoid losing the trailing whitespace.
187
188 use chroot
189 If "use chroot" is true, the rsync daemon will chroot to the
190 "path" before starting the file transfer with the client. This
191 has the advantage of extra protection against possible implemen‐
192 tation security holes, but it has the disadvantages of requiring
193 super-user privileges, of not being able to follow symbolic
194 links that are either absolute or outside of the new root path,
195 and of complicating the preservation of users and groups by name
196 (see below).
197
198 If use chroot is not set, it defaults to trying to enable a ch‐
199 root but allows the daemon to continue (after logging a warning)
200 if it fails. The one exception to this is when a module's path
201 has a "/./" chroot divider in it -- this causes an unset value
202 to be treated as true for that module.
203
204 Prior to rsync 3.2.7, the default value was "true". The new
205 "unset" default makes it easier to setup an rsync daemon as a
206 non-root user or to run a daemon on a system where chroot fails.
207 Explicitly setting the value to "true" in rsyncd.conf will al‐
208 ways require the chroot to succeed.
209
210 It is also possible to specify a dot-dir in the module's "path"
211 to indicate that you want to chdir to the earlier part of the
212 path and then serve files from inside the latter part of the
213 path (with sanitizing and default symlink munging). This can be
214 useful if you need some library dirs inside the chroot (typi‐
215 cally for uid & gid lookups) but don't want to put the lib dir
216 into the top of the served path (even though they can be hidden
217 with an exclude directive). However, a better choice for a mod‐
218 ern rsync setup is to use a name converter" and try to avoid in‐
219 ner lib dirs altogether. See also the daemon chroot parameter,
220 which causes rsync to chroot into its own chroot area before do‐
221 ing any path-related chrooting.
222
223 If the daemon is serving the "/" dir (either directly or due to
224 being chrooted to the module's path), rsync does not do any path
225 sanitizing or (default) munging.
226
227 When it has to limit access to a particular subdir (either due
228 to chroot being disabled or having an inside-chroot path set),
229 rsync will munge symlinks (by default) and sanitize paths.
230 Those that dislike munged symlinks (and really, really trust
231 their users to not break out of the subdir) can disable the sym‐
232 link munging via the "munge symlinks" parameter.
233
234 When rsync is sanitizing paths, it trims ".." path elements from
235 args that it believes would escape the module hierarchy. It also
236 substitutes leading slashes in absolute paths with the module's
237 path (so that options such as --backup-dir & --compare-dest in‐
238 terpret an absolute path as rooted in the module's "path" dir).
239
240 When a chroot is in effect and the "name converter" parameter is
241 not set, the "numeric ids" parameter will default to being en‐
242 abled (disabling name lookups). This means that if you manually
243 setup name-lookup libraries in your chroot (instead of using a
244 name converter) that you need to explicitly set nu‐
245 meric ids = false for rsync to do name lookups.
246
247 If you copy library resources into the module's chroot area, you
248 should protect them through your OS's normal user/group or ACL
249 settings (to prevent the rsync module's user from being able to
250 change them), and then hide them from the user's view via "ex‐
251 clude" (see how in the discussion of that parameter). However,
252 it's easier and safer to setup a name converter.
253
254 daemon chroot
255 This parameter specifies a path to which the daemon will chroot
256 before beginning communication with clients. Module paths (and
257 any "use chroot" settings) will then be related to this one.
258 This lets you choose if you want the whole daemon to be chrooted
259 (with this setting), just the transfers to be chrooted (with
260 "use chroot"), or both. Keep in mind that the "daemon chroot"
261 area may need various OS/lib/etc files installed to allow the
262 daemon to function. By default the daemon runs without any ch‐
263 rooting.
264
265 proxy protocol
266 When this parameter is enabled, all incoming connections must
267 start with a V1 or V2 proxy protocol header. If the header is
268 not found, the connection is closed.
269
270 Setting this to true requires a proxy server to forward source
271 IP information to rsync, allowing you to log proper IP/host info
272 and make use of client-oriented IP restrictions. The default of
273 false means that the IP information comes directly from the
274 socket's metadata. If rsync is not behind a proxy, this should
275 be disabled.
276
277 CAUTION: using this option can be dangerous if you do not ensure
278 that only the proxy is allowed to connect to the rsync port. If
279 any non-proxied connections are allowed through, the client will
280 be able to use a modified rsync to spoof any remote IP address
281 that they desire. You can lock this down using something like
282 iptables -uid-owner root rules (for strict localhost access),
283 various firewall rules, or you can require password authoriza‐
284 tion so that any spoofing by users will not grant extra access.
285
286 This setting is global. If you need some modules to require
287 this and not others, then you will need to setup multiple rsync
288 daemon processes on different ports.
289
290 name converter
291 This parameter lets you specify a program that will be run by
292 the rsync daemon to do user & group conversions between names &
293 ids. This script is started prior to any chroot being setup,
294 and runs as the daemon user (not the transfer user). You can
295 specify a fully qualified pathname or a program name that is on
296 the $PATH.
297
298 The program can be used to do normal user & group lookups with‐
299 out having to put any extra files into the chroot area of the
300 module or you can do customized conversions.
301
302 The nameconvert program has access to all of the environment
303 variables that are described in the section on pre-xfer exec.
304 This is useful if you want to customize the conversion using in‐
305 formation about the module and/or the copy request.
306
307 There is a sample python script in the support dir named "name‐
308 convert" that implements the normal user & group lookups. Feel
309 free to customize it or just use it as documentation to imple‐
310 ment your own.
311
312 numeric ids
313 Enabling this parameter disables the mapping of users and groups
314 by name for the current daemon module. This prevents the daemon
315 from trying to load any user/group-related files or libraries.
316 This enabling makes the transfer behave as if the client had
317 passed the --numeric-ids command-line option. By default, this
318 parameter is enabled for chroot modules and disabled for non-ch‐
319 root modules. Also keep in mind that uid/gid preservation re‐
320 quires the module to be running as root (see "uid") or for "fake
321 super" to be configured.
322
323 A chroot-enabled module should not have this parameter set to
324 false unless you're using a "name converter" program or you've
325 taken steps to ensure that the module has the necessary re‐
326 sources it needs to translate names and that it is not possible
327 for a user to change those resources.
328
329 munge symlinks
330 This parameter tells rsync to modify all symlinks in the same
331 way as the (non-daemon-affecting) --munge-links command-line op‐
332 tion (using a method described below). This should help protect
333 your files from user trickery when your daemon module is
334 writable. The default is disabled when "use chroot" is on with
335 an inside-chroot path of "/", OR if "daemon chroot" is on, oth‐
336 erwise it is enabled.
337
338 If you disable this parameter on a daemon that is not read-only,
339 there are tricks that a user can play with uploaded symlinks to
340 access daemon-excluded items (if your module has any), and, if
341 "use chroot" is off, rsync can even be tricked into showing or
342 changing data that is outside the module's path (as access-per‐
343 missions allow).
344
345 The way rsync disables the use of symlinks is to prefix each one
346 with the string "/rsyncd-munged/". This prevents the links from
347 being used as long as that directory does not exist. When this
348 parameter is enabled, rsync will refuse to run if that path is a
349 directory or a symlink to a directory. When using the "munge
350 symlinks" parameter in a chroot area that has an inside-chroot
351 path of "/", you should add "/rsyncd-munged/" to the exclude
352 setting for the module so that a user can't try to create it.
353
354 Note: rsync makes no attempt to verify that any pre-existing
355 symlinks in the module's hierarchy are as safe as you want them
356 to be (unless, of course, it just copied in the whole hierar‐
357 chy). If you setup an rsync daemon on a new area or locally add
358 symlinks, you can manually protect your symlinks from being
359 abused by prefixing "/rsyncd-munged/" to the start of every sym‐
360 link's value. There is a perl script in the support directory
361 of the source code named "munge-symlinks" that can be used to
362 add or remove this prefix from your symlinks.
363
364 When this parameter is disabled on a writable module and "use
365 chroot" is off (or the inside-chroot path is not "/"), incoming
366 symlinks will be modified to drop a leading slash and to remove
367 ".." path elements that rsync believes will allow a symlink to
368 escape the module's hierarchy. There are tricky ways to work
369 around this, though, so you had better trust your users if you
370 choose this combination of parameters.
371
372 charset
373 This specifies the name of the character set in which the mod‐
374 ule's filenames are stored. If the client uses an --iconv op‐
375 tion, the daemon will use the value of the "charset" parameter
376 regardless of the character set the client actually passed.
377 This allows the daemon to support charset conversion in a chroot
378 module without extra files in the chroot area, and also ensures
379 that name-translation is done in a consistent manner. If the
380 "charset" parameter is not set, the --iconv option is refused,
381 just as if "iconv" had been specified via "refuse options".
382
383 If you wish to force users to always use --iconv for a particu‐
384 lar module, add "no-iconv" to the "refuse options" parameter.
385 Keep in mind that this will restrict access to your module to
386 very new rsync clients.
387
388 max connections
389 This parameter allows you to specify the maximum number of si‐
390 multaneous connections you will allow. Any clients connecting
391 when the maximum has been reached will receive a message telling
392 them to try later. The default is 0, which means no limit. A
393 negative value disables the module. See also the "lock file"
394 parameter.
395
396 log file
397 When the "log file" parameter is set to a non-empty string, the
398 rsync daemon will log messages to the indicated file rather than
399 using syslog. This is particularly useful on systems (such as
400 AIX) where syslog() doesn't work for chrooted programs. The
401 file is opened before chroot() is called, allowing it to be
402 placed outside the transfer. If this value is set on a per-mod‐
403 ule basis instead of globally, the global log will still contain
404 any authorization failures or config-file error messages.
405
406 If the daemon fails to open the specified file, it will fall
407 back to using syslog and output an error about the failure.
408 (Note that the failure to open the specified log file used to be
409 a fatal error.)
410
411 This setting can be overridden by using the --log-file=FILE or
412 --dparam=logfile=FILE command-line options. The former over‐
413 rides all the log-file parameters of the daemon and all module
414 settings. The latter sets the daemon's log file and the default
415 for all the modules, which still allows modules to override the
416 default setting.
417
418 syslog facility
419 This parameter allows you to specify the syslog facility name to
420 use when logging messages from the rsync daemon. You may use any
421 standard syslog facility name which is defined on your system.
422 Common names are auth, authpriv, cron, daemon, ftp, kern, lpr,
423 mail, news, security, syslog, user, uucp, local0, local1, lo‐
424 cal2, local3, local4, local5, local6 and local7. The default is
425 daemon. This setting has no effect if the "log file" setting is
426 a non-empty string (either set in the per-modules settings, or
427 inherited from the global settings).
428
429 syslog tag
430 This parameter allows you to specify the syslog tag to use when
431 logging messages from the rsync daemon. The default is "rsyncd".
432 This setting has no effect if the "log file" setting is a non-
433 empty string (either set in the per-modules settings, or inher‐
434 ited from the global settings).
435
436 For example, if you wanted each authenticated user's name to be
437 included in the syslog tag, you could do something like this:
438
439 syslog tag = rsyncd.%RSYNC_USER_NAME%
440
441 max verbosity
442 This parameter allows you to control the maximum amount of ver‐
443 bose information that you'll allow the daemon to generate (since
444 the information goes into the log file). The default is 1, which
445 allows the client to request one level of verbosity.
446
447 This also affects the user's ability to request higher levels of
448 --info and --debug logging. If the max value is 2, then no info
449 and/or debug value that is higher than what would be set by -vv
450 will be honored by the daemon in its logging. To see how high
451 of a verbosity level you need to accept for a particular
452 info/debug level, refer to rsync --info=help and rsync --de‐
453 bug=help. For instance, it takes max-verbosity 4 to be able to
454 output debug TIME2 and FLIST3.
455
456 lock file
457 This parameter specifies the file to use to support the "max
458 connections" parameter. The rsync daemon uses record locking on
459 this file to ensure that the max connections limit is not ex‐
460 ceeded for the modules sharing the lock file. The default is
461 /var/run/rsyncd.lock.
462
463 read only
464 This parameter determines whether clients will be able to upload
465 files or not. If "read only" is true then any attempted uploads
466 will fail. If "read only" is false then uploads will be possible
467 if file permissions on the daemon side allow them. The default
468 is for all modules to be read only.
469
470 Note that "auth users" can override this setting on a per-user
471 basis.
472
473 write only
474 This parameter determines whether clients will be able to down‐
475 load files or not. If "write only" is true then any attempted
476 downloads will fail. If "write only" is false then downloads
477 will be possible if file permissions on the daemon side allow
478 them. The default is for this parameter to be disabled.
479
480 Helpful hint: you probably want to specify "refuse options =
481 delete" for a write-only module.
482
483 open noatime
484 When set to True, this parameter tells the rsync daemon to open
485 files with the O_NOATIME flag (on systems that support it) to
486 avoid changing the access time of the files that are being
487 transferred. If your OS does not support the O_NOATIME flag
488 then rsync will silently ignore this option. Note also that
489 some filesystems are mounted to avoid updating the atime on read
490 access even without the O_NOATIME flag being set.
491
492 When set to False, this parameters ensures that files on the
493 server are not opened with O_NOATIME.
494
495 When set to Unset (the default) the user controls the setting
496 via --open-noatime.
497
498 list This parameter determines whether this module is listed when the
499 client asks for a listing of available modules. In addition, if
500 this is false, the daemon will pretend the module does not exist
501 when a client denied by "hosts allow" or "hosts deny" attempts
502 to access it. Realize that if "reverse lookup" is disabled
503 globally but enabled for the module, the resulting reverse
504 lookup to a potentially client-controlled DNS server may still
505 reveal to the client that it hit an existing module. The de‐
506 fault is for modules to be listable.
507
508 uid This parameter specifies the user name or user ID that file
509 transfers to and from that module should take place as when the
510 daemon was run as root. In combination with the "gid" parameter
511 this determines what file permissions are available. The default
512 when run by a super-user is to switch to the system's "nobody"
513 user. The default for a non-super-user is to not try to change
514 the user. See also the "gid" parameter.
515
516 The RSYNC_USER_NAME environment variable may be used to request
517 that rsync run as the authorizing user. For example, if you
518 want a rsync to run as the same user that was received for the
519 rsync authentication, this setup is useful:
520
521 uid = %RSYNC_USER_NAME%
522 gid = *
523
524 gid This parameter specifies one or more group names/IDs that will
525 be used when accessing the module. The first one will be the
526 default group, and any extra ones be set as supplemental groups.
527 You may also specify a "*" as the first gid in the list, which
528 will be replaced by all the normal groups for the transfer's
529 user (see "uid"). The default when run by a super-user is to
530 switch to your OS's "nobody" (or perhaps "nogroup") group with
531 no other supplementary groups. The default for a non-super-user
532 is to not change any group attributes (and indeed, your OS may
533 not allow a non-super-user to try to change their group set‐
534 tings).
535
536 The specified list is normally split into tokens based on spaces
537 and commas. However, if the list starts with a comma, then the
538 list is only split on commas, which allows a group name to con‐
539 tain a space. In either case any leading and/or trailing white‐
540 space is removed from the tokens and empty tokens are ignored.
541
542 daemon uid
543 This parameter specifies a uid under which the daemon will run.
544 The daemon usually runs as user root, and when this is left un‐
545 set the user is left unchanged. See also the "uid" parameter.
546
547 daemon gid
548 This parameter specifies a gid under which the daemon will run.
549 The daemon usually runs as group root, and when this is left un‐
550 set, the group is left unchanged. See also the "gid" parameter.
551
552 fake super
553 Setting "fake super = yes" for a module causes the daemon side
554 to behave as if the --fake-super command-line option had been
555 specified. This allows the full attributes of a file to be
556 stored without having to have the daemon actually running as
557 root.
558
559 filter The daemon has its own filter chain that determines what files
560 it will let the client access. This chain is not sent to the
561 client and is independent of any filters the client may have
562 specified. Files excluded by the daemon filter chain (daemon-
563 excluded files) are treated as non-existent if the client tries
564 to pull them, are skipped with an error message if the client
565 tries to push them (triggering exit code 23), and are never
566 deleted from the module. You can use daemon filters to prevent
567 clients from downloading or tampering with private administra‐
568 tive files, such as files you may add to support uid/gid name
569 translations.
570
571 The daemon filter chain is built from the "filter", "include
572 from", "include", "exclude from", and "exclude" parameters, in
573 that order of priority. Anchored patterns are anchored at the
574 root of the module. To prevent access to an entire subtree, for
575 example, "/secret", you must exclude everything in the subtree;
576 the easiest way to do this is with a triple-star pattern like
577 "/secret/***".
578
579 The "filter" parameter takes a space-separated list of daemon
580 filter rules, though it is smart enough to know not to split a
581 token at an internal space in a rule (e.g. "- /foo - /bar" is
582 parsed as two rules). You may specify one or more merge-file
583 rules using the normal syntax. Only one "filter" parameter can
584 apply to a given module in the config file, so put all the rules
585 you want in a single parameter. Note that per-directory merge-
586 file rules do not provide as much protection as global rules,
587 but they can be used to make --delete work better during a
588 client download operation if the per-dir merge files are in‐
589 cluded in the transfer and the client requests that they be
590 used.
591
592 exclude
593 This parameter takes a space-separated list of daemon exclude
594 patterns. As with the client --exclude option, patterns can be
595 qualified with "- " or "+ " to explicitly indicate exclude/in‐
596 clude. Only one "exclude" parameter can apply to a given mod‐
597 ule. See the "filter" parameter for a description of how ex‐
598 cluded files affect the daemon.
599
600 include
601 Use an "include" to override the effects of the "exclude" param‐
602 eter. Only one "include" parameter can apply to a given module.
603 See the "filter" parameter for a description of how excluded
604 files affect the daemon.
605
606 exclude from
607 This parameter specifies the name of a file on the daemon that
608 contains daemon exclude patterns, one per line. Only one "ex‐
609 clude from" parameter can apply to a given module; if you have
610 multiple exclude-from files, you can specify them as a merge
611 file in the "filter" parameter. See the "filter" parameter for
612 a description of how excluded files affect the daemon.
613
614 include from
615 Analogue of "exclude from" for a file of daemon include pat‐
616 terns. Only one "include from" parameter can apply to a given
617 module. See the "filter" parameter for a description of how ex‐
618 cluded files affect the daemon.
619
620 incoming chmod
621 This parameter allows you to specify a set of comma-separated
622 chmod strings that will affect the permissions of all incoming
623 files (files that are being received by the daemon). These
624 changes happen after all other permission calculations, and this
625 will even override destination-default and/or existing permis‐
626 sions when the client does not specify --perms. See the de‐
627 scription of the --chmod rsync option and the chmod(1) manpage
628 for information on the format of this string.
629
630 outgoing chmod
631 This parameter allows you to specify a set of comma-separated
632 chmod strings that will affect the permissions of all outgoing
633 files (files that are being sent out from the daemon). These
634 changes happen first, making the sent permissions appear to be
635 different than those stored in the filesystem itself. For in‐
636 stance, you could disable group write permissions on the server
637 while having it appear to be on to the clients. See the de‐
638 scription of the --chmod rsync option and the chmod(1) manpage
639 for information on the format of this string.
640
641 auth users
642 This parameter specifies a comma and/or space-separated list of
643 authorization rules. In its simplest form, you list the user‐
644 names that will be allowed to connect to this module. The user‐
645 names do not need to exist on the local system. The rules may
646 contain shell wildcard characters that will be matched against
647 the username provided by the client for authentication. If "auth
648 users" is set then the client will be challenged to supply a
649 username and password to connect to the module. A challenge re‐
650 sponse authentication protocol is used for this exchange. The
651 plain text usernames and passwords are stored in the file speci‐
652 fied by the "secrets file" parameter. The default is for all
653 users to be able to connect without a password (this is called
654 "anonymous rsync").
655
656 In addition to username matching, you can specify groupname
657 matching via a '@' prefix. When using groupname matching, the
658 authenticating username must be a real user on the system, or it
659 will be assumed to be a member of no groups. For example, spec‐
660 ifying "@rsync" will match the authenticating user if the named
661 user is a member of the rsync group.
662
663 Finally, options may be specified after a colon (:). The op‐
664 tions allow you to "deny" a user or a group, set the access to
665 "ro" (read-only), or set the access to "rw" (read/write). Set‐
666 ting an auth-rule-specific ro/rw setting overrides the module's
667 "read only" setting.
668
669 Be sure to put the rules in the order you want them to be
670 matched, because the checking stops at the first matching user
671 or group, and that is the only auth that is checked. For exam‐
672 ple:
673
674 auth users = joe:deny @guest:deny admin:rw @rsync:ro susan joe sam
675
676 In the above rule, user joe will be denied access no matter
677 what. Any user that is in the group "guest" is also denied ac‐
678 cess. The user "admin" gets access in read/write mode, but only
679 if the admin user is not in group "guest" (because the admin
680 user-matching rule would never be reached if the user is in
681 group "guest"). Any other user who is in group "rsync" will get
682 read-only access. Finally, users susan, joe, and sam get the
683 ro/rw setting of the module, but only if the user didn't match
684 an earlier group-matching rule.
685
686 If you need to specify a user or group name with a space in it,
687 start your list with a comma to indicate that the list should
688 only be split on commas (though leading and trailing whitespace
689 will also be removed, and empty entries are just ignored). For
690 example:
691
692 auth users = , joe:deny, @Some Group:deny, admin:rw, @RO Group:ro
693
694 See the description of the secrets file for how you can have
695 per-user passwords as well as per-group passwords. It also ex‐
696 plains how a user can authenticate using their user password or
697 (when applicable) a group password, depending on what rule is
698 being authenticated.
699
700 See also the section entitled "USING RSYNC-DAEMON FEATURES VIA A
701 REMOTE SHELL CONNECTION" in rsync(1) for information on how han‐
702 dle an rsyncd.conf-level username that differs from the remote-
703 shell-level username when using a remote shell to connect to an
704 rsync daemon.
705
706 secrets file
707 This parameter specifies the name of a file that contains the
708 username:password and/or @groupname:password pairs used for au‐
709 thenticating this module. This file is only consulted if the
710 "auth users" parameter is specified. The file is line-based and
711 contains one name:password pair per line. Any line has a hash
712 (#) as the very first character on the line is considered a com‐
713 ment and is skipped. The passwords can contain any characters
714 but be warned that many operating systems limit the length of
715 passwords that can be typed at the client end, so you may find
716 that passwords longer than 8 characters don't work.
717
718 The use of group-specific lines are only relevant when the mod‐
719 ule is being authorized using a matching "@groupname" rule.
720 When that happens, the user can be authorized via either their
721 "username:password" line or the "@groupname:password" line for
722 the group that triggered the authentication.
723
724 It is up to you what kind of password entries you want to in‐
725 clude, either users, groups, or both. The use of group rules in
726 "auth users" does not require that you specify a group password
727 if you do not want to use shared passwords.
728
729 There is no default for the "secrets file" parameter, you must
730 choose a name (such as /etc/rsyncd.secrets). The file must nor‐
731 mally not be readable by "other"; see "strict modes". If the
732 file is not found or is rejected, no logins for an "auth users"
733 module will be possible.
734
735 strict modes
736 This parameter determines whether or not the permissions on the
737 secrets file will be checked. If "strict modes" is true, then
738 the secrets file must not be readable by any user ID other than
739 the one that the rsync daemon is running under. If "strict
740 modes" is false, the check is not performed. The default is
741 true. This parameter was added to accommodate rsync running on
742 the Windows operating system.
743
744 hosts allow
745 This parameter allows you to specify a list of comma- and/or
746 whitespace-separated patterns that are matched against a con‐
747 necting client's hostname and IP address. If none of the pat‐
748 terns match, then the connection is rejected.
749
750 Each pattern can be in one of six forms:
751
752 o a dotted decimal IPv4 address of the form a.b.c.d, or an
753 IPv6 address of the form a:b:c::d:e:f. In this case the
754 incoming machine's IP address must match exactly.
755
756 o an address/mask in the form ipaddr/n where ipaddr is the
757 IP address and n is the number of one bits in the net‐
758 mask. All IP addresses which match the masked IP address
759 will be allowed in.
760
761 o an address/mask in the form ipaddr/maskaddr where ipaddr
762 is the IP address and maskaddr is the netmask in dotted
763 decimal notation for IPv4, or similar for IPv6, e.g.
764 ffff:ffff:ffff:ffff:: instead of /64. All IP addresses
765 which match the masked IP address will be allowed in.
766
767 o a hostname pattern using wildcards. If the hostname of
768 the connecting IP (as determined by a reverse lookup)
769 matches the wildcarded name (using the same rules as nor‐
770 mal Unix filename matching), the client is allowed in.
771 This only works if "reverse lookup" is enabled (the de‐
772 fault).
773
774 o a hostname. A plain hostname is matched against the re‐
775 verse DNS of the connecting IP (if "reverse lookup" is
776 enabled), and/or the IP of the given hostname is matched
777 against the connecting IP (if "forward lookup" is en‐
778 abled, as it is by default). Any match will be allowed
779 in.
780
781 o an '@' followed by a netgroup name, which will match if
782 the reverse DNS of the connecting IP is in the specified
783 netgroup.
784
785 Note IPv6 link-local addresses can have a scope in the address
786 specification:
787
788 fe80::1%link1
789 fe80::%link1/64
790 fe80::%link1/ffff:ffff:ffff:ffff::
791
792 You can also combine "hosts allow" with "hosts deny" as a way to
793 add exceptions to your deny list. When both parameters are
794 specified, the "hosts allow" parameter is checked first and a
795 match results in the client being able to connect. A non-al‐
796 lowed host is then matched against the "hosts deny" list to see
797 if it should be rejected. A host that does not match either
798 list is allowed to connect.
799
800 The default is no "hosts allow" parameter, which means all hosts
801 can connect.
802
803 hosts deny
804 This parameter allows you to specify a list of comma- and/or
805 whitespace-separated patterns that are matched against a con‐
806 necting clients hostname and IP address. If the pattern matches
807 then the connection is rejected. See the "hosts allow" parameter
808 for more information.
809
810 The default is no "hosts deny" parameter, which means all hosts
811 can connect.
812
813 reverse lookup
814 Controls whether the daemon performs a reverse lookup on the
815 client's IP address to determine its hostname, which is used for
816 "hosts allow" & "hosts deny" checks and the "%h" log escape.
817 This is enabled by default, but you may wish to disable it to
818 save time if you know the lookup will not return a useful re‐
819 sult, in which case the daemon will use the name "UNDETERMINED"
820 instead.
821
822 If this parameter is enabled globally (even by default), rsync
823 performs the lookup as soon as a client connects, so disabling
824 it for a module will not avoid the lookup. Thus, you probably
825 want to disable it globally and then enable it for modules that
826 need the information.
827
828 forward lookup
829 Controls whether the daemon performs a forward lookup on any
830 hostname specified in an hosts allow/deny setting. By default
831 this is enabled, allowing the use of an explicit hostname that
832 would not be returned by reverse DNS of the connecting IP.
833
834 ignore errors
835 This parameter tells rsyncd to ignore I/O errors on the daemon
836 when deciding whether to run the delete phase of the transfer.
837 Normally rsync skips the --delete step if any I/O errors have
838 occurred in order to prevent disastrous deletion due to a tempo‐
839 rary resource shortage or other I/O error. In some cases this
840 test is counter productive so you can use this parameter to turn
841 off this behavior.
842
843 ignore nonreadable
844 This tells the rsync daemon to completely ignore files that are
845 not readable by the user. This is useful for public archives
846 that may have some non-readable files among the directories, and
847 the sysadmin doesn't want those files to be seen at all.
848
849 transfer logging
850 This parameter enables per-file logging of downloads and uploads
851 in a format somewhat similar to that used by ftp daemons. The
852 daemon always logs the transfer at the end, so if a transfer is
853 aborted, no mention will be made in the log file.
854
855 If you want to customize the log lines, see the "log format" pa‐
856 rameter.
857
858 log format
859 This parameter allows you to specify the format used for logging
860 file transfers when transfer logging is enabled. The format is
861 a text string containing embedded single-character escape se‐
862 quences prefixed with a percent (%) character. An optional nu‐
863 meric field width may also be specified between the percent and
864 the escape letter (e.g. "%-50n %8l %07p"). In addition, one or
865 more apostrophes may be specified prior to a numerical escape to
866 indicate that the numerical value should be made more human-
867 readable. The 3 supported levels are the same as for the --hu‐
868 man-readable command-line option, though the default is for hu‐
869 man-readability to be off. Each added apostrophe increases the
870 level (e.g. "%''l %'b %f").
871
872 The default log format is "%o %h [%a] %m (%u) %f %l", and a
873 "%t [%p] " is always prefixed when using the "log file" parame‐
874 ter. (A perl script that will summarize this default log format
875 is included in the rsync source code distribution in the "sup‐
876 port" subdirectory: rsyncstats.)
877
878 The single-character escapes that are understood are as follows:
879
880 o %a the remote IP address (only available for a daemon)
881
882 o %b the number of bytes actually transferred
883
884 o %B the permission bits of the file (e.g. rwxrwxrwt)
885
886 o %c the total size of the block checksums received for the
887 basis file (only when sending)
888
889 o %C the full-file checksum if it is known for the file.
890 For older rsync protocols/versions, the checksum was
891 salted, and is thus not a useful value (and is not dis‐
892 played when that is the case). For the checksum to output
893 for a file, either the --checksum option must be in-ef‐
894 fect or the file must have been transferred without a
895 salted checksum being used. See the --checksum-choice
896 option for a way to choose the algorithm.
897
898 o %f the filename (long form on sender; no trailing "/")
899
900 o %G the gid of the file (decimal) or "DEFAULT"
901
902 o %h the remote host name (only available for a daemon)
903
904 o %i an itemized list of what is being updated
905
906 o %l the length of the file in bytes
907
908 o %L the string " -> SYMLINK", " => HARDLINK", or "" (where
909 SYMLINK or HARDLINK is a filename)
910
911 o %m the module name
912
913 o %M the last-modified time of the file
914
915 o %n the filename (short form; trailing "/" on dir)
916
917 o %o the operation, which is "send", "recv", or "del." (the
918 latter includes the trailing period)
919
920 o %p the process ID of this rsync session
921
922 o %P the module path
923
924 o %t the current date time
925
926 o %u the authenticated username or an empty string
927
928 o %U the uid of the file (decimal)
929
930 For a list of what the characters mean that are output by "%i",
931 see the --itemize-changes option in the rsync manpage.
932
933 Note that some of the logged output changes when talking with
934 older rsync versions. For instance, deleted files were only
935 output as verbose messages prior to rsync 2.6.4.
936
937 timeout
938 This parameter allows you to override the clients choice for I/O
939 timeout for this module. Using this parameter you can ensure
940 that rsync won't wait on a dead client forever. The timeout is
941 specified in seconds. A value of zero means no timeout and is
942 the default. A good choice for anonymous rsync daemons may be
943 600 (giving a 10 minute timeout).
944
945 refuse options
946 This parameter allows you to specify a space-separated list of
947 rsync command-line options that will be refused by your rsync
948 daemon. You may specify the full option name, its one-letter
949 abbreviation, or a wild-card string that matches multiple op‐
950 tions. Beginning in 3.2.0, you can also negate a match term by
951 starting it with a "!".
952
953 When an option is refused, the daemon prints an error message
954 and exits.
955
956 For example, this would refuse --checksum (-c) and all the vari‐
957 ous delete options:
958
959 refuse options = c delete
960
961 The reason the above refuses all delete options is that the op‐
962 tions imply --delete, and implied options are refused just like
963 explicit options.
964
965 The use of a negated match allows you to fine-tune your refusals
966 after a wild-card, such as this:
967
968 refuse options = delete-* !delete-during
969
970 Negated matching can also turn your list of refused options into
971 a list of accepted options. To do this, begin the list with a
972 "*" (to refuse all options) and then specify one or more negated
973 matches to accept. For example:
974
975 refuse options = * !a !v !compress*
976
977 Don't worry that the "*" will refuse certain vital options such
978 as --dry-run, --server, --no-iconv, --seclude-args, etc. These
979 important options are not matched by wild-card, so they must be
980 overridden by their exact name. For instance, if you're forcing
981 iconv transfers you could use something like this:
982
983 refuse options = * no-iconv !a !v
984
985 As an additional aid (beginning in 3.2.0), refusing (or "!refus‐
986 ing") the "a" or "archive" option also affects all the options
987 that the --archive option implies (-rdlptgoD), but only if the
988 option is matched explicitly (not using a wildcard). If you
989 want to do something tricky, you can use "archive*" to avoid
990 this side-effect, but keep in mind that no normal rsync client
991 ever sends the actual archive option to the server.
992
993 As an additional safety feature, the refusal of "delete" also
994 refuses remove-source-files when the daemon is the sender; if
995 you want the latter without the former, instead refuse
996 "delete-*" as that refuses all the delete modes without affect‐
997 ing --remove-source-files. (Keep in mind that the client's
998 --delete option typically results in --delete-during.)
999
1000 When un-refusing delete options, you should either specify
1001 "!delete*" (to accept all delete options) or specify a limited
1002 set that includes "delete", such as:
1003
1004 refuse options = * !a !delete !delete-during
1005
1006 ... whereas this accepts any delete option except --delete-af‐
1007 ter:
1008
1009 refuse options = * !a !delete* delete-after
1010
1011 A note on refusing "compress": it may be better to set the "dont
1012 compress" daemon parameter to "*" and ensure that RSYNC_COM‐
1013 PRESS_LIST=zlib is set in the environment of the daemon in order
1014 to disable compression silently instead of returning an error
1015 that forces the client to remove the -z option.
1016
1017 If you are un-refusing the compress option, you may want to
1018 match "!compress*" if you also want to allow the --compress-
1019 level option.
1020
1021 Note that the "copy-devices" & "write-devices" options are re‐
1022 fused by default, but they can be explicitly accepted with
1023 "!copy-devices" and/or "!write-devices". The options "log-file"
1024 and "log-file-format" are forcibly refused and cannot be ac‐
1025 cepted.
1026
1027 Here are all the options that are not matched by wild-cards:
1028
1029 o --server: Required for rsync to even work.
1030
1031 o --rsh, -e: Required to convey compatibility flags to the
1032 server.
1033
1034 o --out-format: This is required to convey output behavior
1035 to a remote receiver. While rsync passes the older alias
1036 --log-format for compatibility reasons, this options
1037 should not be confused with --log-file-format.
1038
1039 o --sender: Use "write only" parameter instead of refusing
1040 this.
1041
1042 o --dry-run, -n: Who would want to disable this?
1043
1044 o --seclude-args, -s: Is the oldest arg-protection method.
1045
1046 o --from0, -0: Makes it easier to accept/refuse --files-
1047 from without affecting this helpful modifier.
1048
1049 o --iconv: This is auto-disabled based on "charset" parame‐
1050 ter.
1051
1052 o --no-iconv: Most transfers use this option.
1053
1054 o --checksum-seed: Is a fairly rare, safe option.
1055
1056 o --write-devices: Is non-wild but also auto-disabled.
1057
1058 dont compress
1059 NOTE: This parameter currently has no effect except in one in‐
1060 stance: if it is set to "*" then it minimizes or disables com‐
1061 pression for all files (for those that don't want to refuse the
1062 --compress option completely).
1063
1064 This parameter allows you to select filenames based on wildcard
1065 patterns that should not be compressed when pulling files from
1066 the daemon (no analogous parameter exists to govern the pushing
1067 of files to a daemon). Compression can be expensive in terms of
1068 CPU usage, so it is usually good to not try to compress files
1069 that won't compress well, such as already compressed files.
1070
1071 The "dont compress" parameter takes a space-separated list of
1072 case-insensitive wildcard patterns. Any source filename matching
1073 one of the patterns will be compressed as little as possible
1074 during the transfer. If the compression algorithm has an "off"
1075 level, then no compression occurs for those files. If an algo‐
1076 rithms has the ability to change the level in mid-stream, it
1077 will be minimized to reduce the CPU usage as much as possible.
1078
1079 See the --skip-compress parameter in the rsync(1) manpage for
1080 the list of file suffixes that are skipped by default if this
1081 parameter is not set.
1082
1083 early exec, pre-xfer exec, post-xfer exec
1084 You may specify a command to be run in the early stages of the
1085 connection, or right before and/or after the transfer. If the
1086 early exec or pre-xfer exec command returns an error code, the
1087 transfer is aborted before it begins. Any output from the pre-
1088 xfer exec command on stdout (up to several KB) will be displayed
1089 to the user when aborting, but is not displayed if the script
1090 returns success. The other programs cannot send any text to the
1091 user. All output except for the pre-xfer exec stdout goes to
1092 the corresponding daemon's stdout/stderr, which is typically
1093 discarded. See the --no-detatch option for a way to see the
1094 daemon's output, which can assist with debugging.
1095
1096 Note that the early exec command runs before any part of the
1097 transfer request is known except for the module name. This
1098 helper script can be used to setup a disk mount or decrypt some
1099 data into a module dir, but you may need to use lock file and
1100 max connections to avoid concurrency issues. If the client
1101 rsync specified the --early-input=FILE option, it can send up to
1102 about 5K of data to the stdin of the early script. The stdin
1103 will otherwise be empty.
1104
1105 Note that the post-xfer exec command is still run even if one of
1106 the other scripts returns an error code. The pre-xfer exec com‐
1107 mand will not be run, however, if the early exec command fails.
1108
1109 The following environment variables will be set, though some are
1110 specific to the pre-xfer or the post-xfer environment:
1111
1112 o RSYNC_MODULE_NAME: The name of the module being accessed.
1113
1114 o RSYNC_MODULE_PATH: The path configured for the module.
1115
1116 o RSYNC_HOST_ADDR: The accessing host's IP address.
1117
1118 o RSYNC_HOST_NAME: The accessing host's name.
1119
1120 o RSYNC_USER_NAME: The accessing user's name (empty if no
1121 user).
1122
1123 o RSYNC_PID: A unique number for this transfer.
1124
1125 o RSYNC_REQUEST: (pre-xfer only) The module/path info spec‐
1126 ified by the user. Note that the user can specify multi‐
1127 ple source files, so the request can be something like
1128 "mod/path1 mod/path2", etc.
1129
1130 o RSYNC_ARG#: (pre-xfer only) The pre-request arguments are
1131 set in these numbered values. RSYNC_ARG0 is always
1132 "rsyncd", followed by the options that were used in
1133 RSYNC_ARG1, and so on. There will be a value of "." in‐
1134 dicating that the options are done and the path args are
1135 beginning -- these contain similar information to
1136 RSYNC_REQUEST, but with values separated and the module
1137 name stripped off.
1138
1139 o RSYNC_EXIT_STATUS: (post-xfer only) the server side's
1140 exit value. This will be 0 for a successful run, a posi‐
1141 tive value for an error that the server generated, or a
1142 -1 if rsync failed to exit properly. Note that an error
1143 that occurs on the client side does not currently get
1144 sent to the server side, so this is not the final exit
1145 status for the whole transfer.
1146
1147 o RSYNC_RAW_STATUS: (post-xfer only) the raw exit value
1148 from waitpid().
1149
1150 Even though the commands can be associated with a particular
1151 module, they are run using the permissions of the user that
1152 started the daemon (not the module's uid/gid setting) without
1153 any chroot restrictions.
1154
1155 These settings honor 2 environment variables: use RSYNC_SHELL to
1156 set a shell to use when running the command (which otherwise
1157 uses your system() call's default shell), and use
1158 RSYNC_NO_XFER_EXEC to disable both options completely.
1159
1161 There are currently two config directives available that allow a config
1162 file to incorporate the contents of other files: &include and &merge.
1163 Both allow a reference to either a file or a directory. They differ in
1164 how segregated the file's contents are considered to be.
1165
1166 The &include directive treats each file as more distinct, with each one
1167 inheriting the defaults of the parent file, starting the parameter
1168 parsing as globals/defaults, and leaving the defaults unchanged for the
1169 parsing of the rest of the parent file.
1170
1171 The &merge directive, on the other hand, treats the file's contents as
1172 if it were simply inserted in place of the directive, and thus it can
1173 set parameters in a module started in another file, can affect the de‐
1174 faults for other files, etc.
1175
1176 When an &include or &merge directive refers to a directory, it will
1177 read in all the *.conf or *.inc files (respectively) that are contained
1178 inside that directory (without any recursive scanning), with the files
1179 sorted into alpha order. So, if you have a directory named "rsyncd.d"
1180 with the files "foo.conf", "bar.conf", and "baz.conf" inside it, this
1181 directive:
1182
1183 &include /path/rsyncd.d
1184
1185 would be the same as this set of directives:
1186
1187 &include /path/rsyncd.d/bar.conf
1188 &include /path/rsyncd.d/baz.conf
1189 &include /path/rsyncd.d/foo.conf
1190
1191 except that it adjusts as files are added and removed from the direc‐
1192 tory.
1193
1194 The advantage of the &include directive is that you can define one or
1195 more modules in a separate file without worrying about unintended side-
1196 effects between the self-contained module files.
1197
1198 The advantage of the &merge directive is that you can load config snip‐
1199 pets that can be included into multiple module definitions, and you can
1200 also set global values that will affect connections (such as
1201 motd file), or globals that will affect other include files.
1202
1203 For example, this is a useful /etc/rsyncd.conf file:
1204
1205 port = 873
1206 log file = /var/log/rsync.log
1207 pid file = /var/lock/rsync.lock
1208
1209 &merge /etc/rsyncd.d
1210 &include /etc/rsyncd.d
1211
1212 This would merge any /etc/rsyncd.d/*.inc files (for global values that
1213 should stay in effect), and then include any /etc/rsyncd.d/*.conf files
1214 (defining modules without any global-value cross-talk).
1215
1217 The authentication protocol used in rsync is a 128 bit MD4 based chal‐
1218 lenge response system. This is fairly weak protection, though (with at
1219 least one brute-force hash-finding algorithm publicly available), so if
1220 you want really top-quality security, then I recommend that you run
1221 rsync over ssh. (Yes, a future version of rsync will switch over to a
1222 stronger hashing method.)
1223
1224 Also note that the rsync daemon protocol does not currently provide any
1225 encryption of the data that is transferred over the connection. Only
1226 authentication is provided. Use ssh as the transport if you want en‐
1227 cryption.
1228
1229 You can also make use of SSL/TLS encryption if you put rsync behind an
1230 SSL proxy.
1231
1233 When setting up an rsync daemon for access via SSL/TLS, you will need
1234 to configure a TCP proxy (such as haproxy or nginx) as the front-end
1235 that handles the encryption.
1236
1237 o You should limit the access to the backend-rsyncd port to only
1238 allow the proxy to connect. If it is on the same host as the
1239 proxy, then configuring it to only listen on localhost is a good
1240 idea.
1241
1242 o You should consider turning on the proxy protocol rsync-daemon
1243 parameter if your proxy supports sending that information. The
1244 examples below assume that this is enabled.
1245
1246 An example haproxy setup is as follows:
1247
1248 frontend fe_rsync-ssl
1249 bind :::874 ssl crt /etc/letsencrypt/example.com/combined.pem
1250 mode tcp
1251 use_backend be_rsync
1252
1253 backend be_rsync
1254 mode tcp
1255 server local-rsync 127.0.0.1:873 check send-proxy
1256
1257 An example nginx proxy setup is as follows:
1258
1259 stream {
1260 server {
1261 listen 874 ssl;
1262 listen [::]:874 ssl;
1263
1264 ssl_certificate /etc/letsencrypt/example.com/fullchain.pem;
1265 ssl_certificate_key /etc/letsencrypt/example.com/privkey.pem;
1266
1267 proxy_pass localhost:873;
1268 proxy_protocol on; # Requires rsyncd.conf "proxy protocol = true"
1269 proxy_timeout 1m;
1270 proxy_connect_timeout 5s;
1271 }
1272 }
1273
1275 A simple rsyncd.conf file that allow anonymous rsync to a ftp area at
1276 /home/ftp would be:
1277
1278 [ftp]
1279 path = /home/ftp
1280 comment = ftp export area
1281
1282 A more sophisticated example would be:
1283
1284 uid = nobody
1285 gid = nobody
1286 use chroot = yes
1287 max connections = 4
1288 syslog facility = local5
1289 pid file = /var/run/rsyncd.pid
1290
1291 [ftp]
1292 path = /var/ftp/./pub
1293 comment = whole ftp area (approx 6.1 GB)
1294
1295 [sambaftp]
1296 path = /var/ftp/./pub/samba
1297 comment = Samba ftp area (approx 300 MB)
1298
1299 [rsyncftp]
1300 path = /var/ftp/./pub/rsync
1301 comment = rsync ftp area (approx 6 MB)
1302
1303 [sambawww]
1304 path = /public_html/samba
1305 comment = Samba WWW pages (approx 240 MB)
1306
1307 [cvs]
1308 path = /data/cvs
1309 comment = CVS repository (requires authentication)
1310 auth users = tridge, susan
1311 secrets file = /etc/rsyncd.secrets
1312
1313 The /etc/rsyncd.secrets file would look something like this:
1314
1315 tridge:mypass
1316 susan:herpass
1317
1319 /etc/rsyncd.conf or rsyncd.conf
1320
1322 rsync(1), rsync-ssl(1)
1323
1325 Please report bugs! The rsync bug tracking system is online at
1326 https://rsync.samba.org/.
1327
1329 This manpage is current for version 3.2.7 of rsync.
1330
1332 Rsync is distributed under the GNU General Public License. See the
1333 file COPYING for details.
1334
1335 An rsync web site is available at https://rsync.samba.org/ and its
1336 github project is https://github.com/WayneD/rsync.
1337
1339 Thanks to Warren Stanley for his original idea and patch for the rsync
1340 daemon. Thanks to Karsten Thygesen for his many suggestions and docu‐
1341 mentation!
1342
1344 Rsync was originally written by Andrew Tridgell and Paul Mackerras.
1345 Many people have later contributed to it. It is currently maintained by
1346 Wayne Davison.
1347
1348 Mailing lists for support and development are available at
1349 https://lists.samba.org/.
1350
1351
1352
1353rsyncd.conf from rsync 3.2.7 20 Oct 2022 rsyncd.conf(5)