Full Disk access to launchctl script

What file operation is failing when you don’t have Full Disk Access?

Is

zpool

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

zpool binary, and all its .dylibs, are signed and notarized. Hopefully correctly, but let's leave a little room for the possibility I got something wrong.

I need to think up a good way to test the issue, since it appears to trigger at boot (when it is supposed to import the pools), from launchd. I believe when run by hand after a user logged in, all is well. Could it be running too early, before the OS has a chance to verify certificates?

I found I had to leave "mount_zfs" unsigned for mount_root - or it would fail to mount root at boot time as it was unable to verify the teamID. But that is unrelated I think.

I think you've got too many things going on at once. I suggest dealing with them one at a time.

1) You are trying to run a shell script through launchctl. You can make that work, but there is no point in relying on all the shell script baggage when you don't need to. Instead, use this in your plist:

<key>ProgramArguments</key>

<array>

<string>/usr/local/sbin/zpool</string>

<string>import</string>

<string>-a</string>

</array>

If this fails, it means you are relying on some shell script baggage like environment variables. Ideally, remove that baggage or maybe configure your plist to provide what you need. Also, never use an interactive shell like "bash" as an unattended interpreter. Just use "sh" for these situtations. And don't use bash at all on a Mac. It is long since deprecated and dead-in-the-water. Use zsh if you want something modern.

2. Maybe there is no 2). The above might solve the problem. If it works form the command line but not in launchd, that is usually a classic launchd problem and unrelated to any new permissions issues.

3. Regarding Full Disk Access. What are you trying to do here? Clearly it is something with zfs. But Full Disk Access, especially in this context, shouldn't be required. Full Disk Access, especially in a non-sandboxed, root context, only protects certain sensitive Apple directories and certain user directories. If you are mounting new zfs volumes, it shouldn't have anything to do with Full Disk Access.