Full disk access is required if the destination for the `.backup` files are set as a remote network share like NFS or SMB

[sethgoldin]

A couple of users noticed that if a remote network share is specified as the destination directory for the .backup files, like an NFS or SMB share, then the launchd daemon won't have permission to execute pg_dump.

A couple of similar cases on Stack Exchange:

• https://stackoverflow.com/questions/58677123/launchagent-script-cant-write-to-external-drive
• https://superuser.com/questions/1669457/launchd-unable-to-access-external-drive

So a line of documentation should be added to README.md to let users know to grant the /Library/PostgreSQL/13/bin/pg_dump binary full disk access if they intend to save out to a remote network share.

[macvfx]

FDA tcc full disk access check (can be tested and added in another pull request)

if [ -r '/Library/Application Support/com.apple.TCC/TCC.db' ]; then

If TCC.db is readable (tested via "-r") then the parent process has Full Disk Access since the TCC.db can only be read with FDA.

echo 'HAS FDA' else echo 'no FDA' fi

[nicolasforest]

Hi, I've added pg_dump to full disk access permission, but the log only show the optimization. I'm not getting any backup. In the backup and optimized folder, I do see script that has been created for each DB.

[sethgoldin]

@nicolasforest Did you escape all the spaces and special characters in the full path of whatever destination folder you specified?

[nicolasforest]

Hi, yes I've escaped all space and there is no special character. It's working on local drive, but not on SMB. I've gave the full permission disk access to pg_dump

[nicolasforest]

adding also /bin/bash to full disk access make it work.

[sethgoldin]

@nicolasforest I don't think it's just that the pg_dump binary needs permission. I think the issue is that permission must be given to write to the destination directory itself.