vorta Vorta only launches in root instead of a regular user

Description

Vorta only launches in root now instead of a regular user. I only need to backup my home directory + other folders that my user has access to, so I don't need root permissions. When it does launch via root, my configs are missing.

EDIT: As per troubleshooting with @goebbe (thanks again!), it appears that for version 0.10.3, schemaversion was set to version 22 instead of 23 even though both the sqlite columns were present in settings.db.

Steps to produce:

Launch Vorta via KDE Start Menu/Autostart, no error message. Launch via CLI, an error message appears (see below).
Launch vorta via root CLI, and the app launches, but no configs are present (I assume that's normal since I did my configs on my main user account).

Reproduction

[x] I tried to reproduce the issue.
[x] I was able to reproduce the issue.

OS

Arch Linux KDE (X11 and Wayland)

Version of Vorta

0.10.3

What did you install Vorta with?

Distribution package

Version of Borg

1.4.0

Logs

025-02-04 10:43:07,969 - root - CRITICAL - Uncaught exception, file a report at https://github.com/borgbase/vorta/issues/new/choose
Traceback (most recent call last)
  File "/usr/lib/python3.13/site-packages/peewee.py", line 3322, in execute_sql
    cursor.execute(sql, params or ())
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
sqlite3.OperationalError: duplicate column name: compaction_on

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/vorta", line 8, in <module>
    sys.exit(main())
             ~~~~^^
  File "/usr/lib/python3.13/site-packages/vorta/__main__.py", line 74, in main
    init_db(sqlite_db)
    ~~~~~~~^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/vorta/store/connection.py", line 91, in init_db
    run_migrations(current_schema, con)
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/vorta/store/migrations.py", line 254, in run_migrations
    _apply_schema_update(
    ~~~~~~~~~~~~~~~~~~~~^
        current_schema,
        ^^^^^^^^^^^^^^^
    ...<10 lines>...
        ),
        ^^
    )
    ^
  File "/usr/lib/python3.13/site-packages/vorta/store/migrations.py", line 272, in _apply_schema_update
    migrate(*operations)
    ~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/playhouse/migrate.py", line 944, in migrate
    operation.run()
    ~~~~~~~~~~~~~^^
  File "/usr/lib/python3.13/site-packages/playhouse/migrate.py", line 162, in run
    self._handle_result(method(*self.args, **kwargs))
    ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/playhouse/migrate.py", line 156, in _handle_result
    self._handle_result(item)
    ~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/usr/lib/python3.13/site-packages/playhouse/migrate.py", line 153, in _handle_result
    result.run()
    ~~~~~~~~~~^^
  File "/usr/lib/python3.13/site-packages/playhouse/migrate.py", line 162, in run
    self._handle_result(method(*self.args, **kwargs))
    ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/playhouse/migrate.py", line 151, in _handle_result
    self.execute(result)
    ~~~~~~~~~~~~^^^^^^^^
  File "/usr/lib/python3.13/site-packages/playhouse/migrate.py", line 147, in execute
    self.migrator.database.execute(node)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/usr/lib/python3.13/site-packages/peewee.py", line 3330, in execute
    return self.execute_sql(sql, params)
           ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/peewee.py", line 3320, in execute_sql
    with __exception_wrapper__:
         ^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/peewee.py", line 3088, in __exit__
    reraise(new_type, new_type(exc_value, *exc_args), traceback)
    ~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/peewee.py", line 196, in reraise
    raise value.with_traceback(tb)
  File "/usr/lib/python3.13/site-packages/peewee.py", line 3322, in execute_sql
    cursor.execute(sql, params or ())
    ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
peewee.OperationalError: duplicate column name: compaction_on

Feb 04 '25 16:02 akmijares

I only need to backup my home directory + other folders that my user has access to, so I don't need root permissions.

Just for correctness: You would not need root access to backup sys files. As user you have reading rights and that's all you need for the backup src.

