'Operation not permitted' accessing SMB Share as root under Catalina

Question

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
root
+ pwd
/Volumes/Macintosh HD/backups
+ mkdir /Volumes/Server_auto
+ /sbin/mount_smbfs smb://User:password@Server/General  /Volumes/Server_auto
+ ls /Volumes
Macintosh HD
Server_auto
+ 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?

Answer 1

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.

Answer 2

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.