rsync replaced with openrsync on macOS Sequoia
On many Unix-based operating systems, rsync is a command line tool for transferring and synchronizing files on a computer, either between storage attached directly to the computer or between another computer located elsewhere on a network. The rsync command line tool has long been included on macOS, but Apple has provided the last version of rsync 2.x (rsync 2.6.9, released in November 2006) and did not update rsync past that even though rsync 3.x was released. Why not? It has to do with the version of the GNU General Public License (GPL) open source license that rsync 2.x and 3.x were released under, with rsync 2.x being released under the GPLv2 license and rsync 3.x being released under the GPLv3 license. Without going in-depth into the background legal issues, the reason for not providing rsync 3.x is that Apple decided that while it could comply with the terms of GPLv2 license with regards to rsync 2.x, it could not comply with the terms of GPLv3 license with regards to rsync 3.x.
What this has meant for macOS is that it has been shipping with a version of rsync which was last updated in 2006. While Apple has been updating the rsync 2.6.9 command line tool it shipped with macOS as needed in response to security issues and other problems, the fact remains that Apple’s version of rsync up until macOS Sequoia was almost twenty years old and did not include any of the new features introduced in rsync versions which came after version 2.6.9.
Now with macOS Sequoia, Apple has replaced rsync 2.6.9 with openrsync, an implementation of rsync which is not using any version of the GPL open source license. Instead, openrsync is licensed under the BSD family of licenses, specifically the ISC license. The ISC license is a permissive license, which means it places minimal restrictions on on how the licensed software can be used, modified and distributed, which means Apple decided it is able to comply with the terms of the license for openrsync where it decided it could not comply with the terms of GPLv3 license with regards to rsync 3.x.
So I’ve spent a bunch of time talking about licenses. Why does this change matter? It matters in two ways:
- Apple can ship updated versions of openrsync going forward without having to be concerned as to whether or not Apple can comply with the GPL open source license for rsync.
- The openrsync command line tool is compatible with rsync, but as noted in the documentation openrsync accepts only a subset of rsync’s command line arguments.
Item number 2 is important for Mac admins because it may mean that rsync functionality that worked on older versions of macOS may not be working now on macOS Sequoia because that functionality is not available as part of the openrsync command line tool included with macOS Sequoia. For more information about what functionality is supported in the openrsync command line tool on macOS Sequoia, please see the link below:
https://manp.gs/mac/1/openrsync
As of macOS 15.4, the openrsync tool is linked to /usr/bin/rsync so you can run the the openrsync command line tool like you have been the rsync command line tool. For version information about the openrsync command line tool, run the command shown below:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| /usr/bin/rsync –version |
You should see output similar to that shown below:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| username@computername ~ % /usr/bin/rsync –version | |
| openrsync: protocol version 29 | |
| rsync version 2.6.9 compatible | |
| username@computername ~ % |
Leave a comment
Recent Comments
 | BRAD WHITE on Showing or hiding the Self Ser… |
 | rtrouton on MDM-based Software Update mana… |
 | stefanx on MDM-based Software Update mana… |
 | peteostro on MDM-based Software Update mana… |
 | John on MDM-based Software Update mana… |
Der Flounder 
The command on (both) line one(s) should read : /usr/bin/rsync –version
That’s a WordPress display issue. If you click on the Gist link, it’s correct.
Thanks for the summary Rich!
Thanks, Rich. For years we have used a custom rsync script for migrating user data between machines. Last Friday we saw the script stopping after about five seconds. Console logs showed that rsync was waking the CPU 45001 times over five seconds when the limit is 45000 wakes over 300 seconds. The script was stopping due to this violation.
The machine we were running the rsync script on was running 15.4. When we tried running it on a new machine out of the box that still had 15.1, it ran fine. Now at least I have some idea why.
Carbon Copy Cloner brings its own sophisticated Version of rsync. It is part of the demo installer. I guess to use it permanently you’d need a CCC license.
Thank you. Now I know why my backup script has suddenly stopped working. rsync now crashes with a SEGV and various other (seemingly random) problems. I will try a prior version.
Maybe take a look at these instructions : http://www.lbackup.org/developer/rsync_hfs
Thanks Rich, I didn’t realize my overnight rsync script had been failing recently. This explains what’s been happening.
The man page mentions that –log-file=logfile is a supported option, but my script was failing with:
rsync: unrecognized option `–log-file=/Users/Shared/logs/backup.log’
I’m not sure why the documentation doesn’t match the behavior – I’ll need to dig deeper. At least for now, I can omit the option and my remote backups should run successfully tonight.
Thanks!
I have been using rsync for years to backup my VMWare Fusion virtual machines (mainly because Timemachine is not well suited as you need to backup atomically, or –delay-updates, to keep them in a usable state).
Back on topic:
I had to change the destination by removing the username and set it in an environment variable. So from user@host::share to USER=user rsync …. host::share
I had the same problem. I found that changing ‘user@host::share’ to ‘rsync://user@host/share’ also works for openrsync.
From where I sit, the main “feature” of Apple’s build of openrsync is that a simple command that used to reliably succeed now fails with errors like thisAssertion failed: (offset + datasz <= fm->mapsz), function fmap_data, file fmap.c, line 358.my_script: line 12: 21634 Abort trap: 6 /usr/bin/rsync -avz Knowing Apple, they neglected to test compatibility with rsync utilities as built for other common operating systems – linux in this case.Perhaps the incompatibility is between rsync and openrsync, but I still remember when Apple “added value” to the vnc protocol, such that for a year or so Macs couldn’t be clients to anyone else’s vnc server.So this could just as well be Apple “adding value” to openrsync.
Work-around: Use rsync from Homebrew. For me it restored –log-file parameter and looks like rsync behaves just as before Apple downgraded it.
Thank you so much for this article. I’ve been scratching my head for a while as of why my backup scripts were suddenly failing…
It seems to have been fixed by Apple in Sequoia 15.6.1. It’s openrsync version 2.6.9, protocol 29 is now compatible with Ubuntu’s rsync version 3.2.7, protocol 31.
‘It’ being the failures when writing to an Ubuntu rsync server. It now syncs normally without any retries or protocol=xx specifiers on the command line.