Database Error prevents Signal-Desktop to start

ronidee commented 1 month ago

Using a supported version?

[X] I have searched searched open and closed issues for duplicates.
[X] I am using Signal-Desktop as provided by the Signal team, not a 3rd-party package.

Overall summary

Seemingly out of the blue Signal always shows a database error popup whenever I attempt to start the application. It prompts me to quit or to delete all data, i.e. I can't use Signal without deleting my data (which I'm trying to avoid).

Steps to reproduce

-

Expected result

-

Actual result

-

Screenshots

I receive this error when trying to start Signal:

When I click "Copy error and quit", sometimes this second error message appears: Screenshot from 2024-08-08 12-02-56

Signal version

7.19.0

Operating system

Ubuntu 23.10

Version of Signal on your phone

7.12.3

Link to debug log

https://pastebin.com/cnikkkFs

jenkniss commented 1 month ago

Thank you for logging this @ronidee

We are having this same issue across my office's signal users with v7.19.0. We are all unable to use Signal Desktop at the moment.
We have tried the Delete Data and Restart option which does not fix the issue.

ronidee commented 1 month ago

We are all unable to use Signal Desktop at the moment.

You won't have all your history, but you can try using signal-desktop-beta for the time being. Version 7.20.0~beta.1 works fine for me.

Firebug24k commented 1 month ago

This is affecting me too (Arch linux). I tried downgrading to an older version but they also fail.

{"level":40,"time":"2024-08-10T14:27:40.269Z","msg":"MainSQL: Database log code=26: file is not a database in \"PRAGMA journal_mode = WAL\""} {"level":30,"time":"2024-08-10T14:27:40.269Z","msg":"MainSQL: migrateDatabase: Migration without cipher change failed"} {"level":40,"time":"2024-08-10T14:27:40.269Z","msg":"MainSQL: Database log code=26: statement aborts at 2: [PRAGMA user_version] file is not a database"} {"level":50,"time":"2024-08-10T14:27:40.269Z","msg":"MainSQL: Database startup error: SqliteError: file is not a database\n at Database.pragma ([REDACTED]/node_modules/@signalapp/better-sqlite3/lib/methods/pragma.js:11:31)\n at getUserVersion ([REDACTED]/ts/sql/util.js:132:13)\n at migrateSchemaVersion ([REDACTED]/ts/sql/Server.js:383:54)\n at openAndMigrateDatabase ([REDACTED]/ts/sql/Server.js:414:3)\n at openAndSetUpSQLCipher ([REDACTED]/ts/sql/Server.js:429:14)\n at Object.initialize ([REDACTED]/ts/sql/Server.js:465:16)\n at MessagePort.<anonymous> ([REDACTED]/ts/sql/mainWorker.js:84:35)\n at [nodejs.internal.kHybridDispatch] (node:internal/event_target:826:20)\n at exports.emitMessage (node:internal/per_context/messageport:23:28)"} {"

scottnonnenberg-signal commented 1 month ago

@ronidee Thanks for providing your debug log. Based on these log lines, Signal Desktop successfully (as far as it understood) decrypted your database key via Electron's safeStorage APIs, but that key was incorrect. That then resulted in the 'file is not a database'/'code=26' error.

{"level":30,"time":"2024-08-09T11:32:48.316Z","msg":"getSQLKey: decrypting key"}
<no other database-related logging>
{"level":40,"time":"2024-08-09T11:32:48.536Z","msg":"MainSQL: Database log code=26: file is not a database in \"PRAGMA journal_mode = WAL\""}

My questions to all are:

How did you install Signal Desktop?
What desktop environment are you in, and has that changed recently? If you switch desktop environments, Signal Desktop won't have access to its previous privileged storage location.
Is there anything else that has changed recently on your system that might affect Signal Desktop's access to your privileged storage location?

ronidee commented 1 month ago

Hello, thank you for your reply!

I installed it via the "Linux (Debian-based) Install Instructions" presented on https://signal.org/de/download/#.
I'm using Gnome 45.2, it has not recently changed. Using it for years, only the version changes (obviously).
I can't think of anything. The password stayed the same.
I had booted to my Windows 11 partition intermediately. After returning to my GNU/Linux OS the next day it stopped working. I think this could indecate that a) some package update caused the error (I think I ran apt upgarde while Signal was still working) or b) that Windows messed something up. Or perhaps it's just coincidental.
Also I (nearly?) ran out of disk space for a few seconds while downloading a file and Signal was active during that. Could that be the cause too?

What should I do next?

Kind regards

ronidee

scottnonnenberg-signal commented 1 month ago

