Fail when a configuration file is a symlink with a relative path

pierreay commented

2026-04-06 18:25:00 +00:00

What I'm trying to do and why

Hi,

Since a few weeks, my borgmatic configuration is throwing error messages and failing, without any change on my side except an update. I think it happens since the 2.1.3 release. I'm sure that my configuration worked for years before. I discovered that the bug is happening only when a configuration file read by Borg is a symlink using a relative path (not absolute path). See the following for reproduction and output.

P.S.: I'm a bit surprised this has not been reported before (I searched for), because I thought having symlinked configuration file is pretty common. Is there something specific to my system?

Thank you for the hard work!

Steps to reproduce

Prepare a temporary source and destination directories:

mkdir -p /tmp/source /tmp/destination

Init a borg repository inside the destination:

borg init --encryption=repokey /tmp/destination

Create a configuration file my-backup.yaml containing the bare minimum to make a backup:

cat << EOF > ~/.config/borgmatic.d/my-backup.yaml
source_directories:
    - /tmp/source
repositories:
    - path: /tmp/destination
EOF

Run the backup and observe the expected behavior (output below):

cd /tmp && borgmatic create --stats --repository /tmp/destination/

Let's reproduce the bug now. Move the previous YAML configuration file to another directory where it will not be loaded automatically:

mv ~/.config/borgmatic.d/my-backup.yaml ~/.config/borgmatic/

Create a symlink to our YAML file using a relative path in the directory where borgmatic loads it configuration:

ln -sfT ../borgmatic/my-backup.yaml ~/.config/borgmatic.d/my-backup.yaml

Run the backup and observe the actual behavior (output below):

cd /tmp && borgmatic create --stats --repository /tmp/destination/

Another test, change the working directory directory and run the backup again:

cd && borgmatic create --stats --repository /tmp/destination/

Instead of having /borgmatic/my-backup.yaml as the path to which borgmatic tries to access, we have /home/borgmatic/my-backup.yaml.

Final test, if we use an absolute path in the symlink, this does not fail and we have the expected behavior:

ln -sfT ~/.config/borgmatic/my-backup.yaml ~/.config/borgmatic.d/my-backup.yaml

Actual behavior

/tmp/destination: Error running actions for repository
/tmp/destination: Source directories or root pattern paths do not exist: /borgmatic/my-backup.yaml
/home/USER/.config/borgmatic.d/my-backup.yaml: Error running configuration
/home/USER/.config/borgmatic.d/my-backup.yaml: An error occurred

summary:
An error occurred
Error running actions for repository
Source directories or root pattern paths do not exist: /borgmatic/my-backup.yaml
Error running configuration

Expected behavior

Repository: /tmp/destination
Archive name: HOSTNAME-2026-04-06T19:46:06.640026
Archive fingerprint: df14ff0aca32728357f994687bb6554ad8bef0302369a2dc6d7171080270fff8
Time (start): Mon, 2026-04-06 19:46:06
Time (end):   Mon, 2026-04-06 19:46:06
Duration: 0.01 seconds
Number of files: 2
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:                  178 B                243 B                109 B
All archives:               77.95 MB             60.52 MB             20.76 MB

                       Unique chunks         Total chunks
Chunk index:                    1573                 6980
------------------------------------------------------------------------------

Other notes / implementation ideas

No response

borgmatic version

2.1.3

borgmatic installation method

Arch package

Borg version

1.4.4

Python version

3.14.3

Database version (if applicable)

No response

Operating system and version

ArchLinux

