New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MacOS Mojave: error: Open: ... operation not permitted #2051

Open
n8henrie opened this Issue Oct 17, 2018 · 36 comments

Comments

Projects
None yet
6 participants
@n8henrie

n8henrie commented Oct 17, 2018

MacOS Mojave's privacy features seem to limit restic access to files (at least that what seems to be happening), I'm getting permissions errors that I didn't get prior to upgrading.

MacOS 10.14

Running with sudo:

can not obtain extended attribute com.apple.rootless for /Library/Application Support/com.apple.TCC
error: Open: open /Library/Application Support/com.apple.TCC: operation not permitted
error: open /Library/Preferences/com.apple.TimeMachine.plist: operation not permitted

... many other files.

Output of restic version

0.9.2 (most recent in homebrew)

How did you run restic exactly?

Same bash script I've been using for months prior to upgrading to Mojave, run with root privileges.

RESTIC_PASSWORD_FILE="/path/to/file.txt" \
HOME="/path/to/homedir" \
/usr/local/bin/restic \
    --repo sftp:myserver.local:my/repo/path \
    --option='sftp.command=ssh -p REDACTEDPORT -i REDACTEDKEYFILE -o identitiesonly=yes -l restic myserver.local -s sftp' \
    --exclude-file="${DIR}/global-exclude.txt" \
    --exclude-if-present='.norestic' \
    backup \
    --cleanup-cache \
    / \
    &>> /path/to/file.log

What backend/server/service did you use to store the repository?

sftp, as per above. Same repo as previous.

Expected behavior

