Bug 14267 - rsync produces unhelpful errors on remote copy to OS with different ACL format
Summary: rsync produces unhelpful errors on remote copy to OS with different ACL format
Status: NEW
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.3
Hardware: All All
: P5 minor (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-02-06 00:35 UTC by Stewart A.
Modified: 2020-02-06 00:35 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stewart A. 2020-02-06 00:35:59 UTC
# Issue Description
Between two systems (different OSs) both with rsync 3.1.3, copies fail with an unhelpful error when they use different ACL formats:

rsync: [sender] write error: Broken pipe (32)
rsync: connection unexpectedly closed (56591 bytes received so far) [generator]
rsync error: error in rsync protocol data stream (code 12) at io.c(820) [sender=3.1.3]

This is a nondescript error that sends the user down a rabbit hole debugging the wrong issue (are my rsync versions mismatched? why is there a protocol-level error? is my ssh connection failing? is my disk full?).

It doesn't help that by default logs or increasing sender-side verbose produces no further hints; it's only by increasing receiver-side verbosity with -M-vvv that I got to the bottom of it -- incompatible ACL systems:

recv_acl_access: "value out of range": 129a000

Once it became clear that it was an ACL issue, per the man page '-M--fake-super' fixes the issue.

# Repro steps
rsync -aAX macos-timemachine-backups-folder user@linuxhost:/path/to/dst

# Actual Results
rsync produces a bogus error about protocol failure, when in reality the protocol communication itself is just fine (receiver just has an unsupported ACL error)

# Expected Results
rsync produces a more appropriate error message, along the lines of "ACL unsupported by receiver"