Re: rsync error

[Dave Gordon via rsync]

On 25/06/2020 13:18, Madhurananda Pahar via rsync wrote:
> Hello everybody, 
> 
>          I am having a funny problem while using rsync as a tool to
> back-up my files: 
> 
> [sender] expand file_list pointer array to 524288 bytes, did move.
> 
> I am just wondering if you had this issue before and if you know a way
> to solve this, please share with me. 
> 
> Many thanks,
> Dr. Madhurananda Pahar. 

That's just a debug message, letting the developers know when the file
list had to be expanded, and whether it had to be moved (by realloc(3))
as a result -- because that case introduces the particular hazard that
some other code might have kept a pointer to the old array. So this
message would be useful if one were debugging a random crash, to know
whether it only happened when the file list grew to a certain size, or
when it was relocated during expansion.

>   if (DEBUG_GTE(FLIST, 1) && flist->malloced != FLIST_START) {
>   rprintf(FCLIENT, "[%s] expand file_list pointer array to %s 
> bytes, did%s move\n",
>   who_am_i(),
>   big_num(sizeof flist->files[0] * flist->malloced),
>   (new_ptr == flist->files) ? " not" : "");
>   }
> 

It's not an error of any sort, and you're only seeing it because you've
enabled DEBUG_GTE. Is there some other problem that you're trying to debug?

.Dave.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: [Bug 12769] error allocating core memory buffers (code 22) depending on source file system

[Dave Gordon via rsync]

On 11/10/2019 13:53, just subscribed for rsync-qa from bugzilla via
rsync wrote:
> https://bugzilla.samba.org/show_bug.cgi?id=12769
>
> --- Comment #5 from Simon Matter  ---
> I'm suffering the same problem and was wondering if anyone found a solution or
> work around or other tool to do the job?
>
> First I thought maybe it's a bug which is fixed already and tried with the
> latest release 3.1.3. Unfortunately no joy and I still get the same issue.
>
> Any help would be much appreciated!
The hash table doubles each time it reaches 75% full.
A hash table for 32m items @ 16 bytes each (8 byte key, 8 byte void *
data) needs 512MB of memory.
At the next doubling (up to 64m items) it hits the array allocator limit
in utils2.c:

#define MALLOC_MAX 0x4000

void *_new_array(unsigned long num, unsigned int size, int use_calloc)
{
    if (num >= MALLOC_MAX/size)
    return NULL;
    return use_calloc ? calloc(num, size) : malloc(num * size);
}
void *_realloc_array(void *ptr, unsigned int size, size_t num)
{
    if (num >= MALLOC_MAX/size)
    return NULL;
    if (!ptr)
    return malloc(size * num);
    return realloc(ptr, size * num);
}

No single array allocation or reallocation is allowed to exceed
MALLOC_MAX (1GB).
Hence rsync can only handle up to 32m items per invocation if a hash
table is required (e.g. for tracking hardlinks when -H is specified).

HTH,
Dave



-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: rsync many processes and slow backup

[Dave Gordon via rsync]

