Borgmatic exits with error 105 #1256
Labels
No labels
blocked
breaking
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No milestone
No project
No assignees
3 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
borgmatic-collective/borgmatic#1256
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What I'm trying to do and why
I've recently started getting the following error when running
borgmaticfor backupborgmatic check --repairreturns nothing, nor does it resolve the issue.Steps to reproduce
It just started happening recently when I run
borgmatic --verbosity 1 --list --stats.Actual behavior
--verbosity 2output:Expected behavior
For borgmatic not to exit with an error
Other notes / implementation ideas
According to
borgmatic list, the backup archives do seem to be created, though I cannot attest to their contents being there.borgmatic version
2.1.0
borgmatic installation method
Arch packae
Borg version
borg 1.4.3
Python version
Python 3.14.2
Database version (if applicable)
N/A
Operating system and version
Arch Linux rolling
Exit code 105 is a Borg permission warning, meaning that it doesn't have permission to read some files that you're directing it to backup. I'd suggest looking at the rest of the log (and if necessary, upping the verbosity) to see what files those are.
Prior to borgmatic 2.1.0, those permissions warnings were swallowed silently. Now they result in the kind of error you're seeing so that you actually find out about files that aren't being backed up.
There are several ways to deal with the permission problem:
sudo/ as root. Then Borg should have permissions to read all files.source_directoriesthat your user doesn't have permission to read (or containing files that your user doesn't have permission to read).For that last option, it would look something like this in borgmatic's configuration:
Hope that helps!
Related: #1249
Just to clarify, will running borgmatic with elevated permissions not cause permission issues later down the line when accessing back-ups? That's my main concern with running
borgmaticwith elevated permissions.Yeah, that's a valid concern, and I wasn't necessarily recommending it as the best solution. Elevated permissions are just one possible approach, subject to your own needs (like how you want to access those backups as a non-privileged user). I think instead, I'd recommend trying to track down which files are having the permission problems, because that means they're not getting backed up. And if that's too much trouble and/or you don't actually care about those files, you can fall back to the
borg_exit_codesworkaround and they will continue being omitted from backups.I also hit this. Using
-v 2did not result in an explicit log pointing to the file triggering the permission error.I suspect that's a borg issue rather than a borgmatic issue?
The default output generated a list of files and directories, but that seemed to be the set of directories it decided needed to be backed up, and none of the files in that set had a permission issue. The issue was elsewhere.
Admittedly listing the first file to cause a problem would not help the user local all the files that pose a problem, but it would help the user discover the root cause faster.
Have you tried including
--list, so Borg outputs the list of files it's processing as it's processing them? Maybe that's what you mean by "generated a list of files and directories"? If so, the permission issue might occur near the last file listed, meaning that it might occur in the same directory or parent directory.I'm just speculating here though. I could maybe help if I saw your logs.
adding
--listdid not change the output noticeably. running as user aaaa. The list after "An error occurred" was there without--listand is mostly directories. I've checked and aaa has read access to all those files and directories.my difficulties debugging this were:
running as root fixes the problem, but feels like the nuclear option.
That's really odd. What version of borgmatic and Borg are you using? When I try a repro with borgmatic 2.1.3 and Borg 1.4.3, it looks like the following:
Notice that Borg's permission error (and the path in question) is getting surfaced.
https://synocommunity.com/package/borgbackup
The synovommunity package seems to be running 2.1.2 😿
2.1.2? That should be fine. I just confirmed the same behavior I described above with borgmatic 2.1.2. So something weird is going on. Are you able to run just Borg without borgmatic and see if that's also missing the permission denied message? You'd have to leave out the
--patterns-from+ path (since borgmatic creates that on the fly) and supply your own patterns on the command-line. Or do--patterns-fromwith your own temporary patterns file. Kind of a pain, I know.Also, I don't see
--verbosity 2in your command above. It'd be nice to include that to see if there's anything helpful, even though it shouldn't be necessary to get an error. And it'd also be good to confirm viaborgmatic --versionthat the version running is the version expected.When I run the underlying borg command I do get the error:
which is owned by root and is I presume a file synolgy universal search created to index the drive.
Okay, thanks for running that. I'm not sure why that error isn't showing up in the borgmatic output, but at least now you know what the problem file is. I recommend adding it to your excludes, since you don't have the permission to read it as a non-root user.
running the borg command with
2>&1 | grep "^E"generates a tidy list of trouble makers. I'm glad it doesn't give up early. It would be nice if that showed up in the borgmatic output, but there's something weird about the synocommunity package? maybe it'll resolve in the next package update.Thanks for your help. Sorry if I hijacked StandingPadAnimations's issue. Hopefully they will find this conversation helpful as well.