Hopefully reads and backs up all files when run as root (realizing this may not be a restic issue, but seems like it's certainly a problem for backups).

Actual behavior

as per above

Steps to reproduce the behavior

sudo bash restic-backup.sh (script above)

Do you have any idea what may have caused this?

My guess:

Do you have an idea how to solve the issue?

No. What I've tried so far:

  • No libcap on MacOS, so can't use setcap.
  • Tried adding restic to "Full Disk Access" in the new System Preferences -> Security and Privacy pane, no luck.

Did restic help you or made you happy in any way?

After years of trying to find a good, reliable, scriptable, open source backup solution, it's the only one that fits the bill. So grateful!

@mholt

This comment has been minimized.

Contributor

mholt commented Oct 17, 2018

Yeah, apparently you have to do the Full Disk Access thing: https://www.backblaze.com/blog/mojave-permissions/

Are you sure you added the right restic binary? Did you move the file or change any of its attributes (ownership, etc) after adding it to Full Disk Access in System Preferences?

(I have a Mac, but I don't yet have Mojave, sorry.)

@n8henrie

This comment has been minimized.

n8henrie commented Oct 17, 2018

I use homebrew, so first I added /usr/local/bin/restic to Full Disk Access, started a job, noted the same errors, so then I removed that and added the path to the actual binary (noting that this would unfortunately have to be redone every time restic updates): /usr/local/Cellar/restic/0.9.2/bin/restic, unfortunately I see the same errors.

No changes, added binary to Full Disk Access, switched back to terminal and ran sudo myscript.sh, which worked for most files but gave permission errors on others.

Side-note, there is another (possibly Mojave-related) issue I'm trying to flesh out, where my sftp pubkey authentication stopped working when run from launchctl (as root), but works when run manually as root, but I'll file a new issue if I'm able to determine that it's not specific to my setup.

@mholt

This comment has been minimized.

Contributor

mholt commented Oct 17, 2018

Interesting. What happens if you run restic directly? And/or add your script to FDA. Just shooting in the dark here, honestly. If I had Mojave I'd try it out.

@n8henrie

This comment has been minimized.

n8henrie commented Oct 17, 2018

Good thought.

My script itself is not executable (for no good reason really), as noted I run it with sudo bash myscript.sh (/usr/local/bin/bash actually); it can't be added to FDA because it is not executable.

I tried adding /usr/local/bin/bash to FDA and no dice.

EDIT: I'm wrong apparently, even after chmod +x, my backup.sh still can't be added directly to FDA (while the bash and restic binaries can). Odd.

EDIT2: Just to be thorough, I added the bash and restic binaries both to FDA and I see the same error.

@n8henrie

This comment has been minimized.

n8henrie commented Oct 17, 2018

Probably a bigger issue than restic -- I even tried adding /bin/ls to the FDA list and still get an error.

$ sudo /bin/ls /Users/me/Library/Suggestions
ls: Suggestions: Operation not permitted

EDIT: Ugly workaround: add Terminal.app to the FDA permissions and the permissions errors go away.

@n8henrie

This comment has been minimized.

n8henrie commented Oct 17, 2018

@n8henrie

This comment has been minimized.

n8henrie commented Oct 17, 2018

Tried codesigning both the restic binary and my backup.sh script and adding to FDA, no luck.

@mholt

This comment has been minimized.

Contributor

mholt commented Oct 18, 2018

(After reading some of that thread) My goodness. This is super annoying. Thanks for looking into it! I'll keep investigating too once I upgrade...

@fd0

This comment has been minimized.

Member

fd0 commented Oct 18, 2018

Wow, thank you very much for the information and all the time you spent on the problem! I don't have a mac at all, so I'm glad if you both could figure it out and we can document this issue for other users! Thank you again!

@rawtaz

This comment has been minimized.

Contributor

rawtaz commented Oct 18, 2018

@mholt If you want to, you can install a 30 day trial of VMware Fusion and install Mojave in that (unless Apple crippled the ability to install it ad-hoc). That trial doesn't do any pollution and can be uninstalled if you don't want it later on.

@n8henrie

This comment has been minimized.

n8henrie commented Oct 18, 2018

I noted above that adding Terminal.app to the System Preferences -> Security & Privacy -> Full Disk Access list was a workaround, since when I manually ran my script (sudo /usr/local/bin/bash mybackup.sh) it seemed to work without the permissions errors.

For some reason, when I checked my logs this morning from the automated overnight restic run (based on a launchd script at /Library/LaunchDaemons/com.n8henrie.restic.plist which runs nightly with root privileges), the permissions errors are still there.

And unfortunately, I am now unable to get the workaround to work -- even with Terminal.app in FDA, I still get the permissions errors when I run sudo launchctl start com.n8henrie.restic or sudo /usr/local/bin/bash mybackup.sh.

So the workaround doesn't seem to work, or something has changed.

EDIT: Gah, just added all 3 to FDA -- Terminal.app, /usr/local/bin/bash, and /usr/local/Cellar/restic/0.9.2/bin/restic -- and now it ran without errors. 🤷‍♂️

FWIW, here is my log output, which contains the list of files getting errors. As you can see, there are some big concerns, like my photos library.

@mholt

This comment has been minimized.

Contributor

mholt commented Oct 18, 2018

@n8henrie From the Mac support thread you linked to earlier, it seems that FDA requires the approved apps to be a registered .app bundle in the Applications folder, which might be why Terminal.app succeeds... but you have to add all 3 to FDA in your case? Interesting...

@n8henrie

This comment has been minimized.

n8henrie commented Oct 19, 2018

@mholt it looks like something else is going on. I left my settings exactly as they were yesterday (all 3 in FDA, which produced no permissions errors), and my overnight run still got the same old permissions errors.

This has happened twice now, where after tinkering for a while I get runs with no permissions errors that then reappear. Does restic somehow know whether or not a file has changed without needing to open the file -- some kind of cache? I wonder if I'm getting fooled by runs that are done closely together, and there have been no interim changes to a file and therefore restic doesn't try to open it?

Otherwise I'm having a hard time explaining what's going on here.

@mholt

This comment has been minimized.

Contributor

mholt commented Oct 19, 2018

Good question. I know restic uses a cache but I have not looked into how aggressively it adheres to it in the case of permissions errors, etc.

@n8henrie

This comment has been minimized.

n8henrie commented Oct 20, 2018

@fd0

This comment has been minimized.

Member

fd0 commented Oct 20, 2018

Good question. I know restic uses a cache but I have not looked into how aggressively it adheres to it in the case of permissions errors, etc.

Not at all. The cache only contains files from the repo, no information about the file system (that is not in the repo) is included.

@mholt

This comment has been minimized.

Contributor

mholt commented Oct 22, 2018

Okay -- yeah, I don't think this is a bug in restic. This is definitely a macOS Mojave issue that, at this point, I'm pretty sure restic itself can't do anything to fix.

@fd0

This comment has been minimized.

Member

fd0 commented Oct 22, 2018

Cool, thanks for the feedback, I'm closing this issue for now. Please add more comments if you find out things. Thanks!

@fd0 fd0 closed this Oct 22, 2018

@fd0 fd0 removed bug needs triage labels Oct 22, 2018

@n8henrie

This comment has been minimized.

n8henrie commented Oct 23, 2018

@n8henrie

This comment has been minimized.

n8henrie commented Nov 3, 2018

A few more updates now that I have my machine back:

I cannot replicate my successes above in getting a full system backup from my launchd script.

I've tried adding all of the below to the FDA list (at the same time), and still get the errors:

  • restic
  • bash
  • launchctl
  • launchd
  • Terminal.app

Just for experimentation, bare binaries seem to work fine when added to the FDA list and seems to have nothing to do with codesigning. Compare the ls binaries provided by MacOS and by Homebrew:

$ codesign -d /bin/ls
Executable=/bin/ls
$ codesign -d /usr/local/opt/coreutils/libexec/gnubin/ls
/usr/local/opt/coreutils/libexec/gnubin/ls: code object is not signed at all

Before and adding to the FDA list:

$ /bin/ls ~/Library/Mail
ls: Mail: Operation not permitted
$ /usr/local/opt/coreutils/libexec/gnubin/ls ~/Library/Mail
ls: cannot open directory '/Users/n8henrie/Library/Mail': Operation not permitted
$ # Added to FDA
$ /bin/ls ~/Library/Mail
PersistenceInfo.plist V6
$ /usr/local/opt/coreutils/libexec/gnubin/ls ~/Library/Mail
PersistenceInfo.plist  V6

Additionally, they work fine when put into a bash script as long as ls is in FDA (no need to add bash separately), which makes me think I should only need to add restic.

Also, for comparison running the following Go script errors if not in FDA, but works fine by itself as well as when called from launchd as long as the binary is in FDA (no need to add launchd / launchctl / anything else).

package main

import (
	"fmt"
	"io/ioutil"
)

func main() {
	matches, err := ioutil.ReadDir("/Users/n8henrie/Library/Mail")
	if err != nil {
		fmt.Println("Err:", err)
	} else {
		for _, match := range matches {
			fmt.Println(match.Name())
		}
	}
}

Output:

$ ./gotest
Err: open /Users/n8henrie/Library/Mail: operation not permitted
$ # Add to FDA
$ ./gotest
.DS_Store
PersistenceInfo.plist
V6

Next I'll do some experimenting with Restic to see if I can figure out why it's getting permission errors even when added to FDA (although other binaries seem to be working once added).

@fd0

This comment has been minimized.

Member

fd0 commented Nov 3, 2018

Ok, thanks for the feedback! I'll reopen this issue, maybe we can figure it out what's going on and then add some documentation to the manual.

@fd0 fd0 reopened this Nov 3, 2018

@n8henrie

This comment has been minimized.

n8henrie commented Nov 4, 2018

Still getting Open errors on a fresh repo, with restic added to the FDA list.

See edit below.

$ restic -r /tmp/restic backup ~/Library/Mail -vvv
open repository
enter password for repository:
repository 9ccb5357 opened successfully, password is correct
created new cache in /Users/me/Library/Caches/restic
lock repository
load index files
start scan on [/Users/me/Library/Mail]
start backup on [/Users/me/Library/Mail]
scan: Open: open /Users/me/Library/Mail: operation not permitted
scan finished in 1.849s: 0 files, 0 B
can not obtain extended attribute com.apple.quarantine for /Users/me/Library/Mail:
error: Open: open /Users/me/Library/Mail: operation not permitted
new       /Users/me/Library/, saved in 0.012s (0 B added, 13 B metadata)
new       /Users/me/, saved in 0.012s (0 B added, 381 B metadata)
new       /Users/, saved in 0.013s (0 B added, 379 B metadata)

Files:           0 new,     0 changed,     0 unmodified
Dirs:            3 new,     0 changed,     0 unmodified
Data Blobs:      0 new
Tree Blobs:      4 new
Added to the repo: 1.119 KiB

processed 0 files, 0 B in 0:01
snapshot 4a658c73 saved
$ restic -r /tmp/restic ls latest
enter password for repository:
repository 9ccb5357 opened successfully, password is correct
snapshot 4a658c73 of [/Users/me/Library/Mail] filtered by [] at 2018-11-04 11:30:05.334024 -0700 MST):
/Users
/Users/me
/Users/me/Library

screenshot 2018-11-04 at 11 32 18 am

EDIT: Disregard this comment -- I'm still plagued by intermittent errors that are confounding any progress, perhaps in association with updating to MacOS 10.14.1 yesterday. Today, the same Go code from yesterday that consistently worked with FDA and failed without it (I toggled it on and off multiple times to be sure) is no longer working even with FDA. Same with ls.

It does work if Terminal.app is added to FDA (as the sole entry), which wasn't necessary yesterday.

🤷‍♂️

I'll report back if I can find anything on this in the Apple forums.

EDIT2: Wife's Macbook is still on 10.14, and /bin/ls ~/Library/Mail does not work with /bin/ls added to FDA, so seems like it may not be something new in 10.14.1. 😕

@n8henrie

This comment has been minimized.

n8henrie commented Nov 16, 2018

Still working on this.

It continues to be pretty painful, but I finally have a workaround that I think will work for my purposes.

I've detailed the process here, but the bottom line is:

You can use Script Editor.app to make an AppleScript into an application bundle. That AppleScript can run your restic backup script (in my case /path/to/restic-backup.sh, where restic-backup.sh is a bash script that runs restic with my desired settings), and you can add the resulting application bundle to FDA in order to get access to the protected files.

However, this makes it difficult to automate running backups on a system level. The built-in open command works, but runs the application under your user -- so while the FDA protected files above are backed up, you'll get permissions errors on any files that are only root readable (e.g. root-owned 0600 stuff).

My workaround at this point is to have the AppleScript call the backup script with sudo and give my user privileges to run that script with root privileges without a password (sudo visudo, NOPASSWD:, etc.).

It's not pretty, but it seems to be working.

I'd like to leave this open for any suggestions from MacOS users with more expertise. If nothing more satisfying comes up, I could add this info to the docs (although this solution honestly doesn't seem very satisfactory).

