I have a script that copies a file from our server to the local machine. Here is the script and output

+ date
Thu Jun 11 09:16:00 ACST 2020
+ id -un
+ pwd
/Volumes/Macintosh HD/backups
+ mkdir /Volumes/Server_auto
+ /sbin/mount_smbfs smb://User:password@Server/General  /Volumes/Server_auto
+ ls /Volumes
Macintosh HD
+ ls /Volumes/Server_auto
ls: Server_auto: Operation not permitted

Ultimately I want to

cp -f /Volumes/Server_auto/Backups/Web/db_6_1500.zip ./db.zip

but I think if I can at least get a directory listing, the copy will probably work.

I can sudo this script from the terminal and it runs without a hitch. It has been running for several years from cron without a hitch, it's only after updating to Catalina that the problems have started.

I have tried

  • adding cron, ls and mount_smbfs to the Full Disk Access list
  • moving the job to a plist file in the LaunchDaemons folder

Everything works just fine except for the copy operation. Behaviour is identical under cron or plist/launchd.

This is clearly a SIP issue. Before I added cron to the Privacy 'Full Disk Access' list, I was getting the same error message when the cron job started.
Now, it's entirely blocking the external SMB share, but I don't know why or what permission to grant to make it work. The exact same sequence of operations, when run manually as root, succeed every time.

Any ideas?

  • The copy reads from the share and writes to the current directoy. When running from cron, what directory is this and does root have write permissions there?
    – nohillside
    Jun 10, 2020 at 8:05
  • as mentioned, the destination (current) folder is world-writable. See recent comments - even ls is failing. I'm beginning to suspect it's a mount issue, but I can't see why it would work in one context but not the other. Jun 10, 2020 at 8:06

2 Answers 2


I had the same problem and it was fixed by granting »Full disk access« to Terminal in System preferences -> Security & Privacy -> Privacy and restarting Terminal.

Click the lock at the bottom left of the window in case the options are greyed out.

  • Thanks, but I tried this long ago. I am now suspecting that this is an issue with the particular machine, perhaps with the SIP or BIOS settings. I have also had issues with other programs not working correctly. I even reinstalled OSX (for the first time ever), but it didn't help. Jul 19, 2020 at 5:09
  • 1
    Hmmm. So, reset PRAM and SMC, and disabled SIP. Still no change. Jul 31, 2020 at 13:45
  • Interestingly I still had access to one of the mounted volumes. Others were blocked as OP stated. This resolved the issue, thx. Jul 15, 2022 at 10:49

I am having this problem more often with Sonoma OS, the cause seems to be the share is accessed and mounted by one user, then the other user cannot access. The temporary cure is to unmount with sudo and remount as the user who is going to access the share. Especially tricky is getting it right with the user and permissions when doing mkdir /Volumes/aaa. Basically, this is bad idea, I recommend creating the mount somewhere else.

When using automount, sometimes I had to remove the line from auto_master unmount with automount -vc then add back the line and mount again. Here, one additional piece of advice is, use a "new style" directory names for mounting shares, such as /System/Volumes/Data/sharename. Automount will create it for you with the right permissions.

  • interesting. I never did solve this, I decided in the end that the Mac Mini I was running it on had some specific hardware issues. The kicker with all of this was that it would run fine as root (so under sudo) from Terminal, but then not run as a scheduled job, when you can see that id -un was indicating that the job was running as root. Nov 23, 2023 at 23:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .