Rsync Iconv Option Not Working on Mac – How to Fix Rsync Backup Issues

backuplinuxmacrsync

I want to use rsync to backup data from a remote Linux server to my local Mac. And I want to initialise this operation on my local Mac. All works fine except that there is a special character problem: every time I re-run the rsync operation (after the initial sync), the files with special characters are first deleted and then re-synced. As far as I understand, there is a problem with different character sets, and the preferred solution seems to be to use the --iconv option:

You can use rsync's –iconv option to convert between UTF-8 NFC & NFD,
at least if you're on a Mac. There is a special utf-8-mac character
set that stands for UTF-8 NFD. So to copy files from your Mac to your
NAS, you'd need to run something like:

rsync -a --iconv=utf-8-mac,utf-8 localdir/ mynas:remotedir/

This will convert all the local filenames from UTF-8 NFD to UTF-8 NFC on the
remote server. The files' contents won't be affected.

The problem is that this only works 'one way' for me, namely when syncing from the Mac to the linux. But I want to 'go the other way', i.e. sync FROM the linux machine TO the Mac. And I want to initialise the operation from my local Mac. But when I try:

rsync -av --delete --iconv=utf-8,utf-8-mac mynas:remotedir/ localdir/

I receive an error:

iconv_open("UTF-8", "utf-8-mac") failed
rsync error: requested action not supported (code 4) at rsync.c(118) [sender=3.0.9]
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(226) [Receiver=3.1.1]

I am at loss to understand why this does not work. My rsync version on the Mac is updated from 2.6.9. to 3.1.1. using Macports. Note that the operation works then when I (on the Mac, nota bene) initiate a rsync FROM the Mac TO Linux:

rsync -av --delete --iconv=utf-8-mac,utf-8 localdir/ mynas:remotedir/

But going the other way' from the mac – which is what I want to do – does not work.

Strangely enough, testing to initiate the sync from the linux machine renders this strange message:

rsync: on remote machine: --iconv=UTF-8-MAC: unknown option
rsync error: syntax or usage error (code 1) at /SourceCache/rsync/rsync-45/rsync/main.c(1333) [server=2.6.9]
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [sender=3.0.9]

including, note, the very strange claim [server=2.6.9], although I have updated to 3.1.1 on the Mac. For some reasons, it looks as my linux machine 'sees' only the original rsync version on the Mac.

Any suggestion on how to solve this?

UPDATE October 23: Per @Lee Johnson's excellent suggestion (see below), initiating the sync from the linux server now works. For completeness, I have now tried all combinations, and an interesting pattern emerges:

ON MAC:

WORKS: Files from Mac to Linux

FAILS: Files from Linux to Mac

ON LINUX

WORKS: Files from Linux to Mac

FAILS: Files from Mac to Linux

In other words, the --iconv option seems to work only one way, with files from the local machine to the remote, not the other way around. It looks like a bug to me, but maybe that is the way it is SUPPOSED to work?

Anyone able to share light on this?

Best Answer

After a lot of experimenting, and very much due to @Lee Johnson's helpful suggestions, I finally found out the solution, which now strikes me as embarrassingly obvious. Much due to a comment I read when researching the problem, I thought you were supposed to specify the character set in the order of transformation; but it seems as that is not the correct syntax. Rather, one should

ALWAYS use --iconv=utf-8-mac,utf-8 when initialising the rsync from the mac, and ALWAYS use --iconv=utf-8,utf-8-mac when initialising the rsync from the linux machine, no matter if I want to sync files from the mac or linux machine.

Then it works like magic!