@ronidee If you could give us your logs from ~/.config/Signal/logs that would give us more historical context. Maybe you would be willing to provide those here or to support@signal.org?

jenkniss commented 1 month ago

Following up on our experience:

I was able to resolve this for myself and team with the following, which may or may not help others.

We are all running Rocky 9.4 and Gnome 40.10

NOTE: Some of us did have at least partial restore of messages and others did not, but all of us have had Signal Desktop running normally again since.

Obviously, use caution here if you are tying to retain all of your current messages this worked for what we need but may not end up being the optimal solution for you!

Verified that we had installed Signal via snap: which signal-desktop
Removed Signal Desktop with snap purge option: sudo snap remove --purge signal-desktop
Installed Flatpak: sudo dnf install flatpak
Added repo: flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
Re-installed Signal Desktop: flatpak install flathub org.signal.Signal

scottnonnenberg-signal commented 1 month ago

@jenkniss Moving from snap to flatpack worked for you - do you have any idea why? Perhaps it has something to do with how each of those systems mediates access to privileged storage locations used by Electron's safeStorage API?

jenkniss commented 1 month ago

Hmm... well this wont necessarily explain why snap has the issue vs flatpak that I can see but it definitely feels like something is up with the keys/db. Something is preventing the db from initializing (as we see in the error presented). I did notice this comment at line 1687 from commit e449702 which seems to fit the the error some of us are getting when I looked at sql.sqlCall's defined errors:

```// This should be the first awaited call in this function, otherwise
// `sql.sqlCall` will throw an uninitialized error instead of waiting for
// init to finish.```

There is a new await prior to that in the function.

I have not dug much deeper than that.

scottnonnenberg-signal commented 1 month ago

@jenkniss Please let us know if you find anything else interesting, especially differences between those two packages or details of your system.

I took a look at the code you pointed out, and in the latest version of main.ts you can see that it's the first await in that codepath - the function has returned by that point if that other await was hit: https://github.com/signalapp/Signal-Desktop/blob/00e6071b1df73b0b37f219a289678d226bee490c/app/main.ts#L1723-L1763

waynongithub commented 1 month ago

Same here. I migrated from linux mint 20.2 MATE to 21.3 MATE and Signal gives the same database error. I haven't tried linking to my phone because I'm afraid that would ruin any chance of keeping my chat history.

I did not have this issue migrating from linux mint 18.3 to 19.3 to 20.2. I also had no problems transferring Signal Desktop from one laptop to another (both running linux mint 20.3).

I installed Signal Desktop with the install instructions from https://signal.org/download Both installations run Signal 7.19.1

ddeberhar commented 1 month ago

Is there a way to back-up the key from the (Electron) safeStorage and restore it - say - after migrating e.g. to a different desktop, different distro/OS, or a new installation after a crash - along with the Signal folder (i.e. the desktop's history)?

In my main.log I have on one system:

{"level":30,"time":"2024-08-14T10:27:51.326Z","msg":"getSQLKey: decrypting key"}
...
{"level":30,"time":"2024-08-14T10:27:51.609Z","msg":"MainSQL: updateSchema:\n  Current user_version: 1120;\n  Most recent db schema: 1120;\n  SQLite version: 3.42.0;\n  SQLCipher version: 4.5.5 community;\n  (deprecated) schema_version: 486;\n"}

but on the other:

{"level":30,"time":"2024-08-14T10:36:00.929Z","msg":"getSQLKey: decrypting key"}
...
{"level":40,"time":"2024-08-14T10:36:02.033Z","msg":"MainSQL: Database log code=26: file is not a database in \"PRAGMA journal_mode = WAL\""}

(I used to mount the one Signal folder from a Veracrypt container on an external USB to the desktop or laptop, whichever I was just on - now I learned that the signal-dektop will start with it's history only on that single system which holds the key in the safeStorage; so I'm curious again how to do a backup and restore - similiar to what I can have Signal doing on Android with local backups.)

Many thanks, Dirk

vegantostada commented 1 month ago

See my comment on another thread https://github.com/signalapp/Signal-Desktop/issues/6944#issuecomment-2259575767

Firebug24k commented 1 month ago

I'm pretty sure vegantostada is on to something. Signal works fine if I delete my entire old DB and recreate it (but I've now sadly lost my entire 3 years of message history), the issue is something with the way the latest version is storing keys.

ddeberhar commented 1 month ago

