Evaluating Kopia to see if it be a good fit for me but running into issues with a fresh test repository on a network share. I cannot open it immediately after creating it.
I am uncertain if this issue is due to the way Kopia is writing data to the network share or something with the NAS or share configuration that Kopia doesn’t play nice with. I’m stumped on where to look next.
Firstly, some context…
NAS: = Unraid 6.12.14 Windows PC: Windows 11 Macbook Pro: Sonoma 14.7.1
Clients:
Windows PC → NAS over SMB: Works
Macbook Pro → Local Repository: Works
Macbook Pro → NAS over SMB: Error below
Macbook Pro → NAS over NFS: Error below
Reading / writing to the shares from Finder on macOS works fine as it has for months. Connecting to the share vis NFS gives the same behaviour.
The error thrown by Kopia on macOS is: Connect Error: INTERNAL: internal server error: connect error: error opening repository: error connecting: unable to create shared content manager: error loading indexes: error downloading indexes: error loading index blob xn0_3a._9cacb68e0f6cf47c5ad21cc07b5465-sc3f779db1b82902e12f-c1: decrypt blob: unable to get index blob IV: invalid blob ID: xn0_3a._9cacb68e0f6cf47c5ad21cc07b5465
Did some quick reading and it seems this could be a permissions issue but no matter how I change permissions on the NAS it does not seem to solve the error. Unraid has a permissions ‘fixer’ tool which resets any oddball permissions to what they should be and although that has fixed other issues for me with shares it seems to do nothing for this case. The other odd thing is that Kopia clearly has write permissions since it was able to create the repository and even run snapshots without issue but it’s somehow unable to open the blob(s)? So perhaps it’s not a permissions issue?
I have a short video here showing the issue. Suggestions on what to try next?
Trust me I HATE how macOS does stuff like this with dot files. But at the same time I think it’s more of a failing of Kopia. I’d say a missing test scenario being that macOS is officially supported and this is likely a common setup for mac users. Heck even in the demo videos I’ve seen from the original developer he’s using a mac for the demo. So it kind of shocks me that this either wasn’t tested or was ignored. The dot files on mac has been a known issue, apparently, for well over a decade with all kinds of software. Example: How to stop ._ (dot dash) files being uploaded | The Dropbox Community.
Not trying to speak badly of the developer(s) or of Kopia, I think it’s a great product overall. Just pointing out that this seems to be par for the course when working with external file systems on Macs and should be accounted for.
Whether I / we agree with Apple’s approach to dot files is another conversation but it is what it is and Kopia should handle it more gracefully. Having a hard and misleading error like that its really tough from a user perspective and may drive new / non-technical users away. Having a more clear error or at least having it documented somewhere that this is a known issue would be great.
I have seen some quirky behavior with other programs before regarding dot files but having it hard error in a catastrophic way like this is surprising.
But even if working with kopia I think that SFTP (or WEBDAV etc.) is better choice for NAS based backup. Does not require extra step before running kopia (mounting SMB/NFS) and works over WAN (this maybe only applies to laptops).
Also… NFS /WebDAV are notoriously slow when dealing with lots of files… and this is only partly Apple’s doing… So whenever I can get to use something other than those, I’ll do it.