but no configs are present (I assume that's normal...

Yes. Every user has his own cfg and root has none.

To add your OS and KDE version could possibly helpful.
Could you use Vorta before this problem normally?

Feb 05 '25 11:02 madeddy

@akmijares Interpreting your error message: Apparently, the error occurs when Vorta tries to migrate the internal Sqlite data-structure for Vorta 0.10.3. It seems that your current_schema.version < 23 Therefore, Vorta tries to add new data columns for compaction: "'compaction_on'" The error occurs, since apparently the column "compaction_on" already exists in your Sqlite dataset.
So it seems that Sqlite has already been migrated but the schema.version has not been updated/ saved as expected.

Could you please export and upload the Vorta profile?
Before uploading, please check that the profile does not contain password - or other confidential information.

Feb 05 '25 13:02 goebbe

I only need to backup my home directory + other folders that my user has access to, so I don't need root permissions.

Just for correctness: You would not need root access to backup sys files. As user you have reading rights and that's all you need for the backup src.

but no configs are present (I assume that's normal...

Yes. Every user has his own cfg and root has none.

To add your OS and KDE version could possibly helpful.

Could you use Vorta before this problem normally?

My apologies:

Operating System: Arch Linux KDE Plasma Version: 6.2.5 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.13.1-zen1-1-zen (64-bit)
Yes I was able to use Vorta normally before this issue occured.

@akmijares Interpreting your error message: Apparently, the error occurs when Vorta tries to migrate the internal Sqlite data-structure for Vorta 0.10.3. It seems that your current_schema.version < 23 Therefore, Vorta tries to add new data columns for compaction: "'compaction_on'" The error occurs, since apparently the column "compaction_on" already exists in your Sqlite dataset. So it seems that Sqlite has already been migrated but the schema.version has not been updated/ saved as expected.

Could you please export and upload the Vorta profile? Before uploading, please check that the profile does not contain password - or other confidential information.

Is there a way to export via shell? Since I can only launch vorta through root (sudo vorta), I can only export the profile through root, unless that's alright, as it won't contain any configs.

Feb 05 '25 14:02 akmijares

@akmijares Sorry, as far as I know there is no way to export the profiles from the shell.

Did you already try to start Vorta (as a user) with new settings?

first make a backup/ rename your users Vorta settings: ~/.local/share/Vorta
start Vorta (as a user)

Another thing you could check on your side:

copy the setting.db from ~/.local/share/Vorta
use sqlitebrowser (GUI) to open and "browse Data" (using the copy of your settings.db)
- In table 'schemaversion' check the version
- In table 'backupprofilemodel' check if columns 'compaction_on' and 'compaction_week' are present. Report here. :-)

If 'compaction_on' and 'compaction_week' are present, the schemaversion should be '23'.

Feb 05 '25 14:02 goebbe

@akmijares Sorry, as far as I know there is no way to export the profiles from the shell.

Did you already try to start Vorta (as a user) with new settings?

first make a backup/ rename your users Vorta settings: ~/.local/share/Vorta

start Vorta (as a user)

Another thing you could check on your side:

copy the setting.db from ~/.local/share/Vorta

use sqlitebrowser (GUI) to open and "browse Data" (using the copy of your settings.db)

In table 'schemaversion' check the version

In table 'backupprofilemodel' check if columns 'compaction_on' and 'compaction_week' are present. Report here. :-)

If 'compaction_on' and 'compaction_week' are present, the schemaversion should be '23'.

Okay so it looks like when I backed up the Vorta settings and launched Vorta as a clean slate it launches. Thanks for that troubleshooting step.

I checked the DB with sqlitebrowser, here's what I had:

schemaversion is 22
In backupprofilemodel, both columns are present.

I changed the schemaversion to 23, recopied the directory back to the original location, and I was able to relaunch the app, and my backups are now running as I type this. :)

I would want to close this as problem solved, but I feel like something caused the schemaversion to not upgrade. I did update my system a few weeks ago, so maybe something in the update process caused it to happen. Any ideas?

EDIT: One thing to mention, I did try updating a few more times over the past week or so to see if it would've fixed the issue but it did not.

Feb 05 '25 15:02 akmijares

@akmijares Nice to hear, that Vorta is running again!

I suggest keeping this issue open, for now.
Perhaps one of the developers can say something about how this can happen?

As far as I understand, the addition of the two new columns/ fields and the setting of version is normally done directly one after the other. Not sure how Vorta can succeed in adding the two new columns, but fail to update the version number?

My first suspicion was that this is some weird access control issues caused by different sudo/root/user settings directories. Of course this could also be bad luck: If Vorta/ sqlite crashes directly after creating the two new columns - the version would not be updated.

How did you install Vorta on your system? Pip? Flathub?

Feb 05 '25 15:02 goebbe

Perhaps you could update the description of this issue? "Update 0.10.3 - sqlite columns are added to settings.db, but version is not updated to 23" or something similar.

Feb 05 '25 15:02 goebbe

Sure, I'll edit the description.

I installed this via Arch's package manager (pacman).

Feb 05 '25 15:02 akmijares

Hello, I have a very similar problem. Initially, I tried to follow the instructions in this post (replacing the current settings.db with an older one), but that didn't work. I always got the same error message, which I posted here (goebbe pointed that out in the previous post). There I was directed to this discussion, and I found that the behaviour is the same: I can run vorta as root, and it will start as regular user if no settings.db is present in its system folder. However, I do not find the columns 'compaction_on' and 'compaction_week' in the table 'backupprofilemodel'. The schemaversion is set to 22, changed in January 2024. I now removed vorta from the system and reinstalled it. It started, but didn't have settings, even though I had placed a recent and fully stuffed settings.db in place. Somehow, my earlier settings are being erased. I found that this time, the columns 'compaction_on' and 'compaction_week' are there in the table 'backupprofilemodel', and schemaversion is set to 23. Hence I assume that it's the current version now. It will be a lot of work to get all settings back (a long list of file exclusions...). My system runs Manjaro testing with KDE Plasma 6.3.3.

Mar 21 '25 16:03 DrMartinus

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.

Jun 20 '25 02:06 github-actions[bot]

This issue was closed because it has been stalled for 7 days with no activity.

Jun 27 '25 02:06 github-actions[bot]