My point is that I'd very much desire a supported and maintained solution over a temporary. From the various reports I got the impression that the safeStorage use may fail to decrypt the key correctly after any (Linux/Windows?) system upgrade - and definitely after a re-installation and plain restore of the "Signal/" folder. I'm not the only one who'd be unhappy losing all the history on the desktop.

Since things are evolving further, this workaround to temporarily store the key unencrypted before starting the Signal-desktop again with the folder placed to the new desired location, may work just until the next step in the developement.

And if I read the script right which vegantostada provided, it is for Windows - I'm not sure, to what it would resolve app.getpath('appdata') on linux - perhaps Signal-desktop just decided to use .config/Signal/ while it's e.g. .mozilla/firefox/ for the browser ("~" stands for /home/[username]/ and names starting with a dot are normally hidden).

waynongithub commented 4 weeks ago

For what it's worth, I restored access to the Signal database by replacing the keyring directory on my linux mint 21.3 installation with that of my linux mint 20.3.

sailbird commented 3 weeks ago

fracasula commented 2 weeks ago

Same here, fresh installation on OpenSuse Leap 15.6.

Installed via snap: https://snapcraft.io/signal-desktop

I installed it for the first time with no prior installation. I get the same error also when starting it from the command-line:

Set Windows Application User Model ID (AUMID) { AUMID: 'org.whispersystems.signal-desktop' }
NODE_ENV production
NODE_CONFIG_DIR /snap/signal-desktop/692/opt/Signal/resources/app.asar/config
NODE_CONFIG {}
ALLOW_CONFIG_MUTATIONS undefined
HOSTNAME nebuchadnezzar
NODE_APP_INSTANCE undefined
SUPPRESS_NO_CONFIG_WARNING undefined
SIGNAL_ENABLE_HTTP undefined
userData: /home/francesco/snap/signal-desktop/692/.config/Signal
config/get: Successfully read user config file
config/get: Successfully read ephemeral config file
making app single instance
Error org.freedesktop.DBus.Error.Failed: cannot find desktop file "/var/lib/snapd/desktop/applications/signal-desktop_signal.desktop"
Error org.freedesktop.DBus.Error.Failed: cannot find desktop file "/var/lib/snapd/desktop/applications/signal-desktop_signal.desktop"
libpxbackend-1.0.so: cannot open shared object file: No such file or directory
Failed to load module: /home/francesco/snap/signal-desktop/common/.cache/gio-modules/libgiolibproxy.so
/usr/share/libdrm/amdgpu.ids: No such file or directory
/usr/share/libdrm/amdgpu.ids: No such file or directory
{"level":30,"time":"2024-08-28T07:26:54.966Z","msg":"got fast localeOverride setting null"}
{"level":30,"time":"2024-08-28T07:26:54.967Z","msg":"app.ready: hour cycle preference: UnknownPreference"}
{"level":30,"time":"2024-08-28T07:26:54.967Z","msg":"app.ready: preferred system locales: en-GB, en"}
{"level":30,"time":"2024-08-28T07:26:54.967Z","msg":"locale: Supported locales: af-ZA, ar, az-AZ, bg-BG, bn-BD, bs-BA, ca, cs, da, de, el, en, es, et-EE, eu, fa-IR, fi, fr, ga-IE, gl-ES, gu-IN, he, hi-IN, hr-HR, hu, id, it, ja, ka-GE, kk-KZ, km-KH, kn-IN, ko, ky-KG, lt-LT, lv-LV, mk-MK, ml-IN, mr-IN, ms, my, nb, nl, pa-IN, pl, pt-BR, pt-PT, ro-RO, ru, sk-SK, sl-SI, sq-AL, sr, sv, sw, ta-IN, te-IN, th, tl-PH, tr, ug, uk-UA, ur, vi, yue, zh-CN, zh-HK, zh-Hant"}
{"level":30,"time":"2024-08-28T07:26:54.967Z","msg":"locale: Preferred locales: en-GB, en"}
{"level":30,"time":"2024-08-28T07:26:54.967Z","msg":"locale: Locale Override: null"}
{"level":30,"time":"2024-08-28T07:26:54.968Z","msg":"locale: Matched locale: en"}
{"level":40,"time":"2024-08-28T07:26:54.984Z","msg":"intl.onWarn [@formatjs/intl] \"defaultRichTextElements\" was specified but \"message\" was not pre-compiled. \nPlease consider using \"@formatjs/cli\" to pre-compile your messages for performance.\nFor more details see https://formatjs.io/docs/getting-started/message-distribution"}
/usr/share/libdrm/amdgpu.ids: No such file or directory
{"level":30,"time":"2024-08-28T07:26:54.984Z","msg":"locale: Text info direction for en: ltr"}
{"level":30,"time":"2024-08-28T07:26:54.984Z","msg":"getSQLKey: decrypting key"}
{"level":30,"time":"2024-08-28T07:26:54.985Z","msg":"getSystemTraySetting got value DoNotUseSystemTray"}
{"level":30,"time":"2024-08-28T07:26:54.985Z","msg":"getSystemTraySetting returning DoNotUseSystemTray"}
{"level":30,"time":"2024-08-28T07:26:54.985Z","msg":"app ready"}
{"level":30,"time":"2024-08-28T07:26:54.986Z","msg":"starting version 7.21.0"}
{"level":30,"time":"2024-08-28T07:26:54.986Z","msg":"media access status [object Undefined] [object Undefined]"}
{"level":30,"time":"2024-08-28T07:26:54.987Z","msg":"got fast theme-setting value system"}
{"level":30,"time":"2024-08-28T07:26:54.988Z","msg":"got fast theme-setting value system"}
{"level":30,"time":"2024-08-28T07:26:54.988Z","msg":"got fast spellcheck setting true"}
{"level":50,"time":"2024-08-28T07:26:54.988Z","msg":"visibleOnAnyScreen: windowOptions didn't have valid bounds fields"}
{"level":30,"time":"2024-08-28T07:26:54.988Z","msg":"Location reset needed"}
{"level":30,"time":"2024-08-28T07:26:54.988Z","msg":"Initializing BrowserWindow config: {\"show\":false,\"width\":800,\"height\":610,\"minWidth\":300,\"minHeight\":200,\"autoHideMenuBar\":false,\"titleBarStyle\":\"default\",\"backgroundColor\":\"#121212\",\"webPreferences\":{\"devTools\":false,\"spellcheck\":true,\"enableBlinkFeatures\":\"CSSPseudoDir,CSSLogical\",\"enablePreferredSizeMode\":true,\"nodeIntegration\":false,\"nodeIntegrationInWorker\":false,\"sandbox\":false,\"contextIsolation\":true,\"preload\":\"[REDACTED]/preload.bundle.js\",\"backgroundThrottling\":true,\"disableBlinkFeatures\":\"Accelerated2dCanvas,AcceleratedSmallCanvases\"},\"icon\":\"[REDACTED]/images/signal-logo-desktop-linux.png\"}"}
{"level":30,"time":"2024-08-28T07:26:55.015Z","msg":"spellcheck: user locales: [\"en-GB\",\"en\"]"}
{"level":30,"time":"2024-08-28T07:26:55.015Z","msg":"spellcheck: available spellchecker languages: [\"af\",\"bg\",\"ca\",\"cs\",\"cy\",\"da\",\"de\",\"de-DE\",\"el\",\"en\",\"en-AU\",\"en-CA\",\"en-GB\",\"en-GB-oxendict\",\"en-US\",\"es\",\"es-419\",\"es-AR\",\"es-ES\",\"es-MX\",\"es-US\",\"et\",\"fa\",\"fo\",\"fr\",\"fr-FR\",\"he\",\"hi\",\"hr\",\"hu\",\"hy\",\"id\",\"it\",\"it-IT\",\"ko\",\"lt\",\"lv\",\"nb\",\"nl\",\"pl\",\"pt\",\"pt-BR\",\"pt-PT\",\"ro\",\"ru\",\"sh\",\"sk\",\"sl\",\"sq\",\"sr\",\"sv\",\"ta\",\"tg\",\"tr\",\"uk\",\"vi\"]"}
{"level":30,"time":"2024-08-28T07:26:55.015Z","msg":"spellcheck: setting languages to: [\"en-GB\",\"en\"]"}
{"level":40,"time":"2024-08-28T07:26:55.129Z","msg":"MainSQL: Database log code=26: file is not a database in \"PRAGMA journal_mode = WAL\""}
{"level":30,"time":"2024-08-28T07:26:55.129Z","msg":"MainSQL: migrateDatabase: Migration without cipher change failed"}
{"level":40,"time":"2024-08-28T07:26:55.151Z","msg":"MainSQL: Database log code=26: statement aborts at 2: [PRAGMA user_version] file is not a database"}
{"level":50,"time":"2024-08-28T07:26:55.152Z","msg":"MainSQL: Database startup error: SqliteError: file is not a database\n    at Database.pragma ([REDACTED]/node_modules/@signalapp/better-sqlite3/lib/methods/pragma.js:11:31)\n    at getUserVersion ([REDACTED]/ts/sql/util.js:132:13)\n    at migrateSchemaVersion ([REDACTED]/ts/sql/Server.js:393:54)\n    at openAndMigrateDatabase ([REDACTED]/ts/sql/Server.js:425:5)\n    at openAndSetUpSQLCipher ([REDACTED]/ts/sql/Server.js:447:14)\n    at initialize ([REDACTED]/ts/sql/Server.js:485:10)\n    at MessagePort.<anonymous> ([REDACTED]/ts/sql/mainWorker.js:69:41)\n    at [nodejs.internal.kHybridDispatch] (node:internal/event_target:820:20)\n    at MessagePort.<anonymous> (node:internal/per_context/messageport:23:28)"}
{"level":50,"time":"2024-08-28T07:26:55.152Z","msg":"Failed to get zoom factor {\"name\":\"SqliteError\"}"}
{"level":30,"time":"2024-08-28T07:26:55.351Z","msg":"got fast theme-setting value system"}
{"level":50,"time":"2024-08-28T07:26:55.636Z","msg":"sql.initialize was unsuccessful; returning early"}
{"level":30,"time":"2024-08-28T07:26:55.637Z","msg":"close event {\"readyForShutdown\":false,\"shouldQuit\":false}"}
{"level":30,"time":"2024-08-28T07:26:55.637Z","msg":"maybeRequestCloseConfirmation: Checking to see if close confirmation is needed"}
{"level":50,"time":"2024-08-28T07:26:57.180Z","msg":"onDatabaseError: Quitting application"}
{"level":30,"time":"2024-08-28T07:26:57.180Z","msg":"main window closed event"}
{"level":30,"time":"2024-08-28T07:26:57.181Z","msg":"quit event {\"hasEventBeenPrevented\":false,\"windowCount\":0,\"mainWindowExists\":false}"}
{"level":50,"time":"2024-08-28T07:26:57.181Z","msg":"Error occurred in handler for 'sql-channel:read': {\"name\":\"SqliteError\"}"}

