borgbase
Add the ability to specify the repository passphrase without unlinking and relinking
The problem
I upgraded my system from Kubuntu 20.04 to Kubuntu 24.04. I did a clean install, but I carefully brought all settings from the old home to the new one. I wanted to switch back from Vorta Flatpak (in 20.04) to Vorta deb (in 24.04) but couldn't, since Vorta in Ubuntu 20.04 repository is at version 0.8.12 and does not support compact scheduling yet. Additionally, the settings file for newer Vorta is not compatible with the old version.
Anyway, I reinstalled Vorta from Flatpak. All was there: my profiles, archive list, Vorta settings, etc. However, I can't execute commands because: "Your repo passphrase was stored in a password manager which is no longer available. Try unlinking and re-adding your repo." Not sure why the password manager settings were not brought along with all the other settings, possibly it's a security measure. Anyway, unlink and linking the repository again has consequences (like #245) and also it's a bit boring to add URL again, ensure any advanced property is set again (i.e.: ssh key, extra commands - you may also have forgot them - no way currently to "view" a linked repository settings right now) and ensure the backup profile is bound again to the new relinked repository (and not to another one by error - in case you have multiple repositories).
Requested Solution
Add a button to "relink" the existing repository in place, causing the passphrase prompt, just to store it again in the (new) password manager.
Alternatives
Prompt for the passphrase when executing some borg command and the link to the password manager is lost for any reason. No need for a new "relink" operation then. This will be even better, but possibly more intrusive (since there are many cases in which the passphrase is required by borg I guess).
Thanks for reporting the issue.
Probably Vorta documentation should add some additional comments about this use case, i.e. about transferring settings/ repository to a new computer/ install.
Here is what I would recommend:
- Do not downgrade Vorta - if only an older Version is provided by your distribution, either install the current Vorta version manually - or use the Flatpak (as before).
- On your old install, export the settings on a profile base (including passphrases!) Just select a profile and click on the "Export current profile" button - in the same pane.
- Transfer the exported settings to the new install (as described in the documentation) and import the profile settings via the
.vorta-init.jsonmethod. See: https://vorta.borgbase.com/usage/settings/
If done as described, the passphrases and all the setting can be transferred / reused.
Your attempt probably failed, since you just transferred the settings database - which does not include the passphrases. The passphrases are stored in the keyring/ password vault of your OS.
Yes indeed, but I thought I had also restored the keyring data. Anyway, that's my problem, not Vorta's. Improving the documentation is for sure a good thing, however I still believe that some improvement to the UI could be made. First of all because there are cases in which you can't access the old system (for example in case of a hardware crash), or just because a user would expect a flawless (or at least easy) restoration process when they restore the application settings data like it happens for all the other applications. Said in a different way, the user has to know that they should check the documentation since an export-import procedure before/after the home restore is needed for Vorta (unlike other apps).
Thanks for your feedback.
There has been some work on "changing the passphrase" by @VandalByte, recently. Perhaps this recent work can mitigate some of the current shortcomings in the GUI.
However, I am not sure if his code requires that a passphrase already exists in the keyring, or if the new feature can also be used to set (and save) a passphrase on a new computer, as described. (provided that you know your old passphrase)
However, I am not sure if his code requires that a passphrase already exists in the keyring, or if the new feature can also be used to set (and save) a passphrase on a new computer, as described. (provided that you know your old passphrase)
Actually yes, with the current implementation, it's required for the passphrase to exist in the keyring.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
I just upgraded Vorta from 0.10.3 to 0.11.1 from Flatpak yesterday, and now Vorta says that "Your repo passphrase was stored in a password manager which is no longer available. Try unlinking and re-adding your repo". But I did not change anything on my system!! Is there a way to fix this without unlinking and re-linking? :-(
Would love to help but not using a Linux desktop and all this code was contributed by others. 😕
So I don't know what goes on here, but you could just put the password into Vorta's own settings database. There should be a password column somewhere that may get picked up.
I just checked the settings.db using the sqlitebrowser, on LinuxMint: The "repopassword" table is completely empty on my Linux system - so I guess under Linux, this table is not used. Instead, the passwords/ passphrases for the repositories are saved in the keyring (a kind of OS-integrated password / secret manager)
The easiest way to create a new passphrase entry in the keyring via Vorta:
- Add an existing repository via Vorta: a) create a new profile b) add an "existing repository" via the "+" sign c) add info about URL/path, Repository Name and the Password of your repo. d) as soon as you click "Add", the corresponding password entry in the keyring should be created.
Please report if this works for you.
There is a setting to put passwords in the database instead of system keychain. In Settings / About > Security.
I just checked the settings.db using the sqlitebrowser, on LinuxMint: The "repopassword" table is completely empty on my Linux system - so I guess under Linux, this table is not used. Instead, the passwords/ passphrases for the repositories are saved in the keyring (a kind of OS-integrated password / secret manager)
The easiest way to create a new passphrase entry in the keyring via Vorta:
I'm not sure I can follow. I already have my repositories listed in Vorta and the passphrase is in the keyring (KWallet). But for some reason, after Vorta's update it can't access passphrases anymore, saying the password manager is no longer available.
Additionally, if I try to use the new feature to change the passphrase of a given repository, it says: "Unable to change the repository passphrase. Encryption type must be repokey".
Ok, I see now that the "passphrase change" feature was implemented only for repokey encryption: not sure why anyway, since borg seems to support the passphrase change also for keyfile encryption, indeed the example here is using keyfile: https://borgbackup.readthedocs.io/en/stable/usage/key.html#borg-key-change-passphrase
But anyway, I hoped that changing the passphrase could allow me to somehow trigger a new password manager prompt or something like that, but it's evident it does not. If I understand how this was implemented, I assume it anyway requires the old passphrase to be stored somewhere and accessible, because I don't think the old passphrase will be requested to the user.
Regarding the other proposals:
- @goebbe I'm not sure I understand what's the purpose of adding a new password to the keyring by adding a new repository; I need to make Vorta access the existing passphrase in the existing KWallet instance it was using before the upgrade, for an existing repository already listed in Vorta; in order to re-add the same the repository, I'm pretty sure I need to unlink and readd it, that is exactly what I'd like to avoid, for the reasons described in my original report
- @m3nu even if I switch from keyring to passwords saved in plain text into the Vorta DB (which is not ideal anyway), I wouldn't fix my problem; maybe it will help to prevent this problem from happening again in the future, but now I'd need again to unlink and re-add..
If I check the log I get this:
2025-12-17 20:06:30,086 - vorta.keyring.abc - DEBUG - No module named 'objc'
2025-12-17 20:06:30,087 - vorta.keyring.abc - DEBUG -
2025-12-17 20:06:30,091 - asyncio - DEBUG - Using selector: EpollSelector
2025-12-17 20:06:30,093 - vorta.keyring.abc - DEBUG - Using VortaSecretStorageKeyring
2025-12-17 20:06:30,093 - vorta.borg.borg_job - DEBUG - Using VortaSecretStorageKeyring keyring to store passwords.
2025-12-17 20:06:30,094 - asyncio - DEBUG - Using selector: EpollSelector
2025-12-17 20:06:30,095 - vorta.keyring.secretstorage - DEBUG - Found 0 passwords matching repo URL.
2025-12-17 20:06:30,096 - vorta.borg.borg_job - DEBUG - Password not found in primary keyring. Falling back to VortaDBKeyring.
2025-12-17 20:06:30,097 - vorta.notifications - DEBUG - notification not suppressed
So has anything changed in how Vorta tries to find the "primary keyring", between versions 0.10.3 and 0.11.1? Or maybe some change in how Vorta is packaged with Flatpak, which prevents it from accessing my KWallet...?
The 'blame' feature may be useful to view recent changes to KWallet?
https://github.com/borgbase/vorta/blame/master/src/vorta/keyring/kwallet.py
The 'blame' feature may be useful to view recent changes to KWallet?
https://github.com/borgbase/vorta/blame/master/src/vorta/keyring/kwallet.py
That source has been heavily modified around 3 weeks ago. But anyway, checking again the logs from Vorta, it seems like it's not using it to search for the password, it's using instead this class: https://github.com/borgbase/vorta/blob/master/src/vorta/keyring/secretstorage.py
TBH I don't know how this works. Is it possible that, for some reason, the newer version does not detect that we are in KDE and hence should use KWallet?
Indeed, the logs before the upgrading were showing something different:
2025-12-07 23:40:19,758 - vorta.keyring.abc - DEBUG - No module named 'objc'
2025-12-07 23:40:19,760 - vorta.keyring.abc - DEBUG - Using VortaKWallet5Keyring
2025-12-07 23:40:19,760 - vorta.borg.borg_job - DEBUG - Using VortaKWallet5Keyring keyring to store passwords.
2025-12-07 23:40:19,766 - vorta.keyring.kwallet - DEBUG - Retrieved password for repo [email protected]:/srv/dev-disk-by-uuid-f6280d17-6fef-460e-bb67-dfe3c26d87bf/backup/borg/hppb/mauro/home
2025-12-07 23:40:19,796 - vorta.scheduler - INFO - Preparation for backup successful.
So, in the old version vorta.keyring.abc was saying "Using VortaKWallet5Keyring", instead in latest version it says "Using VortaSecretStorageKeyring".
If I understand the code in vorta.keyring.abc right, it sorts keyrings by priority, and then chooses one. In this class, there's no change newer than 3-4 years ago. I checked the assigned priorities for KWallet and SecretStorage implementations, and these are still dating to 4 years ago. The choice is made based on the contents of the XDG_CURRENT_DESKTOP environment variable. If I open a terminal in my system, I get KDE, so it should give higher priority to the former.
What I do not know is whether inside the Flatpak sandbox, this environment variable is still KDE, because if it were GNOME now, for some reason, then this would explain the change in behavior.
UPDATE: I tried to run Vorta with this:
/usr/bin/flatpak run --env=XDG_CURRENT_DESKTOP=KDE com.borgbase.Vorta
just to make sure that the environment variable XDG_CURRENT_DESKTOP is set correctly. Still, it tries to use the Gnome keyring instead of KWallet...
Ok, after some trial and error, changing the Vorta Python code directly in the Flatpak, I came to the conclusion that:
- whatever priority I give to the KWallet implementation, it's skipped and ignored
- probably some error in the KWallet implementation initialization exists, and this is reflected by the second line of the log:
2025-12-17 20:06:30,086 - vorta.keyring.abc - DEBUG - No module named 'objc'
THIS ONE ===> 2025-12-17 20:06:30,087 - vorta.keyring.abc - DEBUG -
2025-12-17 20:06:30,091 - asyncio - DEBUG - Using selector: EpollSelector
2025-12-17 20:06:30,093 - vorta.keyring.abc - DEBUG - Using VortaSecretStorageKeyring
which must be produced by this line: https://github.com/borgbase/vorta/blob/master/src/vorta/keyring/abc.py#L28 some, some exception while trying to load the KWallet implementation with en empty error message. I hope this information is enough for you to create a new bug and fix it.
* [@goebbe](https://github.com/goebbe) I'm not sure I understand what's the purpose of adding a new password to the keyring by adding a new repository; I need to make Vorta access the existing passphrase in the existing KWallet instance it was using before the upgrade, for an existing repository already listed in Vorta; in order to re-add the same the repository, I'm pretty sure I need to unlink and readd it, that is exactly what I'd like to avoid, for the reasons described in my original report
Sorry for the confusion - this was about testing if you could add and access the already existing repository with the old password - and store the password in the kde-keyring. The aim was twofold:
- check if you can access/ read/ write to the keyring from Vorta on Kubuntu 24.04 at all
- point out a possible way how one could get access to the repository via Vorta, when the password is not transferred or accessible via the keyring.
There are pitfalls when transferring/using an old keyring (just a file) to a new system, and reading about the security goals of the gnome keyring it appears this is intentional. For example, nobody should be able to get access to the secrets of the old keyring by just transferring the file to another computer and just using the same username.
@mauromol Is your system configured to unlock the keyring (automatically) when logging in? Can you access the keyring and secrets using the kwalletmanager on kubuntu 24.04? I just learned that on kde you can allow/restrict access to the keyring on an application basis, but I guess you checked that route already. (this is from the docs, I don't use kde)
Hi @goebbe , the keyring is for sure accessible using the KWalletManager. The problem lies in Vorta, as described in my previous comment: https://github.com/borgbase/vorta/issues/2270#issuecomment-3667630482 Confirmation is that, if I replace kwallet.py with the version from 10.3, stop and restart Vorta, I have my backups working again. So there's some regression in kwallet.py introduced in between 0.10.3 and 0.11.1. I'll open a separate bug for this.