Hi,
I just realized that since I upgraded to macOS Sonoma the Library/Application Support directory can no longer be accessed by Kopia. I have not changed any settings. Full disk access is still enabled.
Has anyone else seen this behavior and knows how to give Kopia access to the directory again?
If you’re referring to the Application Support folder inside the user’s home - directory, that does work for me. I also verified that there are recent changes, which have been included into the snapshots.
Do you get any error message about that?
Yes, inside the home directory. ~/Library/Application Support.
The error in each of the snapshots of my home directory says:
Library/Application Support: operation not permitted
Try to remove and then grant Kopia full disk access again.
Done. I get the same error.
I don’t think it has anything to do with full disk access. If that was the issue, wouldn’t other folders be affected as well? It feels more like an extra layer of protection for this specific folder. But I don’t understand where that would come from.
Other then the reminders app, which lists Kopia as the only app, which is allowed to access its data inside the Application Support folder, I don’t know of any other.
You should also be getting a warning dialog, if Kopia cannot access some of your data. If that is not the case, your tcc database may be corrupted and you may needs to check it using the terminal.
What is a tcc database and how can I check it?
I get the same error. The whole folder ~/Application Support/ is not backed up with the message “operation not permitted”. It is due to the presence of the folder com.apple.LaunchServicesTemplateApp.dv inside ~/Application Support/.
I read on various forum that this folder is created by Apple when someone creates a Web app from inside Safari (icon Export … Add to the Dock).
It is not a problem to not backup this small folder. The big problem is that the whole ~/Application support/ is not backed up. In my case it contains more 20 GB of emails!
Does someone have a solution?
Did you enable full disk access for Kopia?
Of course! In fact, my backup was running correctly until recently. I read on the Internet that this is due to the creation of a Web app in Safari and I did it more or less at the same time I realised I had a problem with Kopia.
The specific folder com.apple.LaunchServicesTemplateApp.dv is locked by macOS and no-one can modify or delete it. The solution would be to skip it when it is declared in the Kopia policy. This is what I made but it did not prevent Kopia to stop backing up the whole parent folder.
I discovered this issue when I needed to restore something from the Application Support directory and saw it wasn’t in the backup at all.
Is there a fix or work around? Surely more people must have this issue but they just haven’t discovered yet that their backups are incomplete.
Like cricri this worked fine until a point where I probably created a web app. The kopia app already has full permission.
It does not need any fix or workaround - it just needs to do the backup setup job right.
The root cause is very simple here - backing up live data. And on macOS Library/Application Support is probably the worst directory to attempt to do it. If you are backing up your cat pictures dir from Documents then only risk is data corruption/inconsistency but Library is busy with system and apps doing there all sort of stuff constantly. And unfortunately some locked files can even cause all snapshot to fail.
Here good summary why it is bad idea to backup live data:
And there are not really excuses on macOS beyond being lazy for not doing it right.
File system snapshots are supported by APFS and kopia can make use of them in very easy way.
Here for reference my two scripts I use as kopia snapshot actions:
BEFORE:
#!/bin/bash
# https://kopia.io/docs/advanced/actions/#action-environment
# When kopia invokes Before actions,
# it passes the following parameter (more in docs):
# Variable Description
# KOPIA_SNAPSHOT_ID Random 64-bit number
# KOPIA_SOURCE_PATH Path being snapshotted
# The action command can modify the contents source directory in place
# or it can request other directory be snapshotted instead by printing a line to standard output:
# KOPIA_SNAPSHOT_PATH=<new-directory>
# Exit on error
set -o errexit
VOLUME_PATH="/System/Volumes/Data"
SNAP_DATE=$(/usr/bin/tmutil snapshot "$VOLUME_PATH" | /usr/bin/tail -n1 | /usr/bin/sed s/'Created local snapshot with date: '//)
LOCAL_MOUNTPOINT=/tmp/kopia_snapshot_"$KOPIA_SNAPSHOT_ID"
mkdir "$LOCAL_MOUNTPOINT" || true
umount "$LOCAL_MOUNTPOINT" || true
# for this to work add "Full Disk Access" for "Kopia UI"
/sbin/mount -t apfs -o nobrowse,-r,-s="com.apple.TimeMachine.${SNAP_DATE}.local" "$VOLUME_PATH" "$LOCAL_MOUNTPOINT"
echo KOPIA_SNAPSHOT_PATH="$LOCAL_MOUNTPOINT"/"$KOPIA_SOURCE_PATH"
AFTER:
#!/bin/bash
# https://kopia.io/docs/advanced/actions/#action-environment
# When kopia invokes After actions,
# it passes the following parameter (more in docs):
# Variable Description
# KOPIA_SNAPSHOT_ID Random 64-bit number
# Exit on error
set -o errexit
LOCAL_MOUNTPOINT=/tmp/kopia_snapshot_"$KOPIA_SNAPSHOT_ID"
umount "$LOCAL_MOUNTPOINT" || true
rm -rf "$LOCAL_MOUNTPOINT" || true
configured in kopia UI:
and do not forget to enable actions - they are off by default. You can not do this via GUI. As per docs:
When using KopiaUI, actions can be enabled globally by editing your repository.config (it is located in the
Config Filelocation in KopiaUI underRepository) and change"enableActions": falseto"enableActions": true. Save the file and restart KopiaUI.
Do above when kopia is not running.
on latest Sonoma I have tested backing up Library/Application Support with filesystem snapshots.
Out of the box kopia snapshot is created with few errors - either because some items are owned by root or are not regular files e.g. sockets. What is important here is that backup is created regardless - just problematic items are skipped.
To get fully error free backup I had to exclude:
me.hide.macapp
Adobe/Acrobat/DC/Reader/Synchronizer/Notification
Adobe/Acrobat/DC/Reader/Synchronizer/Commands
FileProvider
iTerm2/iterm2
It can be different for other configurations. To get all problematic items easily change temporarily logging level in policies to 0 (no output) and then instead of hundreds or thousands lines only errors will be printed.
PS. In real life scenario you should exclude much much more:) Caches, logs, temp folders etc. But it is a bit different subject.
My ramble about using filesystem snapshots stands and I strongly recommend to use it but it DOES NOT fix the issue with com.apple.LaunchServicesTemplateApp.dv dir unfortunately. Only discovered it after more careful investigation.
It is something only some of macOS user experience as this dir is created when Web Apps were used - here more detailed explanation what it is - How do Sonoma’s Web Apps work? – The Eclectic Light Company. If never used it does not exist and kopia works.
It is SIP protected and indeed breaks ~/Library/Application Support backup in kopia.
No solution at the moment exist AFAIK. I would hope Apple will rectify it at some stage as it is very strange to SIP protect items in user home directory. It breaks many other programs - not only kopia.
EDIT - as it broke my other backup software I needed fix ASAP, below worked for me:
~/Library/Application Support/com.apple.LaunchServicesTemplateApp.dvWeb Apps!!! or maybe only when Apple changes way how they implement itPlease note that with SIP enabled you can not even see this pesky dir, the clue that it exist is:
ls ~/Library/Application\ Support/com.apple.LaunchServicesTemplateApp.dv
operation not permitted
if it does not exist you will see:
$ ls ~/Library/Application\ Support/com.apple.LaunchServicesTemplateApp.dv
ls: /Users/kptsky/Library/Application Support/com.apple.LaunchServicesTemplateApp.dv: No such file or directory
I used your suggestion with SIP and it worked. Ican now backup
~/Library/Application Support
Thank you for the workaround.