@n8henrie

This comment has been minimized.

n8henrie commented Nov 21, 2018

Unbelievable, this seems to work and is far cleaner and more simple.

// Runrestic provides a binary to run my restic backup script in MacOS Mojave with Full Disk Access
package main

import (
    "log"
    "os"
    "os/exec"
    "path/filepath"
)

func main() {
    ex, err := os.Executable()
    if err != nil {
        log.Fatal(err)
    }
    dir := filepath.Dir(ex)
    script := filepath.Join(dir, "restic-backup.sh")
    cmd := exec.Command("/usr/local/bin/bash", script)
    if err := cmd.Run(); err != nil {
        log.Fatal(err)
    }
}

The resulting binary can be chown root and chmod 0700, then add to Full Disk Access, and it seems to work. It can then be added to a /Library/LaunchDaemons plist to run automatically.

First 2 runs are working so far, I'm hopeful that this doesn't end up like several false starts above.

@n8henrie

This comment has been minimized.

n8henrie commented Nov 21, 2018

My automated run last night worked. I'm deploying this strategy to my wife's Macbook Air today, if it looks like it works there as well, I'll consider this a reasonable fix and work on a small PR to https://github.com/restic/restic.net (if that seems reasonable).

@armhold

This comment has been minimized.

Contributor

