rsync stalls in MacOS 15 Sequoia

I have several directories with thousands of files that I synchronize to my Mac using rsync. With Sequoia Apple has switched to a new rsync -- I can tell because the verbose output has changed. But this rsync has a bug that shows up on both Intel and Apple Silicon. This has been persistent across all versions of MacOS 15 to date, and on two different Macs.


In this case, I am transferring a large number of files, all of which are relatively small.


I execute the following command:


rsync -av [source] [destination]


The source is on a remote server.


The command will stall after transferring somewhere between 800 and about 1300 files. I did some testing using tee directed to wc to make counts. It always stalls between completing the download of one file and starting the next. I have experienced this hundreds of times now, and have never had an incomplete file. Prior to the Sequoia upgrade, a single rsync command would get all files (or all newer files) in the source with a single command. Now, it takes about 15-25 executions to get all the files (about 27,000 files), and by the time I get them all, it is time to start again because they are updated regularly. The transfer will stall forever (until killed by control-C), so it cannot be done in the background -- a human must be present to kill and restart.


Removing the -v command does not change things, except that you can't tell that the process has stalled other than by looking at the clock. The -v at least lets you see that the output has stopped.


This really needs to be fixed. A process that I used to be able to have my machine do automatically now requires extensive human interaction to complete.


MacBook Pro 16″, macOS 15.3

Posted on Mar 16, 2025 6:30 PM

Reply
Question marked as Top-ranking reply

Posted on Apr 30, 2025 3:08 PM

This conversation has been helpful because I've been struggling with the same issue.


I can confirm that CHOSEN_RSYNC has no effect in macOS 15.4.1, the stalls continue.


However, I searched the rsync manpage. There were no matches for CHOSEN_RSYNC, but I did find a match for "samba" at the end, saying:


openrsync is compatible with rsync protocol versions 27 - 29 as supported
by the samba.org implementation of rsync.


rsync has the --protocol flag. So I tried:


rsync -avmPz --delete --protocol=28 <lan source> .


No stalls! I completed a ~400GB transfer (1.7M files) without having to babysit.

15 replies
Question marked as Top-ranking reply

Apr 30, 2025 3:08 PM in response to Jeff Freymueller

This conversation has been helpful because I've been struggling with the same issue.


I can confirm that CHOSEN_RSYNC has no effect in macOS 15.4.1, the stalls continue.


However, I searched the rsync manpage. There were no matches for CHOSEN_RSYNC, but I did find a match for "samba" at the end, saying:


openrsync is compatible with rsync protocol versions 27 - 29 as supported
by the samba.org implementation of rsync.


rsync has the --protocol flag. So I tried:


rsync -avmPz --delete --protocol=28 <lan source> .


No stalls! I completed a ~400GB transfer (1.7M files) without having to babysit.

May 5, 2025 9:16 AM in response to eskwayrd

I tried adding --protocol=28 and it appears to work for me. I did encounter one stall, but on an unusually slow internet connection (so it could have been something else).


I never had any issues at all before MacOS 15. The CHOSEN_RSYNC workaround was suggested to be earlier in this thread, and it worked until 15.4.1, when that option seems to have gone away.

Apr 30, 2025 4:34 PM in response to Jeff Freymueller

I'm also seeing problems with the "new" rsync on 15.4.1. For me, it's a straight-up crash:


zsh: segmentation fault  rsync -E -rlptgoP


That -E used to be the flag for extended attributes, which apparently changed at some point, but this still crashes:


zsh: segmentation fault  rsync --extended-attributes -rlptgoP


However, it does work for me if I just use the second set of flags (I've yet to determine if this breaks anything on the receiving side). So, yeah, I'm in agreement that clearly the QC that was done on a core tool like rsync was lacking.


Edit (in addition to removing Markdown):


Oh, BTW, the reason I use the long flag list is because I started experiencing stalls too when I used -a. I tracked it down to there being a named pipe that ended up in the files being transferred. Long shot, but are there special files in your batch?

Mar 28, 2025 1:24 PM in response to Jeff Freymueller

And the bug is thus in rsync_openrsync.


One more bit of info. If there are only a few files that have changed, the rsync_openrsync version will scan through and transfer the files that have changed, with no problems. So my comments on the counts in the original post relate to the number of files transferred, not the number of files in the source directory.

Mar 28, 2025 5:03 PM in response to Jeff Freymueller

Wonderful news. I believe this “flavor” of rsync is new to this release of macOS so the new default may be well intended and some breakage was anticipated hence the feature flag to disable the new if needed. This doesn’t seem well documented yet, only one post on Ask Different and this post here as far as I’ve seen.


There’s also some discussion that ssh keys instead of a password for auth will let either of the “flavors” work.

Apr 24, 2025 2:00 PM in response to Michael Bradshaw

I just updated to Sequoia 15.4.1, and the CHOSEN_RSYNC work-around has stopped working. I think they have done away with rsync_samba, which worked, and only provide rsync_openrsync, which does not.


[JeffM4:~] jeff% echo $CHOSEN_RSYNC


rsync_samba


[JeffM4:~] jeff% /usr/bin/rsync --version


openrsync: protocol version 29


rsync version 2.6.9 compatible



This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

rsync stalls in MacOS 15 Sequoia

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.