Where can I see the errors in KopiaUI?

[Blofgo]

Coming from Duplicati, I am now trying out Kopia. So far I am very impressed by the speed! For comparison: an incremental backup in Duplicati would take 22 minutes. That same incremental backup in Kopia is just 12 SECONDS!!! Crazy stuff

The killer feature for me is the option to mount a specific snapshot as a local filesystem. Not only does it allow me to cherrypick what files to restore, it also provides an easy means to double check I included the right directories in the backup policy.

The Kopia User Interface is a bit hard on the eyes, but I suppose real men use the CLI . In the Snapshots tab, it shows “something” went wrong:

Where can I see what went wrong? The warning icon is not clickable. The link in the Path column leads to a list of snapshots, but also there I can not find any error messages.

When I expand the notification MacOS gives me, it does not fit the space so I can not read what else it is saying. Clicking it will bring me back to the Snapshots tab without further details.

In the Tasks tab, I can see the logfile but not a clear message what went wrong. I could scroll the huge list to hunt for lines where {“errors”:0} is non-zero, but that can’t be the right way?!

Any idea how I can figure out what went wrong?

[Blofgo]

Screenshot of the (truncated?) notification:

[Christopher]

From the documentation

Logging

Kopia maintains diagnostic logging for troubleshooting purposes. This documents describes parameters that can be set to configure logging:

Log File Location

The location of log directory varies by operating system:

• On Linux - ~/.cache/kopia

• On macOS - ~/Library/Logs/kopia

• On Windows - %LocalAppData%\kopia

[basldfalksjdf]

The logging in KopiaUI is one thing that needs to be significantly improved. The only way to see the error log is by looking in the Tasks tab and scrolling that very large list. What makes it worse is that the logs will be discarded at some point by KopiaUI.

KopiaUI does not store logs on disk, so unfortunately you cannot go into a text editor to view it.

My suggestion would be to edit your policy and minimize logging so that you can better spot the errors when they happen.

[basldfalksjdf]

This is wrong. KopiaUI does not store logs on disk. Kopia CLI does.

[Blofgo]

Let’s see what we can find:

% cd ~/Library/Logs/kopia/cli-logs
% ls -lh
-rw-r--r--@ 1 user  staff   291B Nov 16 15:19 CACHEDIR.TAG
-rw-r--r--@ 1 user  staff    48M Nov 17 22:00 kopia-20251116-141902-18634-server-start.0.log
-rw-r--r--@ 1 user  staff    48M Nov 18 08:00 kopia-20251116-141902-18634-server-start.1.log
-rw-r--r--@ 1 user  staff    48M Nov 18 18:00 kopia-20251116-141902-18634-server-start.2.log
...

Right… The log files are HUGE! And deep in there are clues hidden to solve my puzzle?

Let’s see what we can “grep”:

% less kopia-20251116-141902-18634-server-start.2.log
2025-11-18T07:19:33.022890Z DEBUG scheduler triggering refresh
2025-11-18T07:19:33.025665Z ERROR connection connection closed: unrecognized error when opening SFTP file macmini/kopia.repository.f: connection lost, will retry
2025-11-18T07:19:33.025738Z DEBUG connection closing active connection.
2025-11-18T07:19:33.025782Z ERROR connection error closing active connection: error closing SFTP client: EOF
2025-11-18T07:19:33.025821Z DEBUG retry got error unrecognized error when opening SFTP file macmini/kopia.repository.f: connection lost when GetBlobFromPath (#0), sleeping for 100ms before retrying
2025-11-18T07:19:33.127900Z DEBUG connection establishing new connection...
2025-11-18T07:19:33.128062Z DEBUG sftp using internal SSH client
2025-11-18T07:19:35.719193Z DEBUG scheduler >>>> scheduling 3 items (now 2025-11-18T08:19:33+01:00)
2025-11-18T07:19:35.719358Z DEBUG scheduler   2025-11-18T12:19:33+01:00 refresh
2025-11-18T07:19:35.719404Z DEBUG scheduler   2025-11-18T08:42:11+01:00 maintenance
2025-11-18T07:19:35.719433Z DEBUG scheduler   2025-11-18T09:00:00+01:00 snapshot "/Users/yoriz"
2025-11-18T07:19:35.719459Z DEBUG scheduler sleeping until 2025-11-18T08:42:11+01:00 (maintenance)
...

So there are connection errors apparently? Interesting. Never got these with Duplicati so I wonder whether there are really connection problems, or incompatibilities with the behavior of my SFTP provider and Kopia. However, it seems to be able to (re-)connect after retrying.

What does this mean? Was the backup successful? Was the backup aborted?

The next error is more clear:

2025-11-18T08:00:02.335255Z DEBUG uploader snapshotted directory	{“path”:“Pictures/Photos Remote.photoslibrary”,“error”:“cannot create iterator: unable to read directory: open /Users/user/Pictures/Photos Remote.photoslibrary: operation not permitted”,“dur”:“66.584µs”}
2025-11-18T08:00:02.336413Z DEBUG uploader snapshotted directory	{“path”:“Pictures”,“dur”:“1.554041ms”,“size”:9535,“files”:2,“dirs”:6,“errors”:1}
2025-11-18T08:00:11.322698Z DEBUG uploader snapshotted directory	{“path”:“.”,“dur”:“9.068282834s”,“size”:133713551971,“files”:577889,“dirs”:22960,“errors”:1}

BTW, I love that the message uses proper SI-units (µs instead of us) . Well done.

So this looks like a locking/exclusive read problem. Is there a way to use the APFS snapshotting feature of MacOS? That would resolve these kinds of problems.

Looking through the log I see just these two problems repeating every hour. I will “fix” the second by adding an Exclude rule. How can I troubleshoot the first one (the connection problem)? Did it succeed or not?

P.S. Needless to say, the user feedback can be a bit improved upon. It would be great if the log could end with a conclusion: backup successful / only partially backed up due to errors / etc.