armhold commented Nov 28, 2018

Hi @n8henrie, I came here after hitting this exact problem and then finding your blog post. Thanks for doing all this research.

The above solution (call shell script from simple Go binary) isn't working for me. Are you sure it's successfully accessing all your files?

I notice in particular that stdout/stderr is discarded to /dev/null. It also cannot read stdin if, for example, restic wants to prompt for a password. (Also kind of funny, why is your bash /usr/local/bin/bash and not /bin/bash? Just curious.)

Anyway I made the following changes to see the error output:

	cmd := exec.Command("/bin/bash", script)
	cmd.Stdin = os.Stdin
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr

Before seeing your blog post my first instinct was to add the restic binary itself to the FDA, and that did not work for me under 10.14.1 (18B75). I'm not sure why inserting another program (the Go wrapper calling a shell script, ultimately calling restic) would change anything.

Is this still working for you?

@fd0

This comment has been minimized.

Member

fd0 commented Nov 28, 2018

@n8henrie thanks for keeping us posted! You could also write a blog post about it on the restic blog if you're up for it (in addition to a small section in the manual or so)... :)

@n8henrie

This comment has been minimized.

n8henrie commented Nov 28, 2018

@fd0 I'd be honored!

@armhold yes, seems to be working like a charm, see below. On my wife's MBA, I think I required a reboot before it started working (not on mine though). IIRC for hers, I created the binary, then rebooted, then added to FDA, and it worked.

