NVivo asking for Full Disk access on M1 Machines

[dlondon]

Hi,
I'm seeing an issue with NVivo 20.7.0 and even the previous version that I packaged - 20.6.2. The issue is that when I try and start NVivo it says:

NVivo needs permission to access data on your computer before it can run.
Click the button below to open your computers Security & Privacy preferences, give NVivo Full Disk Access, then restart NVivo

- I use a Configuration Profile to give NVivo full disk access.
- I only get this pop-up on M1 machines - not Intel ones
- For Intel machines, I've tested on Mac OS 11 and 12 - no issue. On Apple Silicon (M1) computers I've tested with Mac OS 12 and get the pop up.
- I tried unscoping the problem machines from the Configuration Profile and adding NVivo manually for Full Disk Access in System Preferences > Security & Privacey > Full Disk Access but no change and can't get NVivo to start
- I read this post https://forums.nvivobyqsr.com/topic/10209-i-have-given-nvivo-full-disk-access-but-it-still-will-not-... in the QSR User Forum and creating a zero byte file called CloudTabs.db in ~/Library/Safari/ and it solved the problem and NVivo starts fine just like on intel machines.
- I'm struggling to create an Automated fix to work around the issue because it seems like the ~/Library/Safari folder has a lot of protection from meddling and currently I haven't been able to do anything on the command line. This makes sense because the folder is for Safari and isn't meant to be tinkered with, not even with users who have root access. 
e.g.

dep59767:~ root# /bin/mkdir /Users/itadmin/Library/Safari
mkdir: /Users/itadmin/Library/Safari: Operation not permitted
dep59767:~ root# su itadmin
itadmin@dep59767 . % /bin/mkdir /Users/itadmin/Library/Safari
mkdir: /Users/itadmin/Library/Safari: Operation not permitted

- I can't even get Composer to capture that file :(

Has anyone come across this issue and have you found something a bit better than getting the users to manually create the folder and drag it into the ~/Library/Safari folder  - e.g. a plist or setting file in NVivo that I could tweak to stop NVivo looking in that folder for the CloudTabs.db file?

[PaulHazelden]

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.

[dlondon]

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 permitted

Then 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.

[PaulHazelden]

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.

[bethjohnson]

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.

[dlondon]

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

[grayw · Accepted solution]

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.

[dlondon]

Thanks Gray - looks like that did the trick!

[dlondon]

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

[CJ22]

Hello, how would I do this? Having the same issues and tried everything!

[uurazzle]

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

[uurazzle]

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.