### What I'm trying to do and why Hi, Since a few weeks, my borgmatic configuration is throwing error messages and failing, without any change on my side except an update. I think it happens since the [2.1.3 release](https://github.com/borgmatic-collective/borgmatic/releases/tag/2.1.3). I'm sure that my configuration worked for years before. I discovered that the bug is happening only when a configuration file read by Borg is a symlink using a relative path (not absolute path). See the following for reproduction and output. P.S.: I'm a bit surprised this has not been reported before (I searched for), because I thought having symlinked configuration file is pretty common. Is there something specific to my system? Thank you for the hard work! ### Steps to reproduce 1. Prepare a temporary source and destination directories: ``` mkdir -p /tmp/source /tmp/destination ``` 2. Init a borg repository inside the destination: ``` borg init --encryption=repokey /tmp/destination ``` 3. Create a configuration file `my-backup.yaml` containing the bare minimum to make a backup: ``` cat << EOF > ~/.config/borgmatic.d/my-backup.yaml source_directories: - /tmp/source repositories: - path: /tmp/destination EOF ``` 4. Run the backup and observe the expected behavior (output below): ``` cd /tmp && borgmatic create --stats --repository /tmp/destination/ ``` 5. Let's reproduce the bug now. Move the previous YAML configuration file to another directory where it will not be loaded automatically: ``` mv ~/.config/borgmatic.d/my-backup.yaml ~/.config/borgmatic/ ``` 6. Create a symlink to our YAML file using a relative path in the directory where borgmatic loads it configuration: ``` ln -sfT ../borgmatic/my-backup.yaml ~/.config/borgmatic.d/my-backup.yaml ``` 7. Run the backup and observe the actual behavior (output below): ``` cd /tmp && borgmatic create --stats --repository /tmp/destination/ ``` 8. Another test, change the working directory directory and run the backup again: ``` cd && borgmatic create --stats --repository /tmp/destination/ ``` Instead of having `/borgmatic/my-backup.yaml` as the path to which borgmatic tries to access, we have `/home/borgmatic/my-backup.yaml`. 9. Final test, if we use an absolute path in the symlink, this does not fail and we have the expected behavior: ``` ln -sfT ~/.config/borgmatic/my-backup.yaml ~/.config/borgmatic.d/my-backup.yaml ``` ### Actual behavior ``` /tmp/destination: Error running actions for repository /tmp/destination: Source directories or root pattern paths do not exist: /borgmatic/my-backup.yaml /home/USER/.config/borgmatic.d/my-backup.yaml: Error running configuration /home/USER/.config/borgmatic.d/my-backup.yaml: An error occurred summary: An error occurred Error running actions for repository Source directories or root pattern paths do not exist: /borgmatic/my-backup.yaml Error running configuration ``` ### Expected behavior ``` Repository: /tmp/destination Archive name: HOSTNAME-2026-04-06T19:46:06.640026 Archive fingerprint: df14ff0aca32728357f994687bb6554ad8bef0302369a2dc6d7171080270fff8 Time (start): Mon, 2026-04-06 19:46:06 Time (end): Mon, 2026-04-06 19:46:06 Duration: 0.01 seconds Number of files: 2 Utilization of max. archive size: 0% ------------------------------------------------------------------------------ Original size Compressed size Deduplicated size This archive: 178 B 243 B 109 B All archives: 77.95 MB 60.52 MB 20.76 MB Unique chunks Total chunks Chunk index: 1573 6980 ------------------------------------------------------------------------------ ``` ### Other notes / implementation ideas _No response_ ### borgmatic version 2.1.3 ### borgmatic installation method Arch package ### Borg version 1.4.4 ### Python version 3.14.3 ### Database version (if applicable) _No response_ ### Operating system and version ArchLinux

witten commented

2026-04-06 22:20:42 +00:00

Owner

Thanks for filing this with all the reproduction steps! I'm able to reproduce it here on borgmatic 2.1.3 and 2.1.4. My guess is that this is a regression introduced in 2.1.3 by #1248. I'll have a look when I get a chance.

witten added the

bug

label

2026-04-06 22:20:49 +00:00

witten referenced this issue from a commit

2026-04-06 23:04:04 +00:00

Fix a "source directories do not exist" regression when configuration paths are relative symlinks and the bootstrap data source hook is enabled (#1292).

witten commented

2026-04-06 23:05:10 +00:00

Owner

Looks like this regression was actually made in #1270 (and then probably surfaced via #1248). The #1270 change simply didn't work with configuration paths that were relative symlinks. The good news: Now it does work, because this is fixed in main and will be part of the next release!

In the meantime, a workaround might be to set source_directories_must_exist: false. However then you'd be giving up that feature for the time being and you still might get some annoying warnings (but no errors). And then the bootstrap action won't work for these config files until you have the actual fix.

Another (better?) temporary workaround might be to disable the "bootstrap" data source hook in configuration.

Looks like this regression was actually made in #1270 (and then probably surfaced via #1248). The #1270 change simply didn't work with configuration paths that were _relative_ symlinks. The good news: Now it does work, because this is fixed in main and will be part of the next release! In the meantime, a workaround might be to set `source_directories_must_exist: false`. However then you'd be giving up that feature for the time being and you still might get some annoying warnings (but no errors). And then the `bootstrap` action won't work for these config files until you have the actual fix. Another (better?) temporary workaround might be to disable the ["bootstrap" data source hook](https://torsion.org/borgmatic/reference/configuration/#bootstrap-option) in configuration.

❤️ 1

witten closed this issue

2026-04-06 23:05:10 +00:00

pierreay commented

2026-04-07 04:04:08 +00:00

Author

Thank you so much for the quick fix! I indeed used the source_directories_must_exist: false in the meantime. :) Cheers

Thank you so much for the quick fix! I indeed used the `source_directories_must_exist: false` in the meantime. :) Cheers

👍 1

witten commented

2026-04-20 17:33:49 +00:00

Owner