Before the fix:

Thu Nov 15 02:00:00 MST 2018 :: Starting restic-backup.sh
can not obtain extended attribute com.apple.rootless for /Library/Application Support/com.apple.TCC:
error: Open: open /Library/Application Support/com.apple.TCC: operation not permitted
error: open /Library/Preferences/com.apple.TimeMachine.plist: operation not permitted
error: Open: open /Users/me/Library/Application Support/AddressBook: operation not permitted
error: Open: open /Users/me/Library/Application Support/CallHistoryDB: operation not permitted
error: Open: open /Users/me/Library/Application Support/CallHistoryTransactions: operation not permitted
error: Open: open /Users/me/Library/Application Support/MobileSync: operation not permitted
error: Open: open /Users/me/Library/Application Support/com.apple.TCC: operation not permitted
error: Open: open /Users/me/Library/Calendars: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.Home: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.Safari: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.VoiceMemos: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.iChat: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.mail: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.news: operation not permitted
error: Open: open /Users/me/Library/Containers/com.apple.stocks: operation not permitted
can not obtain extended attribute com.apple.quarantine for /Users/me/Library/Cookies:
error: Open: open /Users/me/Library/Cookies: operation not permitted
error: Open: open /Users/me/Library/HomeKit: operation not permitted
error: Open: open /Users/me/Library/IdentityServices: operation not permitted
can not obtain extended attribute com.apple.quarantine for /Users/me/Library/Mail:
error: Open: open /Users/me/Library/Mail: operation not permitted
error: Open: open /Users/me/Library/Messages: operation not permitted
error: Open: open /Users/me/Library/Metadata/CoreSpotlight: operation not permitted
error: Open: open /Users/me/Library/Metadata/com.apple.IntelligentSuggestions: operation not permitted
can not obtain extended attribute com.apple.metadata:com_apple_backup_excludeItem for /Users/me/Library/PersonalizationPortrait:
error: Open: open /Users/me/Library/PersonalizationPortrait: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.AddressBook.plist: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.AddressBook.plist.KaSTvBv: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.AddressBook.plist.M410OmB: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.AddressBook.plist.Sjhd5Xh: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.AddressBook.plist.ceAM0im: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.homed.notbackedup.plist: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.homed.plist: operation not permitted
error: open /Users/me/Library/Preferences/com.apple.mail-shared.plist: operation not permitted
error: Open: open /Users/me/Library/Safari: operation not permitted
can not obtain extended attribute com.apple.metadata:com_apple_backup_excludeItem for /Users/me/Library/Suggestions:
error: Open: open /Users/me/Library/Suggestions: operation not permitted
can not obtain extended attribute com.apple.FinderInfo for /Users/me/Pictures/Photos Library.photoslibrary:
can not obtain extended attribute com.apple.quarantine for /Users/me/Pictures/Photos Library.photoslibrary:
error: Open: open /Users/me/Pictures/Photos Library.photoslibrary: operation not permitted

Files:         179 new,   261 changed, 857338 unmodified
Dirs:            0 new,     0 changed,     0 unmodified
Added to the repo: 266.392 MiB

processed 857778 files, 186.192 GiB in 12:57
snapshot 46831f24 saved
Thu Nov 15 02:12:58 MST 2018 :: restic-backup.sh finished.
Duration: 778 seconds

After the fix:

Tue Nov 27 02:00:00 MST 2018 :: Starting restic-backup.sh

