In the Terminal you look like you are using root account. Try logging in as an administrator and using sudo rather than root. I know sounds daft, but when Apple changed the system around and locked out the System folder, they changed root access, and now for some things sudo does a better job.
In the Terminal you look like you are using root account. Try logging in as an administrator and using sudo rather than root. I know sounds daft, but when Apple changed the system around and locked out the System folder, they changed root access, and now for some things sudo does a better job.
Unfortunately sudo doesn't do it either
I tried first removing ~/Library/Safari in Finder and then in terminal
itadmin@dep59767 ~ % sudo mkdir ~/Library/Safari
Password:
mkdir: /Users/itadmin/Library/Safari: Operation not permittedThen I just opened Safari and that creates the folder
so then I tried making the zero byte file using touch in the Terminal
itadmin@dep59767 ~ % sudo touch ~/Library/Safari/CloudTabs.db
touch: /Users/itadmin/Library/Safari/CloudTabs.db: Operation not permitted
But all these things can be achieved in Finder by the user.
If they can be done by the user, can they be done by script as the user?
If they can, create a script, and create a LaunchAgent to set the script off. Then when the user logs in the script will run. Use a test to see if the db file exists and then you can exit the script. LaunchAgent scripts always run as the User logging in.
I'm using this snippet in a script to solve this problem. It runs from a script in a policy that is set to run once per user per computer at login:
# Find the logged-in user
loggedInUser=$(stat -f%Su /dev/console)
# Create the file that NVivo is "testing"
touch /Users/$loggedInUser/Library/Safari/CloudTabs.db
echo "The file has been created for NVivo to read." This has solved it for us on all of our lab computers.
This was a really poor decision on QSR's part -- adding their own access "check" and making it look like a PPPC profile will satisfy their check, but it won't.
I'm using this snippet in a script to solve this problem. It runs from a script in a policy that is set to run once per user per computer at login:
# Find the logged-in user
loggedInUser=$(stat -f%Su /dev/console)
# Create the file that NVivo is "testing"
touch /Users/$loggedInUser/Library/Safari/CloudTabs.db
echo "The file has been created for NVivo to read." This has solved it for us on all of our lab computers.
This was a really poor decision on QSR's part -- adding their own access "check" and making it look like a PPPC profile will satisfy their check, but it won't.
Thanks Beth,
Unfortunately whilst that will work on intel machines even with Monterey, when I try just that touch command (or the mkdir when Safari hasn't been used) as the user I get this on M1 machines
itadmin@dep59767 ~ % touch ~/Library/Safari/CloudTabs.db
touch: /Users/itadmin/Library/Safari/CloudTabs.db: Operation not permitted
itadmin@dep59767 ~ % touch /Users/itadmin/Library/Safari/CloudTabs.db
touch: /Users/itadmin/Library/Safari/CloudTabs.db: Operation not permitted
Thanks Beth,
Unfortunately whilst that will work on intel machines even with Monterey, when I try just that touch command (or the mkdir when Safari hasn't been used) as the user I get this on M1 machines
itadmin@dep59767 ~ % touch ~/Library/Safari/CloudTabs.db
touch: /Users/itadmin/Library/Safari/CloudTabs.db: Operation not permitted
itadmin@dep59767 ~ % touch /Users/itadmin/Library/Safari/CloudTabs.db
touch: /Users/itadmin/Library/Safari/CloudTabs.db: Operation not permitted
Looks like we can step around this by giving Terminal Full Disk Access. Just had it work on an Intel, a VM on my Intel, and a physical M1.
Looks like we can step around this by giving Terminal Full Disk Access. Just had it work on an Intel, a VM on my Intel, and a physical M1.
Thanks Gray - looks like that did the trick!
Looks like we can step around this by giving Terminal Full Disk Access. Just had it work on an Intel, a VM on my Intel, and a physical M1.
Strangely today I needed to do this on the intel test machine too which is running Mac OS 11. Very odd but it lines up with your experience
FYI, they just release an update NVIvo Pro 20.7.1 (Release 17.1) that fixes the recent permissions issue. But, haven’t seen a release of NVivo 12 yet. In my test, the update fixes these permissions issues with NVivo Pro 20.7 or earlier.
Looks like we can step around this by giving Terminal Full Disk Access. Just had it work on an Intel, a VM on my Intel, and a physical M1.
Hello, how would I do this? Having the same issues and tried everything!
Hello, how would I do this? Having the same issues and tried everything!
Hi @CJ22:
Are you using the latest releases of NVivo 20.x? Also, you need to create a Privacy Preferences Policy Control (PPPC) configuration profile and allow NVivo 20.x allowance to all files.
PPPC stands for Privacy Preferences Policy Control, and it is a security feature introduced by Apple in macOS Mojave (10.14) and later versions. PPPC is designed to enhance user privacy and security by giving users more control over how applications can access sensitive data and features on their Mac.
With PPPC, certain macOS system resources, such as access to the camera, microphone, location services, contacts, calendar events, and more, are restricted by default. When an application wants to access these sensitive resources, it must request user consent first. The user will be prompted to grant or deny the application's access to the requested resource.
This full-disk access is improperly used, but to get NVivo 20.x to properly work we will need to use the "SystemPolicyAllFiles" dictionary key and allow its usage.
CFBundleIdentifier
com.qsrinternational.NVivo-20
Code Signature
identifier "com.qsrinternational.NVivo-20" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = A66L57342X
Hope this help