>>> Hi all! :-)
>>>
>>> I have a small rsync script to sync my data to a usb-disk. It works
>>> fine, when I start it in console. I get 3 rsync processes (look in
>>> top) and the backup takes ~25 min. But, when I add the script in
>>> cron to start it at 1am at night it takes 7 - 9 hours and I see up to
>>> 180 processes. When I look in top I see a hight load of 60 - 80 and 40
>>> - 60 waits. Why? Can someone explain why it takes so long when it
>>> starts with cron?
>>>
>>> This is my rsync command:  rsync -azc --delete "$QUELLORDNER"
>>> "$ZIELORDNER" 
>>> This is the entry in cron (crontab -e): * 2 * * *
>>> /root/backupscript/backup.sh
>>> Data to sync: 18 Gb, 185.000 files.
>>>
>>> When I look in the log files I see errors like this: 
>>>
>>> rsync:
>>> rename "/media/usb/sicherung/var/lib/fail2ban/.fail2ban.sqlite3.JCzY1c"
>>> -> "var/lib/fail2ban/fail2ban.sqlite3": No such file or directory (2) 
>>>
>>> rsync error: some files/attrs were not transferred (see previousrsync
>>> error:
>>>
>>> some files/attrs were not transferred (see previous errors) (code 23) at
>>>
>>> main.c(1196) [sender=3.1.2]
>>>
>>> directory (2)
>>>
>>> Can you help me to solve this problem?
>>>
>>> regards,
>>> Hannes Hutmacher
>>>
Hi,

I think your crontab entry is wrong. As shown,

* 2 * * * /root/backupscript/backup.sh

it will start the script *once per minute* between 02:00 and 02:59 --
hence the 180 processes that you see! You probably meant

12 2 * * * /root/backupscript/backup.sh

(start once per day at 02:12) or some such thing.

HTH,
Dave

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Kudos and feature question

[Dave Gordon via rsync]

I think you would implement it as a new type of filter rule. similar to 'P' 
(preserve) but with a timestamp or delta-time to define what counts as 'recent' 
as well as the pattern to match for this rule to apply (which could just be a 
wildcard matching anything by default, but could also use the full 
pattern-matching capabilities if required).



Have a look at:

the 'make_backups' logic in parse_arguments(), where it adds a 'Preserve' 
pattern to match all backup files,

name_is_excluded() and its subfunctions check_filter() and rule_matches() in 
exclude.c


You'd need to:

define a new filter-type character ('R' for preserve-Recent?)

define the format of the filter rule for this type e.g. how to represent the 
time

add code to parse this new ruletype in rule_matches()

decide how your new option interacts with existing filter rules (higher or 
lower precedence, degree of specificity, etc)

add code to insert one or more rules of the new type into the filter list in 
appropriate positions


Also:

bump the protocol revision number, because an old rsync wouldn't understand the 
new ruletype

decide what to do in the case where one side is using the older protocol (e.g. 
treat it as traditional --delete, or don't delete at all?).


So not trivial, but not impossibly difficult, and at least the changes would be 
fairly localised. 



Hope this helps,

.Dave.

Sent using https://www.zoho.com/mail/




 On Fri, 22 Mar 2019 06:02:33 + Francois Payette via rsync 
 wrote 



Kudos all that maintain this awesome and enduring piece of software. Awesome 
job, many thanks. 



I’ve come across a use case that would greatly benefit form a 
—delete-older-than  argument. This would behave the same as —delete only 
sparing files dest that have a creating time less than  ago. How hard 
would this be to implement? Where would I start ? 



TIA, 

Francois 

-- 

Please use reply-all for most replies to avoid omitting the mailing list. 

To unsubscribe or change options: 
https://lists.samba.org/mailman/listinfo/rsync 

Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: [Bug 5478] rsync: writefd_unbuffered failed to write 4092 bytes [sender]: Broken pipe (32)

[Dave Gordon via rsync]

On 17/04/18 17:47, just subscribed for rsync-qa from bugzilla via rsync
wrote:
> https://bugzilla.samba.org/show_bug.cgi?id=5478
> 
> --- Comment #34 from David Nelson  ---
> FYI. Although when rsync ver. 3.0.9 is called in Ubuntu 12.04LTS to "push"
> files to the server, e.g.,
> 
> rsync / server::Backups/ 
> 
> it fails with the error:
> 
> rsync error: error in rsync protocol data stream (code 12) at io.c(441)
> [sender=3.0.9 [NB server rsync version is 3.1.0 running in Ubuntu 14.04LTS]
> 
> However, curiously, when issued as a "pull" from the server as:
> 
> rsync client::Sharetobackup//Backups/
> 
> it succeeds.
> 
> Furthermore, pushes from the client work when issued one-letter-as-a-time;
> e.g.,
> 
> for i in {A..Z}; do \
> rsync /${i}* server::Backups/ \
> done
> 
> I discovered this while trying to isolate which, if any, of the files were
> causing it to choke. Turns out none of them were, but identifying them all 
> with
> a wildcard * was.

Hi,

did you mean to add this comment to Bug 5478, which had been closed for
~5 years? It looks like it should belong to some other (more recently
active) bug - maybe 2957, 12732, or 13109?

.Dave.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: [Bug 13364] rsyncd clips trims relative symlinks outside of source tree

[Dave Gordon via rsync]

On 04/04/18 20:52, just subscribed for rsync-qa from bugzilla via rsync
wrote:
> https://bugzilla.samba.org/show_bug.cgi?id=13364
> 
> --- Comment #3 from Chris Severance  ---
>> enable munge-symlinks. That way the client will get back the same 
>> out-of-tree symlink as it started with
> 
> This is a lousy option for backups. The only way to get my original links back
> is to pull the restore through rsync. Restoring directly from the rsyncd 
> server
> will copy the munged links.

It's a very sensible option for *backups* i.e. where one host holds a
*backup* copy of the contents of another host's filesystem, but does not
itself use or interpret those contents.

Another useful option for a genuine backup server is --fake-super, so
the user-ids and permissions on the two systems don't have to be
correlated, and a non-root backup daemon can back up files that are
owned by any user. But again, you have to use rsync to reverse the effect.

>> Unless you want the symlinks to be usable on the server
> 
> This is exactly what is required. It's not a server at all. It's two clients
> both of which must have the same usable tree, one of which runs rsyncd to
> accept updates from the other.

So the problem is that you're trying to implement a symmetric p2p
operation using an explicitly asymmetric client-daemon (server) mode.
If you use the non-daemon mode you can initiate the operation from
either peer, and there are no limitations on the targets of symlinks
(with the right choice of options).

Why do you think it's necessary to use the daemon mode?

> I tried enabling chroot and the leading path was still clipped client->server.
> 
>> There are tricky ways to work around this
> 
> This is what I'm looking for. There should be no security for --links since
> copying links can never reach outside the server tree. --copy-links and
> --copy-unsafe-links could reach outside the tree so need to be limited whether
> or not the unsafe link was from the client.

Huh? If you allow a client to upload an unmunged symlink to (say)
/etc/passwd into a r/w directory on the server, and then download it
with the --copy-links option, the client gets a copy of the server's
real /etc/passwd, even though that file doesn't lie under the path=
parameter in the daemon config file. That's a fairly big security hole
if one's not *very* careful about setting appropriately limited uid/gid
mappings in the config -- and if you do that, then you can't back up
files with arbitrary ownership.

> I can build the links on both clients so --safe-links could work but I need a
> way to silence the warnings out of the -v listing.
> 
> Shortening the rsyncd "path=" so that the links become inside the tree could
> work but rsync has no usable way to specify only one directory without causing
> the links to be considered outside outside the tree.
> 
> cd baz2; rsync ./ rsync://.../baz1/ # original case
> 
> rsync bar2/ rsync://.../root/bar1/ # shortened path=
> 
> Links going to bar1 accessible by /root/ are considered outside of the bar1
> tree and clipped.

Create a dummy bar1/ on the client and include it in the files being
uploaded?

.D.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: rsync time machine backup permissions

[Dave Gordon via rsync]

On 03/04/18 18:08, Michael wrote:
> On 2018-04-03, at 4:05 AM, Dave Gordon via rsync <rsync@lists.samba.org> 
> wrote:
> 
>> On 20/03/18 05:44, Andre Althoff via rsync wrote:
>>> That doesn’t work too. :-(
>>>
>>> Last login: Mon Mar 19 19:18:16 on console
>>> iMac:~ andre$ mount
>>> /dev/disk0s2 on / (hfs, local, journaled)
>>> devfs on /dev (devfs, local, nobrowse)
>>> map -hosts on /net (autofs, nosuid, automounted, nobrowse)
>>> map auto_home on /home (autofs, automounted, nobrowse)
>>> /dev/disk2 on /Volumes/G-DRIVE Thunderbolt 3 (hfs, local, nodev, nosuid, 
>>> journaled, noowners)
>>
>> Maybe the "noowners" is the problem?
>> Try remounting the drive without this option?
>>
>> .Dave.
>
> Time Machine will enable ownership on the drive the first time it
> starts up.
>
> The first thing it does when it creates the backup directory is to
> enable ownership on the drive. I've seen this happen repeatedly (it's
> actually the easiest way I know of to enable ownership on drive).

But Andre is not using Time Machine on this drive, and "noowners" here
is an attribute of the mount, not the device. It's supposed to make the
filesystem *ignore* the actual ownership of files on the drive and treat
the contents as though they all belonged to the user; but maybe it also
disallows attempts to actually set ownership (because it would be
confusing?).

So remounting it without this option would definitely be worth trying,
even if only to eliminate it as a source of confusion.

.Dave.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: rsync time machine backup permissions

[Dave Gordon via rsync]

On 20/03/18 05:51, Michael via rsync wrote:
> What is the order that rsync uses to set permissions?
> 
> Time Machine directories have ACL permissions that basically prohibit making 
> any changes of any kind. In order to make a backup of the directory, you 
> would need to set those permissions after copying everything in the 
> subdirectories.
> 
> Is rsync smart enough to do it in that order?

Yes.

The precise sequence depends on lots of (combinations of) options, but
in many cases rsync creates directories with permissions 0700 (u=rwx),
then fills in the contents, then sets xattrs, timestamps and
permissions/acls to the correct values after all transfers are done.

.Dave.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: rsync time machine backup permissions

[Dave Gordon via rsync]

On 20/03/18 05:44, Andre Althoff via rsync wrote:
> That doesn’t work too. :-(
> 
> Last login: Mon Mar 19 19:18:16 on console
> iMac:~ andre$ mount
> /dev/disk0s2 on / (hfs, local, journaled)
> devfs on /dev (devfs, local, nobrowse)
> map -hosts on /net (autofs, nosuid, automounted, nobrowse)
> map auto_home on /home (autofs, automounted, nobrowse)
> /dev/disk2 on /Volumes/G-DRIVE Thunderbolt 3 (hfs, local, nodev, nosuid, 
> journaled, noowners)

Maybe the "noowners" is the problem?
Try remounting the drive without this option?

.Dave.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: rsync to my external eSATA HD is crashing/freezing my system...

[Dave Gordon via rsync]

On 25/03/18 15:32, Morgan Read via rsync wrote:
> On 19/03/18 14:01, Morgan Read wrote:
>> Hello list
>>
>> I've been running the following command, first in fc20 and then now
>> (since the beginning of March) in fc26:
>> now=$(date +"%Y%m%d-%H%M"); sudo rsync -ahuAESX -vi /home/
>> /run/media/readlegal/Backup/home >
>> /run/media/readlegal/Backup/rsync-changes_$now
>>
>> Since the move to fc26, this command has caused the complete
>> freeze/crash of the system.  I tried it under multi-user non-graphic
>> mode in case it was something to do with new graphics systems (don't
>> know why).  The output of the above always stops at:
>> sending incremental file list
>> .d..t.. Music/FLACs/Various_Artists/Temple_Sampler/
>>  >f+
>> Music/FLACs/Various_Artists/Temple_Sampler/13-brian_mcneill-the_butterfly_chain.flac
>>
>>
>> (total 183 bytes file size, always)
>>
>> By complete freeze/crash I mean:
>> * hard-drive light indicates spinning, but no noise (activity)
>> * unable to ssh in
>> * unable to ping
>> * in multi-user text, I'm first able to switch to another login
>> console, but then unable to progress past the login password; after
>> switching to other consoles, the original login screen attempt has
>> gone blank other than a blinking cursor top left
>> * in graphic mode, there's no (inter)activity whatsoever possible -
>> though screen has desktop on it
>> * the only apparent solution is a hard reset
>>
>> The external drive is a WD 750GB hard-drive in a StarTech.com external
>> hard-drive caddy connected via eSATA cable to an old Dell Vostro 3500.
>>
>> Any help or suggestions debugging this would be really appreciated.
>>
>> Many thanks
>> Morgan.

If the problem arrived with the upgrade to fc26, it could be a driver
issue. There may be some newly enabled driver feature that breaks your
hardware. For example, some external USB drives (e.g. Seagate Backup+
Hub devices) don't properly support UAS, so when that became the default
in the kernel those drives started misbehaving. Perhaps something
similar has happened to eSATA?

.Dave.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: file contents cause rsync to fail (with certains args and dir structure)

[Dave Gordon via rsync]

Problem was introduced with this commit:



commit f3873b3d88b61167b106e7b9227a20147f8f6197

Author: Wayne Davison way...@samba.org

Date:   Mon Oct 10 11:49:50 2016 -0700



Support --sparse combined with --preallocate or --inplace.

   

The new code tries to punch holes in the destination file using newer

Linux fallocate features. It also supports a --whole-file + --sparse +

--inplace copy on any filesystem by truncating the destination file.



.Dave.



Sent using Zoho Mail






 On Sun, 04 Mar 2018 23:17:23 +0100 Dave Gordon via rsync 
rsync@lists.samba.org wrote 




Quite strange at first sight that the failure should depend on the files 
containing NULs!

But I've reproduced it on both Ubuntu and OpenSUSE with d73762e "Preparing for 
release of 3.1.3".

The problem remains even if you drop the --checksum or --delay-updates options 
from the command line, but goes away if you don't use both "--sparse" and 
"--preallocate" together.

So it looks like a bad interaction of these options, probably with the sparse 
handling being affected by the NULs in the files.



HTH,

.Dave.



Sent using Zoho Mail






 On Sun, 04 Mar 2018 14:57:24 +0100 xftroxgpx via rsync 
rsync@lists.samba.org wrote 












-- 

Please use reply-all for most replies to avoid omitting the mailing list. 

To unsubscribe or change options: 
https://lists.samba.org/mailman/listinfo/rsync 

Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html


script to reproduce: 



#!/bin/bash 



#tested to fail as below: ArchLinux's rsync-3.1.3-1-x86_64.pkg.tar.xz 

#tested to fail as below: ArchLinux's rsync-3.1.3pre1-1-x86_64.pkg.tar.xz 

#tested to work ok : ArchLinux's rsync-3.1.2-8-x86_64.pkg.tar.xz 



if test "$1" == "clean"; then 

rm -vrf destdir sourcedir sourcedir2 sourcedir3 

exit 0 

fi 



echo '!! test 1:' 



mkdir -p destdir 

mkdir -p sourcedir/a 

#one \0 followed by a non-\0 (so, using a space) required: 

echo -ne '\0 '  sourcedir/a/b 

#non zero size file required: 

echo -ne 'c'  sourcedir/c 

echo 'sourcedir' /tmp/filesfrom.lst.tmp 

rsync --recursive --perms --checksum --delay-updates --numeric-ids 
--preallocate --sparse --files-from=/tmp/filesfrom.lst.tmp -- ./ ./destdir/ 

#rsync: write failed on 
"/home/xftroxgpx/sandbox/rsync/nsfod_issues/try2/destdir/sourcedir/a/b": No 
such file or directory (2) 

#rsync error: error in file IO (code 11) at receiver.c(374) [receiver=3.1.3] 



# ^ this happens first and any subsequent times! 



echo '!! test 2:' 



mkdir -p sourcedir2/a 

#one \0 followed by a non-\0 (so, using an M) required: 

echo -ne '\0M'  sourcedir2/a/b 

#one \0 followed by a non-\0 (so, using an M) required: 

echo -ne '\0M'  sourcedir2/c 



#in order to see this error: (for file 'c') 



#non-zero file size required and it must be prefixed by '.' aka dot 

#echo -ne '1'  sourcedir2/.d 

#XXX: ^ (un)comment, don't forget to ./go clean afterwards, then ./go 



#otherwise, the error is for file "a/b" 



echo 'sourcedir2' /tmp/filesfrom.lst.tmp 

rsync --recursive --perms --checksum --delay-updates --numeric-ids 
--preallocate --sparse --files-from=/tmp/filesfrom.lst.tmp -- ./ ./destdir/ 

#rsync: write failed on 
"/home/xftroxgpx/sandbox/rsync/nsfod_issues/try2/destdir/sourcedir2/a/b": No 
such file or directory (2) 

#rsync error: error in file IO (code 11) at receiver.c(374) 
[receiver=3.1.3pre1] 



echo '!! test 3:' #same as 2 but an extra file '.d' exists! 



mkdir -p sourcedir3/a 

#one \0 followed by a non-\0 (so, using an M) required: 

echo -ne '\0M'  sourcedir3/a/b 

#one \0 followed by a non-\0 (so, using an M) required: 

echo -ne '\0M'  sourcedir3/c 



#non-zero file size required and it must be prefixed by '.' aka dot 

echo -ne '1'  sourcedir3/.d 

echo 'sourcedir3' /tmp/filesfrom.lst.tmp 

rsync --recursive --perms --checksum --delay-updates --numeric-ids 
--preallocate --sparse --files-from=/tmp/filesfrom.lst.tmp -- ./ ./destdir/ 

#rsync: write failed on 
"/home/xftroxgpx/sandbox/rsync/nsfod_issues/try2/destdir/sourcedir2/c": No such 
file or directory (2) 

#rsync error: error in file IO (code 11) at receiver.c(374) [receiver=3.1.3] 



A pristine copy of this script can be found here: 
https://github.com/xftroxgpx/a3/blob/37ebff3e0fe9d294aeec899a082dc2c51c486eb4/system/Z575/OSes/3archlinux/on_baremetal/filesystem_now/archlinux/home/xftroxgpx/sandbox/rsync/nsfod_issues/try2/go
 



Just run ./go to start all 3 tests. 



All 3 tests should fail with: 

ArchLinux's rsync-3.1.3-1-x86_64.pkg.tar.xz 

ArchLinux's rsync-3.1.3pre1-1-x86_64.pkg.tar.xz 



All 3 tests will succeed with ArchLinux's rsync-3.1.2-8-x86_64.pkg.tar.xz 

(aka rsync version 3.1.2 protocol version 31) 





Cheers! 



​Sent with ProtonMail Secure Email.​ 







-- 

Please use reply-all for most replies to avoid omitting the mailing list. 

To unsubscribe or ch

Re: file contents cause rsync to fail (with certains args and dir structure)

[Dave Gordon via rsync]

Quite strange at first sight that the failure should depend on the files 
containing NULs!

But I've reproduced it on both Ubuntu and OpenSUSE with d73762e "Preparing for 
release of 3.1.3".

The problem remains even if you drop the --checksum or --delay-updates options 
from the command line, but goes away if you don't use both "--sparse" and 
"--preallocate" together.

So it looks like a bad interaction of these options, probably with the sparse 
handling being affected by the NULs in the files.



HTH,

.Dave.



Sent using Zoho Mail






 On Sun, 04 Mar 2018 14:57:24 +0100 xftroxgpx via rsync 
rsync@lists.samba.org wrote 




script to reproduce: 

 

#!/bin/bash 

 

#tested to fail as below: ArchLinux's rsync-3.1.3-1-x86_64.pkg.tar.xz 

#tested to fail as below: ArchLinux's rsync-3.1.3pre1-1-x86_64.pkg.tar.xz 

#tested to work ok : ArchLinux's rsync-3.1.2-8-x86_64.pkg.tar.xz 

 

if test "$1" == "clean"; then 

 rm -vrf destdir sourcedir sourcedir2 sourcedir3 

 exit 0 

fi 

 

echo '!! test 1:' 

 

mkdir -p destdir 

mkdir -p sourcedir/a 

#one \0 followed by a non-\0 (so, using a space) required: 

echo -ne '\0 '  sourcedir/a/b 

#non zero size file required: 

echo -ne 'c'  sourcedir/c 

echo 'sourcedir' /tmp/filesfrom.lst.tmp 

rsync --recursive --perms --checksum --delay-updates --numeric-ids 
--preallocate --sparse --files-from=/tmp/filesfrom.lst.tmp -- ./ ./destdir/ 

#rsync: write failed on 
"/home/xftroxgpx/sandbox/rsync/nsfod_issues/try2/destdir/sourcedir/a/b": No 
such file or directory (2) 

#rsync error: error in file IO (code 11) at receiver.c(374) [receiver=3.1.3] 

 

# ^ this happens first and any subsequent times! 

 

echo '!! test 2:' 

 

mkdir -p sourcedir2/a 

#one \0 followed by a non-\0 (so, using an M) required: 

echo -ne '\0M'  sourcedir2/a/b 

#one \0 followed by a non-\0 (so, using an M) required: 

echo -ne '\0M'  sourcedir2/c 

 

#in order to see this error: (for file 'c') 

 

#non-zero file size required and it must be prefixed by '.' aka dot 

#echo -ne '1'  sourcedir2/.d 

#XXX: ^ (un)comment, don't forget to ./go clean afterwards, then ./go 

 

#otherwise, the error is for file "a/b" 

 

echo 'sourcedir2' /tmp/filesfrom.lst.tmp 

rsync --recursive --perms --checksum --delay-updates --numeric-ids 
--preallocate --sparse --files-from=/tmp/filesfrom.lst.tmp -- ./ ./destdir/ 

#rsync: write failed on 
"/home/xftroxgpx/sandbox/rsync/nsfod_issues/try2/destdir/sourcedir2/a/b": No 
such file or directory (2) 

#rsync error: error in file IO (code 11) at receiver.c(374) 
[receiver=3.1.3pre1] 

 

echo '!! test 3:' #same as 2 but an extra file '.d' exists! 

 

mkdir -p sourcedir3/a 

#one \0 followed by a non-\0 (so, using an M) required: 

echo -ne '\0M'  sourcedir3/a/b 

#one \0 followed by a non-\0 (so, using an M) required: 

echo -ne '\0M'  sourcedir3/c 

 

#non-zero file size required and it must be prefixed by '.' aka dot 

echo -ne '1'  sourcedir3/.d 

echo 'sourcedir3' /tmp/filesfrom.lst.tmp 

rsync --recursive --perms --checksum --delay-updates --numeric-ids 
--preallocate --sparse --files-from=/tmp/filesfrom.lst.tmp -- ./ ./destdir/ 

#rsync: write failed on 
"/home/xftroxgpx/sandbox/rsync/nsfod_issues/try2/destdir/sourcedir2/c": No such 
file or directory (2) 

#rsync error: error in file IO (code 11) at receiver.c(374) [receiver=3.1.3] 

 

A pristine copy of this script can be found here: 
https://github.com/xftroxgpx/a3/blob/37ebff3e0fe9d294aeec899a082dc2c51c486eb4/system/Z575/OSes/3archlinux/on_baremetal/filesystem_now/archlinux/home/xftroxgpx/sandbox/rsync/nsfod_issues/try2/go
 

 

Just run ./go to start all 3 tests. 

 

All 3 tests should fail with: 

ArchLinux's rsync-3.1.3-1-x86_64.pkg.tar.xz 

ArchLinux's rsync-3.1.3pre1-1-x86_64.pkg.tar.xz 

 

All 3 tests will succeed with ArchLinux's rsync-3.1.2-8-x86_64.pkg.tar.xz 

(aka rsync version 3.1.2 protocol version 31) 

 

 

Cheers! 

 

​Sent with ProtonMail Secure Email.​ 

 

 

 

-- 

Please use reply-all for most replies to avoid omitting the mailing list. 

To unsubscribe or change options: 
https://lists.samba.org/mailman/listinfo/rsync 

Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html 






-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Unfortunate results from fake-super

[Dave Gordon via rsync]

On 06/02/18 19:03, Dave Gordon via rsync wrote:
[:snip:]
> 
> The other part of this problem is that it doesn't at present seem
> possible to satisfy all of three individually reasonable requirements of
> a backup system at the same time:
> 
> 1.The backup receiver (daemon) need not run as root.
> 2.The backup daemon should preserve all of the client's metadata.
> 3.The backup daemon should have control over modes, ownership, etc
>   of the backup files.
> 
> 1 & 2 can be satisfied today with the use of --fake-super, but even
> apart from the issue with 0777 symlinks, the modes of the backup files
> are based on those of the originals .. unless you use chmod.
> 
> 1 & 3 can be satisfied together by using --fake-super with --chmod on
> the receiving side or incoming-chmod in the daemon config. But this
> actually loses information as it affects not only the modes of the
> backup files, but also the state saved in user.rsync.%stat.
> 
> So my proposal would be for the receiving-side chmod to be applied (in
> fake mode) *after* user.rsync.%stat has been saved, and likewise after
> the conversion of symlinks (et al.) to plain files.
> 
> This would allow a daemon configuration containing both fake-super and
> an absolute setting for incoming-chmod to fulfil all three of the above.
> 
> The logical flow for a push-to-fake-super-daemon would then be:
> 1.client sends filespecs, applying any local --chmod on the way
> 2.daemon receives filespecs, does *not* tweak_mode at this stage
> 3.... data transfer as needed ...
> 4.daemon sets backup file attributes
> 4a.   in fake mode, daemon saves user.rsync.%stat, then applies
>   tweak_mode() to the local file. Daemon modes take precedence
>   as expected.
> 4b.   in non-fake mode, the daemon just applies the deferred
>   tweak_mode(). This may lose information, as at present
>   (because that's *also* useful).
> 
> The reverse flow (pull-from-fake-super-daemon) is:
> 1.daemon sends filespecs, getting modes from user.rsync.%stat
>   (daemon would apply outgoing-chmod here, but I don't think it
>   would be set in this configuration).
> 2.client receives filespecs, does *not* tweak_mode at this stage
> 3.... date transfer as needed ...
> 4.client sets local file attributes
> 4b.   (non-fake-mode) client applies any local --chmod
> 
> Any client-local --chmod is applied later in this flow than at present,
> but that should make no difference. Note that the client didn't need to
> know (and shouldn't be able to tell?) whether the daemon was super or
> just faking it :)
> 
> .Dave.

One more point for consideration: at present the set_stat_xattr()
creates the user.rsync.%stat xattr iff it would contain information
different from the state of the actual file. Thus, it's always created
for symlinks, devices, etc because they're stored as plain files; but
for plain files and directories, the xattr is created only if there's
some way in which the logical and actual objects differ (uid, gid,
permissions).

Presumably this is for reasons of economy, but it seems a little odd;
and there are (perhaps contrived) scenarios where this might lead to
confusion, information loss, and/or security breaches. For example:

Client A is backed up onto a non-root fake-super server B, which stores
all backups under its own uid/gid but leaves permissions unchanged. Then
every backup file will be tagged with a user.rsync.%stat xattr, *except*
for those owned by a user on A whose numerical uid/gid happen to match
those of the backup daemon on B. If the backups are now copied by an
administrator to server C, where the uid/gid of the backup daemon are
different from those on B, naturally the admin will adjust ownership
accordingly (c.f. rsync copy-ownership-by-username). Finally, if client
A is restored from the backups on C rather than B, one specific user's
files will be recreated with the wrong uid. This would be quite
baffling, especially as the local administrator on A might not know
anything about what the (remote) administrator of servers B & C has been
doing!

To avoid this and similar inconsistencies, I would like to completely
decouple the representation of the logical uid/gid/mode of the stored
object from the real uid/gid/mode of the filesystem object representing
it. This would simply mean removing the tests in set_stat_xattr() so
that the xattr is *always* created for every object stored in fake-super
mode. Since the purpose of fake-super mode is to preserve origin
filesystem metadata unchanged whether or not the target filesystem can
represent it, it seems odd to have the extra code that creates this
corner case. Without it, the code would be both simpler and easier to
explain :)

.Dave.


-- 
Please use reply-all for most replies to 

Re: Unfortunate results from fake-super

[Dave Gordon via rsync]

On 05/02/18 23:03, Dave Gordon via rsync wrote:
> On 05/02/18 05:53, Wayne Davison wrote:
>> On Sat, Feb 3, 2018 at 5:20 AM, Dave Gordon via rsync
>> <rsync@lists.samba.org <mailto:rsync@lists.samba.org>> wrote:
>>
>> [...fake-super symlink saved as a file...]
>>
>> This results in the copy being world-writable.
>>
>> Indeed. The file initially gets created as a mode-600 file, but the code
>> later tweaks the permissions to match the symlink, which is (as you
>> note) a bad thing.
>>
>> My first reaction is to change the code in set_stat_xattr()
>> (in xattrs.c) from:
>>
>>        if (fst.st_mode != mode)
>>                do_chmod(fname, mode);
>>
>> to:
>>
>>        if (fst.st_mode != mode && !S_ISLNK(file->mode))
>>                do_chmod(fname, mode);
>>
>> ..wayne.. 
> 
> That's certainly an improvement; from the safety point of view, leaving
> it as 0600 is a lot better than leaving it as 0777. I'm currently
> investigating a slightly more extensive fix to allow more control over
> how fake-symlink files end up, also to make fake-super work better with
> incoming-chmod for the daemon case.
> 
> .Dave.

The other part of this problem is that it doesn't at present seem
possible to satisfy all of three individually reasonable requirements of
a backup system at the same time:

1.  The backup receiver (daemon) need not run as root.
2.  The backup daemon should preserve all of the client's metadata.
3.  The backup daemon should have control over modes, ownership, etc
of the backup files.

1 & 2 can be satisfied today with the use of --fake-super, but even
apart from the issue with 0777 symlinks, the modes of the backup files
are based on those of the originals .. unless you use chmod.

1 & 3 can be satisfied together by using --fake-super with --chmod on
the receiving side or incoming-chmod in the daemon config. But this
actually loses information as it affects not only the modes of the
backup files, but also the state saved in user.rsync.%stat.

So my proposal would be for the receiving-side chmod to be applied (in
fake mode) *after* user.rsync.%stat has been saved, and likewise after
the conversion of symlinks (et al.) to plain files.

This would allow a daemon configuration containing both fake-super and
an absolute setting for incoming-chmod to fulfil all three of the above.

The logical flow for a push-to-fake-super-daemon would then be:
1.  client sends filespecs, applying any local --chmod on the way
2.  daemon receives filespecs, does *not* tweak_mode at this stage
3.  ... data transfer as needed ...
4.  daemon sets backup file attributes
4a. in fake mode, daemon saves user.rsync.%stat, then applies
tweak_mode() to the local file. Daemon modes take precedence
as expected.
4b. in non-fake mode, the daemon just applies the deferred
tweak_mode(). This may lose information, as at present
(because that's *also* useful).

The reverse flow (pull-from-fake-super-daemon) is:
1.  daemon sends filespecs, getting modes from user.rsync.%stat
(daemon would apply outgoing-chmod here, but I don't think it
would be set in this configuration).
2.  client receives filespecs, does *not* tweak_mode at this stage
3.  ... date transfer as needed ...
4.  client sets local file attributes
4b. (non-fake-mode) client applies any local --chmod

Any client-local --chmod is applied later in this flow than at present,
but that should make no difference. Note that the client didn't need to
know (and shouldn't be able to tell?) whether the daemon was super or
just faking it :)

.Dave.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Unfortunate results from fake-super

[Dave Gordon via rsync]

On 05/02/18 05:53, Wayne Davison wrote:
> On Sat, Feb 3, 2018 at 5:20 AM, Dave Gordon via rsync
> <rsync@lists.samba.org <mailto:rsync@lists.samba.org>> wrote:
> 
> [...fake-super symlink saved as a file...]
> 
> This results in the copy being world-writable.
> 
> Indeed. The file initially gets created as a mode-600 file, but the code
> later tweaks the permissions to match the symlink, which is (as you
> note) a bad thing.
> 
> My first reaction is to change the code in set_stat_xattr()
> (in xattrs.c) from:
> 
>        if (fst.st_mode != mode)
>                do_chmod(fname, mode);
> 
> to:
> 
>        if (fst.st_mode != mode && !S_ISLNK(file->mode))
>                do_chmod(fname, mode);
> 
> ..wayne.. 

That's certainly an improvement; from the safety point of view, leaving
it as 0600 is a lot better than leaving it as 0777. I'm currently
investigating a slightly more extensive fix to allow more control over
how fake-symlink files end up, also to make fake-super work better with
incoming-chmod for the daemon case.

.Dave.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Re: Unfortunate results from fake-super

[Dave Gordon via rsync]

On 03/02/18 15:52, Dave Gordon via rsync wrote:
> On 03/02/18 13:20, Dave Gordon via rsync wrote:
>> When using fake-super mode in an rsync receiver, anything that's neither a
>> file nor a directory (e.g. devices, symlinks, etc) is converted into a file,
>> and properties such as original ownership, filetype, and permissions are
>> stored in a specific extended attribute.
>>
>> In the case of a symlink, the contents of the link are stored in a plain
>> file. The original mode of the symlink is normally irrelevant, because
>> (Linux) hosts ignore a symlink's mode and use that of the target instead.
>> But in fake-super mode, the original mode of the link itself (usually
>> 0120777) is used to set the permissions on the receiver's plain-file copy.
>>
>> This results in the copy being world-writable. If this plain file is altered
>> and then transferred back to the origin, the resulting symlink can point to
>> an arbitrary path, which leads to potential security issues.
>>
>> Example:
>>
>> This was first observed in version 3.1.1 on kubuntu, but is still the same
>> in version 3.1.3 as of 28 Jan 2018.
>> See also  Storing-ownership-device-nodes-without-root
>> <http://samba.2283325.n4.nabble.com/Storing-ownership-device-nodes-without-root-td2503256.html#a2503261>
>>   
>>
>> .Dave.
>>
>> --
>> Sent from: http://samba.2283325.n4.nabble.com/Samba-rsync-f2500462.html
>>
> 
> Hmm, the forum seems to have dropped the example (which was in 'raw'
> tags to preserve the formatting). Oh well, here it is ...
> 
> Example:
> 
> As regular user 'dg':
> dg$ mkdir src
> dg$ touch src/foo
> dg$ chmod 444 src/foo
> dg$ ln -s foo src/bar
> 
> Then as trusted (but unprivileged) user 'backup':
> backup$ id -a
> uid=1000(backup) gid=1000(backup) groups=1000(backup),100(users)
> backup$ umask
> 0022
> backup$ rsync -av src/ dst-nonsuper/
> backup$ rsync -av --fake-super src/ dst-fake-super/
> 
> Now as (untrusted) user 'guest':
> guest$ id -a
> uid=(guest) gid=(guest) groups=(guest)
> guest$ echo -n '/etc/shadow' > dst-nonsuper/bar
> bash: dst-nonsuper/bar: Permission denied
> guest$ echo -n '/etc/secret' > dst-fake-super/bar # allowed!!
> 
> And finally, as user 'dg', restore from the fake-super backup:
> dg$ rsync -av --fake-super -M--super dst-fake-super/ recovered/
> dg$ ls -laR */
> ./src:
> total 8
> drwxr-xr-x 2 dg users 4096 Feb  3 11:59 .
> drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
> lrwxrwxrwx 1 dg users3 Feb  3 11:59 bar -> foo
> -r--r--r-- 1 dg users0 Feb  3 11:59 foo
> 
> ./dst-nonsuper:
> total 8
> drwxr-xr-x 2 backup users 4096 Feb  3 11:59 .
> drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
> lrwxrwxrwx 1 backup users3 Feb  3 11:59 bar -> foo
> -r--r--r-- 1 backup users0 Feb  3 11:59 foo
> 
> ./dst-fake-super:
> total 12
> drwxr-xr-x 2 backup backup 4096 Feb  3 11:59 .
> drwxrwxr-x 6 dg users  4096 Feb  3 13:00 ..
> -rwxrwxrwx 1 backup backup   11 Feb  3 12:51 bar
> -rw-r--r-- 1 backup backup0 Feb  3 11:59 foo
> 
> ./recovered:
> total 8
> drwxr-xr-x 2 dg users 4096 Feb  3 11:59 .
> drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
> lrwxrwxrwx 1 dg users   11 Feb  3 12:51 bar -> /etc/secret
> -r--r--r-- 1 dg users0 Feb  3 11:59 foo
> 
> dg$ getfattr -d -R */
> 
> # file: dst-fake-super
> user.rsync.%stat="40755 0,0 32768:100"
> 
> # file: dst-fake-super/bar
> user.rsync.%stat="120777 0,0 32768:100"
> 
> # file: dst-fake-super/foo
> user.rsync.%stat="100444 0,0 32768:100"
> 
> .Dave.

In an attempt to avoid the above problem, one might try using a --chmod
option to ensure that the destination files are not world-writable (here
we use a rather silly chmod, just to make it more obvious what is -- and
isn't -- affected):


backup$ rsync -av src/ dst-nonsuper/
backup$ rsync -av --chmod=D0700,Fu=rx,g=,o=x src/ dst-chmod-501/
backup$ rsync -av --fake-super --chmod=D0700,Fu=rx,g=,o=x src/
dst-fake-chmod-501/
backup$ getfattr -d -R .
# file: dst-fake-chmod-501
user.rsync.%stat="40701 0,0 32768:100"

# file: dst-fake-chmod-501/bar
user.rsync.%stat="120777 0,0 32768:100"

# file: dst-fake-chmod-501/foo
user.rsync.%stat="100501 0,0 32768:100"

backup$ ll -R */
./src:
total 8
drwxr-xr-x 2 dg users 4096 Feb  3 11:59 ./
drwxrwxr-x 6 dg users 4096 Feb  3 17:16 ../
lrwxrwxrwx 1 dg users3 Feb  3 11:59 bar -> foo
-r--r--r-- 1 dg users0 Feb  3 11:59 foo

./dst-nonsuper:
total 8
drwxr-xr-x 2 backup users 4096 Feb  3 11:59 ./
drwxrwxr-x 6 dg users 4096 Feb  3 17:16 ../
lrwxrwxrwx 1 backup users3 Feb  3 11:59 bar -> foo

Re: Unfortunate results from fake-super

[Dave Gordon via rsync]

On 03/02/18 13:20, Dave Gordon via rsync wrote:
> When using fake-super mode in an rsync receiver, anything that's neither a
> file nor a directory (e.g. devices, symlinks, etc) is converted into a file,
> and properties such as original ownership, filetype, and permissions are
> stored in a specific extended attribute.
> 
> In the case of a symlink, the contents of the link are stored in a plain
> file. The original mode of the symlink is normally irrelevant, because
> (Linux) hosts ignore a symlink's mode and use that of the target instead.
> But in fake-super mode, the original mode of the link itself (usually
> 0120777) is used to set the permissions on the receiver's plain-file copy.
> 
> This results in the copy being world-writable. If this plain file is altered
> and then transferred back to the origin, the resulting symlink can point to
> an arbitrary path, which leads to potential security issues.
> 
> Example:
> 
> This was first observed in version 3.1.1 on kubuntu, but is still the same
> in version 3.1.3 as of 28 Jan 2018.
> See also  Storing-ownership-device-nodes-without-root
> <http://samba.2283325.n4.nabble.com/Storing-ownership-device-nodes-without-root-td2503256.html#a2503261>
>   
> 
> .Dave.
> 
> --
> Sent from: http://samba.2283325.n4.nabble.com/Samba-rsync-f2500462.html
> 

Hmm, the forum seems to have dropped the example (which was in 'raw'
tags to preserve the formatting). Oh well, here it is ...

Example:

As regular user 'dg':
dg$ mkdir src
dg$ touch src/foo
dg$ chmod 444 src/foo
dg$ ln -s foo src/bar

Then as trusted (but unprivileged) user 'backup':
backup$ id -a
uid=1000(backup) gid=1000(backup) groups=1000(backup),100(users)
backup$ umask
0022
backup$ rsync -av src/ dst-nonsuper/
backup$ rsync -av --fake-super src/ dst-fake-super/

Now as (untrusted) user 'guest':
guest$ id -a
uid=(guest) gid=(guest) groups=(guest)
guest$ echo -n '/etc/shadow' > dst-nonsuper/bar
bash: dst-nonsuper/bar: Permission denied
guest$ echo -n '/etc/secret' > dst-fake-super/bar # allowed!!

And finally, as user 'dg', restore from the fake-super backup:
dg$ rsync -av --fake-super -M--super dst-fake-super/ recovered/
dg$ ls -laR */
./src:
total 8
drwxr-xr-x 2 dg users 4096 Feb  3 11:59 .
drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
lrwxrwxrwx 1 dg users3 Feb  3 11:59 bar -> foo
-r--r--r-- 1 dg users0 Feb  3 11:59 foo

./dst-nonsuper:
total 8
drwxr-xr-x 2 backup users 4096 Feb  3 11:59 .
drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
lrwxrwxrwx 1 backup users3 Feb  3 11:59 bar -> foo
-r--r--r-- 1 backup users0 Feb  3 11:59 foo

./dst-fake-super:
total 12
drwxr-xr-x 2 backup backup 4096 Feb  3 11:59 .
drwxrwxr-x 6 dg users  4096 Feb  3 13:00 ..
-rwxrwxrwx 1 backup backup   11 Feb  3 12:51 bar
-rw-r--r-- 1 backup backup0 Feb  3 11:59 foo

./recovered:
total 8
drwxr-xr-x 2 dg users 4096 Feb  3 11:59 .
drwxrwxr-x 6 dg users 4096 Feb  3 13:00 ..
lrwxrwxrwx 1 dg users   11 Feb  3 12:51 bar -> /etc/shadow
-r--r--r-- 1 dg users0 Feb  3 11:59 foo

dg$ getfattr -d -R */

# file: dst-fake-super
user.rsync.%stat="40755 0,0 32768:100"

# file: dst-fake-super/bar
user.rsync.%stat="120777 0,0 32768:100"

# file: dst-fake-super/foo
user.rsync.%stat="100444 0,0 32768:100"

.Dave.


-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

Unfortunate results from fake-super

[Dave Gordon via rsync]

When using fake-super mode in an rsync receiver, anything that's neither a
file nor a directory (e.g. devices, symlinks, etc) is converted into a file,
and properties such as original ownership, filetype, and permissions are
stored in a specific extended attribute.

In the case of a symlink, the contents of the link are stored in a plain
file. The original mode of the symlink is normally irrelevant, because
(Linux) hosts ignore a symlink's mode and use that of the target instead.
But in fake-super mode, the original mode of the link itself (usually
0120777) is used to set the permissions on the receiver's plain-file copy.

This results in the copy being world-writable. If this plain file is altered
and then transferred back to the origin, the resulting symlink can point to
an arbitrary path, which leads to potential security issues.

Example:

This was first observed in version 3.1.1 on kubuntu, but is still the same
in version 3.1.3 as of 28 Jan 2018.
See also  Storing-ownership-device-nodes-without-root

  

.Dave.



--
Sent from: http://samba.2283325.n4.nabble.com/Samba-rsync-f2500462.html

-- 
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html