Files:         389 new,  2367 changed, 1055845 unmodified
Dirs:            0 new,     0 changed,     0 unmodified
Added to the repo: 430.279 MiB

processed 1058601 files, 295.471 GiB in 18:16
snapshot e58d8f1c saved
Tue Nov 27 02:18:17 MST 2018 :: restic-backup.sh finished.
Duration: 1097 seconds

Same fix is also working on my wife's Macbook Air, both verified on the remote with restic find '/Users/*/Library/Mail' --snapshot latest --host=$(hostname) (where ~/Library/Mail is one of the directories usually protected, as can be seen in the log of errors above).

I notice in particular that stdout/stderr is discarded to /dev/null. It also cannot read stdin if, for example, restic wants to prompt for a password.

This will depend entirely on your script. As you can see in my original post, since my setup is fully automated, it is set up to read password from a (root-owned 0600) file, but could also read from an envvar or any of the usual methods. You're right, I don't think this will work for interactive stuff. It also logs everything to a file: &>> /path/to/file.log.

(Also kind of funny, why is your bash /usr/local/bin/bash and not /bin/bash? Just curious.)

I use Homebrew to get a more recent version of bash

$ /bin/bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
Copyright (C) 2007 Free Software Foundation, Inc.
$ /usr/local/bin/bash --version
GNU bash, version 4.4.23(1)-release (x86_64-apple-darwin17.5.0)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

This gets me more modern features, such as the &>file.log operator (which saves a few keystrokes compared to 2>&1 >file.log.

Before seeing your blog post my first instinct was to add the restic binary itself to the FDA, and that did not work for me under 10.14.1 (18B75). I'm not sure why inserting another program (the Go wrapper calling a shell script, ultimately calling restic) would change anything.

I'm also not entirely sure about this. For my use case, I have a lot of other setup that I do in my bash script (somewhat complicated sftp command where the destination, the backup paths, and several options are based on the hostname) so calling the restic binary itself wasn't an option. I can experiment with it a bit.

@armhold

This comment has been minimized.

Contributor

armhold commented Nov 28, 2018

OK, thanks for the explanation. I just tried rebuilding, rebooting + adding FDA, and I still get operation not permitted. Also tried moving both the binary wrapper and the shell script into /Applications, and no luck. I'll keep digging.

@n8henrie

This comment has been minimized.

n8henrie commented Nov 28, 2018

@armhold

This comment has been minimized.

Contributor

armhold commented Nov 29, 2018

I'm on 10.14.1 (18B75). I tried the tccutil command too, no luck. I understand why Apple is doing this, but it really is frustrating to not have a clear path about what to do here.

@n8henrie

This comment has been minimized.

n8henrie commented Nov 29, 2018

@armhold

This comment has been minimized.

Contributor

armhold commented Nov 29, 2018

Oddly, I tried and I can't get the restic binary to work directly.

Yeah, that's what I don't understand. I don't see why the Go wrapper would succeed where the restic binary itself would fail. Something seems off.

can you post a copy of the exact bash script and Go code you're using and how you're running it?

Sure, here it is: https://github.com/armhold/restic-fda.

  • both the shell script and the go wrapper are installed in my ~/bin directory.
  • added ~/bin/restic-fda to FDA via System Preferences
  • I'm running restic-fda from a non-root user account interactively on the command line in Terminal. I get errors like: error: Open: open /Users/armhold/Library/Application Support/AddressBook: operation not permitted.
  • running as root (via sudo) fails similarly

I have not tried running it via launchctl.

@ionos

This comment has been minimized.

ionos commented Dec 5, 2018

Little Snitch, a firewall, does something similar - for outgoing connections, it would ask whether to allow "Terminal via restic" do make the connection (rather than just restic); i.e. Terminal.app being the primary one to grant permission to.

What I did in the end was to bundle my shell script as an app using Platypus, and granting FDA to that generated app. Then launch backups via Finder. Works so far.

launchctl will be the next step.

@n8henrie

This comment has been minimized.

n8henrie commented Dec 12, 2018

@armhold

This comment has been minimized.

Contributor

armhold commented Dec 12, 2018

Still does not work for me. I gave up and just gave Terminal FDA.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment