Rsync and operation not permitted

We use rsync to backup a user's documents to a network share and I seem to have run into an issue having it run at login.


I can run the script below, at the terminal prompt, without root access, and the rync command will run without error and I will get a successful backup on the network share:


rsync -rltgoD --progress --no-p --delete --cvs-exclude ~/Documents /Volumes/dfs/"$adOU"/"$loggedInUser"/"$computerName"


When I add that command to be run by Enterprise Connect after a successful login, it fails with the following error message:


building file list ...

0 files...

rsync: opendir "/Users/<USERNAME>/Documents" failed: Operation not permitted (1)

1 file to consider

IO error encountered -- skipping file deletion


Currently running 10.15.1



Thank you for any advice.

Replies

Update to this thread. This script runs fine under High Sierra, as a script that runs after a successful Enterprise Connect login to the server. It appears this is only happening under Catalina.

This is a consequence of new user privacy protections in macOS 10.15. See WWDC 2019 Session 701 Advances in macOS Security for all the details. As a user, you can grant access to the tool by adding it to the list in System Preferences > Security & Privacy > Privacy > Files and Folders.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"
  • I'm on Big Sur and this is not working for me. I'm not using cron, just rsync on its own. I have added both cron and rsync to the full disk access list. I have checked versions to make sure I'm using the version that has the permissions- /usr/bin/rsync. I have restarted my computer a few times as well. I'm still getting rsync: opendir "<every file on my disk>" failed: Operation not permitted (1). Please help

Add a Comment

Any solution on this? Having a similar problem. Starting a shellcript with a rsync routine by a daily job with plist. Before Catalina everything was fine. Now:

rsync: opendir "/Users/Username/Documents" failed: Operation not permitted


Manually calling the shell script executes rsync.


Adding rsync to full access list in system preferences had no effect.

Hi,


I have a similar issue running 10.14.6.


Thanks in advance.

Hi,

I also am having an issue starting a shellscript that runs the command cp -R. This copies folders from a NAS (SMB) Mounted Volume to itself. However I get the Operation not permitted error as well. I have added sh, Terminal, smbd and more to the Full Disk Accesses system preferences.

Thank you,
Same issue. I wrote a backup script (/usr/local/bin/backup) that uses rsync to copy /Users/Myname to a mounted network drive. It works perfectly when I run the script by hand, but when I run it in my personal crontab, I get these errors:

Code Block
rsync: opendir "/Users/Myname/.Trash" failed: Operation not permitted (1)
rsync: opendir "/Users/Myname/Documents" failed: Operation not permitted (1)
rsync: opendir "/Users/Myname/Downloads" failed: Operation not permitted (1)
...


I granted Full Disk Access to both /usr/bin/rsync and my script, and it didn't make any difference.

This is in Catalina 10.15.3.

Any suggestions?

I am tempted to grant Full Disk Access to bash, but that would seem to defeat the purpose of access control....

UPDATE: I found an article on Stack Exchange (apple.stackexchange.com/questions/375383/rsync-in-cron-on-catalina-no-longer-working) that says for cron scripts to work in Catalina, you have to grant Full Disk Access to /usr/sbin/cron. I'll try that next.
Following up my note: yes, granting Full Disk Access to /usr/sbin/cron solved the issue.

So, it looks like you need to grant Full Disk Access to whatever program is launching rsync.

Check "Allow full disk access for remote users":

https://support.apple.com/en-ca/guide/mac-help/mchlp1066/mac

In my case I got the error when trying to copy files from another mac using rsync over SSH.

The solution was to go to the remote machine's Settings -> Security & Privacy -> Privacy -> Full Disk Access -> sshd-keygen-wrapper and enable it.

  • This worked. Thanks.

Add a Comment