fracasula commented 2 weeks ago

Even if I delete everything under /home/francesco/snap/signal-desktop/692/.config/Signal and start from scratch, the moment I close the app and open it again, I get the error.

silvermar commented 2 weeks ago

Same problem here with snap version 7.21 in Fedora 40. The flatpak works fine but I'd prefer to use the snap install instead.

tuxcrafter commented 2 weeks ago

$ signal-desktop Set Windows Application User Model ID (AUMID) { AUMID: 'org.whispersystems.signal-desktop' } NODE_ENV production NODE_CONFIG_DIR /opt/Signal/resources/app.asar/config NODE_CONFIG {} ALLOW_CONFIG_MUTATIONS undefined HOSTNAME workstation04.bothends.lan NODE_APP_INSTANCE undefined SUPPRESS_NO_CONFIG_WARNING undefined SIGNAL_ENABLE_HTTP undefined userData: /home/j.doe/.config/Signal config/get: Successfully read user config file config/get: Successfully read ephemeral config file making app single instance {"level":30,"time":"2024-08-29T08:36:34.473Z","msg":"config/set: Saving ephemeral config to disk"} {"level":30,"time":"2024-08-29T08:36:34.488Z","msg":"config/set: Saved ephemeral config to disk"} {"level":30,"time":"2024-08-29T08:36:34.488Z","msg":"initializing localeOverride setting null"} {"level":30,"time":"2024-08-29T08:36:34.489Z","msg":"app.ready: hour cycle preference: UnknownPreference"} {"level":30,"time":"2024-08-29T08:36:34.489Z","msg":"app.ready: preferred system locales: en-US, en"} {"level":30,"time":"2024-08-29T08:36:34.489Z","msg":"locale: Supported locales: af-ZA, ar, az-AZ, bg-BG, bn-BD, bs-BA, ca, cs, da, de, el, en, es, et-EE, eu, fa-IR, fi, fr, ga-IE, gl-ES, gu-IN, he, hi-IN, hr-HR, hu, id, it, ja, ka-GE, kk-KZ, km-KH, kn-IN, ko, ky-KG, lt-LT, lv-LV, mk-MK, ml-IN, mr-IN, ms, my, nb, nl, pa-IN, pl, pt-BR, pt-PT, ro-RO, ru, sk-SK, sl-SI, sq-AL, sr, sv, sw, ta-IN, te-IN, th, tl-PH, tr, ug, uk-UA, ur, vi, yue, zh-CN, zh-HK, zh-Hant"} {"level":30,"time":"2024-08-29T08:36:34.489Z","msg":"locale: Preferred locales: en-US, en"} {"level":30,"time":"2024-08-29T08:36:34.489Z","msg":"locale: Locale Override: null"} {"level":30,"time":"2024-08-29T08:36:34.493Z","msg":"locale: Matched locale: en"} {"level":40,"time":"2024-08-29T08:36:34.538Z","msg":"intl.onWarn [@formatjs/intl] \"defaultRichTextElements\" was specified but \"message\" was not pre-compiled. \nPlease consider using \"@formatjs/cli\" to pre-compile your messages for performance.\nFor more details see https://formatjs.io/docs/getting-started/message-distribution"} {"level":30,"time":"2024-08-29T08:36:34.538Z","msg":"locale: Text info direction for en: ltr"} {"level":30,"time":"2024-08-29T08:36:34.539Z","msg":"getSQLKey: using legacy key"} {"level":30,"time":"2024-08-29T08:36:34.540Z","msg":"getSystemTraySetting got no value, returning Uninitialized"} {"level":30,"time":"2024-08-29T08:36:34.540Z","msg":"config/set: Saving ephemeral config to disk"} {"level":30,"time":"2024-08-29T08:36:34.550Z","msg":"config/set: Saved ephemeral config to disk"} {"level":30,"time":"2024-08-29T08:36:34.551Z","msg":"app.ready: setting system-tray-setting to DoNotUseSystemTray"} {"level":30,"time":"2024-08-29T08:36:34.551Z","msg":"config/set: Saving ephemeral config to disk"} {"level":30,"time":"2024-08-29T08:36:34.557Z","msg":"config/set: Saved ephemeral config to disk"} {"level":30,"time":"2024-08-29T08:36:34.561Z","msg":"app ready"} {"level":30,"time":"2024-08-29T08:36:34.562Z","msg":"starting version 7.22.0"} {"level":30,"time":"2024-08-29T08:36:34.562Z","msg":"media access status [object Undefined] [object Undefined]"} {"level":30,"time":"2024-08-29T08:36:34.595Z","msg":"config/set: Saving ephemeral config to disk"} {"level":30,"time":"2024-08-29T08:36:34.602Z","msg":"config/set: Saved ephemeral config to disk"} {"level":30,"time":"2024-08-29T08:36:34.602Z","msg":"saving theme-setting value system"} {"level":30,"time":"2024-08-29T08:36:34.602Z","msg":"config/set: Saving ephemeral config to disk"} {"level":30,"time":"2024-08-29T08:36:34.609Z","msg":"config/set: Saved ephemeral config to disk"} {"level":30,"time":"2024-08-29T08:36:34.609Z","msg":"initializing spellcheck setting true"} {"level":30,"time":"2024-08-29T08:36:34.611Z","msg":"Initializing BrowserWindow config: {\"show\":false,\"width\":800,\"height\":610,\"minWidth\":300,\"minHeight\":200,\"autoHideMenuBar\":false,\"titleBarStyle\":\"default\",\"backgroundColor\":\"#3a76f0\",\"webPreferences\":{\"devTools\":false,\"spellcheck\":true,\"enableBlinkFeatures\":\"CSSPseudoDir,CSSLogical\",\"enablePreferredSizeMode\":true,\"nodeIntegration\":false,\"nodeIntegrationInWorker\":false,\"sandbox\":false,\"contextIsolation\":true,\"preload\":\"[REDACTED]/preload.bundle.js\",\"backgroundThrottling\":true,\"disableBlinkFeatures\":\"Accelerated2dCanvas,AcceleratedSmallCanvases\"},\"icon\":\"[REDACTED]/images/signal-logo-desktop-linux.png\",\"x\":563,\"y\":228}"} {"level":30,"time":"2024-08-29T08:36:34.692Z","msg":"spellcheck: user locales: [\"en-US\",\"en\"]"} {"level":30,"time":"2024-08-29T08:36:34.692Z","msg":"spellcheck: available spellchecker languages: [\"af\",\"bg\",\"ca\",\"cs\",\"cy\",\"da\",\"de\",\"de-DE\",\"el\",\"en\",\"en-AU\",\"en-CA\",\"en-GB\",\"en-GB-oxendict\",\"en-US\",\"es\",\"es-419\",\"es-AR\",\"es-ES\",\"es-MX\",\"es-US\",\"et\",\"fa\",\"fo\",\"fr\",\"fr-FR\",\"he\",\"hi\",\"hr\",\"hu\",\"hy\",\"id\",\"it\",\"it-IT\",\"ko\",\"lt\",\"lv\",\"nb\",\"nl\",\"pl\",\"pt\",\"pt-BR\",\"pt-PT\",\"ro\",\"ru\",\"sh\",\"sk\",\"sl\",\"sq\",\"sr\",\"sv\",\"ta\",\"tg\",\"tr\",\"uk\",\"vi\"]"} {"level":30,"time":"2024-08-29T08:36:34.693Z","msg":"spellcheck: setting languages to: [\"en-US\",\"en\"]"} {"level":30,"time":"2024-08-29T08:36:34.695Z","msg":"spellcheck: dictionary initialized: en"} {"level":30,"time":"2024-08-29T08:36:34.699Z","msg":"spellcheck: dictionary initialized: en-US"} {"level":30,"time":"2024-08-29T08:36:34.752Z","msg":"MainSQL: migrateDatabase: Migration without cipher change failed"} {"level":50,"time":"2024-08-29T08:36:34.754Z","msg":"MainSQL: Database startup error: Error: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: versionGLIBCXX_3.4.29' not found (required by [REDACTED].unpacked/node_modules/@signalapp/better-sqlite3/build/Release/better_sqlite3.node)\n at process.func [as dlopen] (node:electron/js2c/node_init:2:2559)\n at Module._extensions..node (node:internal/modules/cjs/loader:1470:18)\n at Object.func [as .node] (node:electron/js2c/node_init:2:2786)\n at Module.load (node:internal/modules/cjs/loader:1215:32)\n at Module._load (node:internal/modules/cjs/loader:1031:12)\n at c._load (node:electron/js2c/node_init:2:17025)\n at Module.require (node:internal/modules/cjs/loader:1240:19)\n at require (node:internal/modules/helpers:179:18)\n at bindings ([REDACTED]/node_modules/bindings/bindings.js:112:48)\n at new Database ([REDACTED]/node_modules/@signalapp/better-sqlite3/lib/database.js:48:64)"} {"level":50,"time":"2024-08-29T08:36:34.755Z","msg":"Failed to get zoom factor {\"name\":\"Error\"}"} {"level":30,"time":"2024-08-29T08:36:35.313Z","msg":"got fast theme-setting value system"} {"level":50,"time":"2024-08-29T08:36:36.214Z","msg":"sql.initialize was unsuccessful; returning early"} {"level":30,"time":"2024-08-29T08:36:36.216Z","msg":"close event {\"readyForShutdown\":false,\"shouldQuit\":false}"} {"level":30,"time":"2024-08-29T08:36:36.216Z","msg":"maybeRequestCloseConfirmation: Checking to see if close confirmation is needed"} {"level":50,"time":"2024-08-29T08:36:45.510Z","msg":"onDatabaseError: Quitting application"} {"level":30,"time":"2024-08-29T08:36:45.513Z","msg":"main window closed event"} {"level":30,"time":"2024-08-29T08:36:45.514Z","msg":"quit event {\"hasEventBeenPrevented\":false,\"windowCount\":0,\"mainWindowExists\":false}"} {"level":50,"time":"2024-08-29T08:36:45.518Z","msg":"Error occurred in handler for 'sql-channel:read': {\"name\":\"Error\"}"} `

running on "Linux Mint 20 Ulyana" downgrading to 7.21.0 fixes the issue for me, looks like the new version was compiled against a newer EBI/API version of libstdc++ please release a new compatible version.

# apt-get install signal-desktop=7.21.0 Reading package lists... Done Building dependency tree Reading state information... Done The following packages will be DOWNGRADED: signal-desktop 0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded. Need to get 0 B/122 MB of archives. After this operation, 56,3 kB disk space will be freed. Do you want to continue? [Y/n] y dpkg: warning: downgrading signal-desktop from 7.22.0 to 7.21.0 (Reading database ... 436870 files and directories currently installed.) Preparing to unpack .../signal-desktop_7.21.0_amd64.deb ... Unpacking signal-desktop (7.21.0) over (7.22.0) ... Setting up signal-desktop (7.21.0) ... update-alternatives is /usr/bin/update-alternatives Error in file "/usr/share/applications/org.kde.kdeconnect_open.desktop": "*/*" is an invalid MIME type ("*" is an unregistered media type) Could not parse file "/usr/share/applications/screensavers/glitchpeg.desktop": Key file contains line ?several times a second. After a while, finds a new image to corrupt. Written by Jamie Zawinski; 2018.? which is not a key-value pair, group, or comment Processing triggers for mime-support (3.64ubuntu1) ... Processing triggers for hicolor-icon-theme (0.17-2) ... Processing triggers for desktop-file-utils (0.24+linuxmint1) ...

fracasula commented 2 weeks ago

Solved with flatpak install flathub org.signal.Signal on OpenSuse Leap 15.6, thanks @silvermar.

corsac-s commented 2 weeks ago

I started experiencing the issue just recently. I'm using Debian sid using the Debian package provided by Signal.org.

One notable thing is that I'm running signal-desktop through Firejail. When not doing that it seems to work fine. I think Snap/Flatpak variants might add some kind of sandboxing as well, so if it's indeed the same issue, maybe there's something to look at?

Maybe the new API requires an update of the Firejail/Snap/Flatpak sandboxing profiles?

corsac-s commented 1 week ago

Still the same error with version 7.23.0.

scottnonnenberg-signal commented 1 week ago

@corsac-s If Signal Desktop cannot access a consistently-available form of protected storage (or basic, if the system doesn't support it), it will save it database password somewhere which it cannot later access. That will cause the errors you are seeing, since the database can't be decrypted.

But maybe there's something else going on in your configuration? Can you provide debug logs (~/config/Signal/logs/*.log), and a little bit more information about the history of your Signal Desktop usage? Can you think of a way that Signal Desktop would have put your encrypted database password into a protected storage location that it can no longer access?

xvado00 commented 1 week ago

I can confirm this issue (code=26: file is not a database) on Arch. Mobile app reports last activity on 23.8.2024 corresponding to the version 7.19.1 of signal-desktop. This is a device paired since 2020. Of the package-listed dependences, none have been upgraded that that day. However both nodejs (22.6.0-1 -> 22.7.0-1) and electron (1:31-1 -> 1:32-1) together with signal-desktop (7.19.1-1 -> 7.21.0-1) were upgraded. Going back to those versions does not solve the issue, nor did any upgrade so far.

Recently, I noticed, I was being asked by kwallet to allow Signal access. And indeed it is set in Signal config as: "safeStorageBackend": "kwallet6" I may have allowed it access on one devices and denied on the other... I cannot seem to find any associated password in the wallet, though. And on the device with allowed access, I can start signal-desktop.

And allowing access on the other device and reloggin fixes the issue. Can Signal's password be masking as "Chromium Keys/Chromium Safe Storage"?

corsac-s commented 1 week ago

@corsac-s If Signal Desktop cannot access a consistently-available form of protected storage (or basic, if the system doesn't support it), it will save it database password somewhere which it cannot later access. That will cause the errors you are seeing, since the database can't be decrypted.

But maybe there's something else going on in your configuration? Can you provide debug logs (~/config/Signal/logs/*.log), and a little bit more information about the history of your Signal Desktop usage? Can you think of a way that Signal Desktop would have put your encrypted database password into a protected storage location that it can no longer access?

It's possible I've run signal both under and outside Firejail, so maybe at one point (outside of Firejail) it identified a way to save the password, then can't access it under Firejail. Following the comment by @xvado00 I checked the configuration and I have:

"safeStorageBackend": "gnome_libsecret"

(I'm running Debian sid with Xfce desktop environment, but I do have gnome keyring available somewhere).

The debug logs are attached. app.log main.log

I can't really see issues there but on the terminal output I get:

[18:0909/203736.429726:ERROR:bus.cc(407)] Failed to connect to the bus: Failed to connect to socket /run/firejail/mnt/dbus/system: Permission denied

I guess it might be linked because I assume gnome_libsecret might try to access gnome keyring with DBus. It was working previously but maybe the password was saved somewhere else?

Also, when looking in seahorse I can't see a password for Signal so I'm not sure about all of the above.

scottnonnenberg-signal commented 6 days ago

@corsac-s Going back and reading your original report, it seems that the answer is simply that you cannot run Signal Desktop in Firejail. Firejail somehow prevents access to the secure storage location it normally has access to.

Note that you might be able to start your Desktop installation over from scratch and run it only within Firejail, giving Desktop the consistent access it needs. My theory is that you ran the first version that upgraded its database key storage outside of Firejail, so that's where the database key was saved.

corsac-s commented 5 days ago

@corsac-s Going back and reading your original report, it seems that the answer is simply that you cannot run Signal Desktop in Firejail. Firejail somehow prevents access to the secure storage location it normally has access to.

Note that you might be able to start your Desktop installation over from scratch and run it only within Firejail, giving Desktop the consistent access it needs. My theory is that you ran the first version that upgraded its database key storage outside of Firejail, so that's where the database key was saved.

Well maybe but it was working before so I'm not sure what changed and if there's something to be done (either in Signal Desktop, or maybe in the firejail profiles, and maybe the Flatpak/Snap ones)

signalapp / Signal-Desktop