MY PROBLEM
All of my clients back up to a network folder over SMB using kopia UI v13.0. I had this running perfectly for years on a Windows server and have since moved over to Linux. It seemed all was well - everyone was able to connect to the new repo location, hosted on the Linux server (Proxmox/Debian) and back up just fine. However, I recently realized that after a maintenance run, the clients can’t reconnect to the repo. If they were already connected, they can continue to stay that way and fire off snapshots, but will sometimes get “permission denied” errors, indicating they can’t properly access a folder in the repo. However, once that client machine has to reboot (for example) and reconnect to the repo, it fails to connect with “Access is denied”
MORE DETAILS
I run a script on the Linux machine that connects to the repo which is mounted as a path /mnt/backups, then runs a verify, maintenance, then a send-to to copy the repo offsite. Maintenance in owned by root@backupper. On the old Windows server it was managed by Administrator@backupserver. After running the maintenance, the only way to get the clients to reconnect is to change the permissions on the repo directory, /mnt/backups (eg. chmod -R 777 /mnt/backups). But this will only work until the next maintenance run which again will lock them out.
How can I run maintenance without locking out my clients? Security / fine-grained permission control is not a concern to me on this system. If someone can get to that folder that has bad intentions, I’m already toast, and it’s just a backup. I would prefer to manually run maintenance with this verify>maintenance>send-to script, but if I have to go another way, I’m open to hearing about it.
Running Kopia snapshots on remote clients should only be done against a Kopia server, not a Kopia repo itself. This way, the Kopia server will be to the only one that operates on the repo and will perform all necessary maintenance on its own.
Probably the most likely issue is that kopia’s ownership or permissions on the index files keep changing between the time clients use and the time maintenance runs. You can also see who is the ownership & permissions of /mnt/backups/kopia.maintenance.f
and /mnt/backups/x*.f
IMO it sounds more like a samba type issue than a kopia issue. If you’re using samba, you can try looking into mapping the client’s usernames to a single unix username. Just an idea.
@budy - are you saying that in my case, my clients are also performing maintenance operations? I thought that was the point of declaring a maintenance owner. Do I have this confused? I’m going to sidestep the “you’re doing it wrong” comment, though I’m sure you’re generally correct with advising one should use Kopia Server for backing up multiple clients to a single repo. The real question from my perspective is: why is maintenance all of the sudden changing the permissions of the content of my repo? Is this normal and why was it never an issue before?
@elel - thanks for the thoughts. I have since looked into the permissions side of things further (see below), but need to check the samba config and see what can be done there. If I can’t stop maintenance from changing permissions, then maybe there is a samba-related solution in mapping the clients to the owner so even when maintenance restricts permissions, the clients can still get to the files. I’m not familiar with mapping one username to another, but I can look into it. My original (and historical) approach for this specific repo has always been keeping permissions completely open and I never had any issues.
Some updates - after further investigation on what is actually happening to the repo contents, I can connect and back up and delete as much as I want from any client without any permissions changes on the actual data in the repo. But, it looks like every folder and file maintenance touches is changing from 777 (anyone can r/w) to 755 (only owner can write, everyone else can only read) and the maintenance file itself, kopia.maintenance.f is changing to 600 (owner r/w only). So then when a client goes to reconnect, it hits a permission wall in trying to access one of those files and errors out.
I actually don’t know, if the maintenance owner setting applies to cases, where a local Kopia process engages with a repo, which is - from its perspective a local one. If that’s the case, it should be fine and I’d also assume, that you can fix the posix permissions using something like directory mask = 2777 in your smb.conf.