No more database access rights after BIOS UEFI upgrade....

[olivier mimet]

Thank you Gilles for this very quick and interesting answer (the kind I 
expected!) : from now, I need a few time to read more about secure boot 
and its signature's management...especially considering those info :
- DK 8.8 (rpm version from Fedora repo) didn't open either the database 
before succeeding after windows boot
- Firefox and Thunderbird encounted the same issue with their profile 
access (which has been solved in the same way)
- rights management through shared NTFS partition could be tricky
- ...

And I need to read more about SELinux/AppArmor too....!!!

NB : from a practical point of view, disabling Secure Boot on a pure 
Linux is ok, but on a dual boot W11/Linux, it's a mess to have to go 
through BIOS settings at each OS switching (but it's not the point here, 
assuming the issue is permanently solved...)

Many thanks again,

Best Regards
Olivier

Le 16/12/2025 à 05:22, Gilles Caulier a écrit :
> Hi,
>
> Here’s my explanation of the issue and possible solutions:
>
> 1. Likely Cause of the Issue
>
> Secure Boot: The BIOS update likely enabled or altered Secure Boot
> settings (even with CSM disabled). Secure Boot checks the signatures
> of executables at startup. As the digiKam AppImage is unsigned, Linux
> may block access to certain files, such as the SQLite database.
> File Permissions: After a BIOS/UEFI update, file
> permissions—especially for shared NTFS partitions—can be
> misinterpreted or changed by Linux, especially if the system reboots
> with different security settings.
> AppImage and Secure Boot: AppImages are not always compatible with
> Secure Boot, as they lack recognized signatures by the UEFI firmware.
>
> 2. Why Does It Work from Windows?
>
> Windows does not enforce the same signature checks as Secure Boot on Linux.
> Launching digiKam from Windows likely reset file permissions or
> repaired the SQLite database (e.g., recreating lock files or fixing
> metadata).
>
> 3. Solutions for a Pure Linux Setup
>
> A. Disable Secure Boot (I do it on all my Linux computers)
>
> Reboot and enter your UEFI menu (usually by pressing F2, F12, DEL, or ESC).
> Locate the Secure Boot option and disable it.
> Save changes and reboot.
> Test launching digiKam from Linux.
>
> B. Check and Fix Database Permissions
>
> C. Check SELinux/AppArmor
>
> If SELinux is enabled, it might block database access. Check logs with:
>
> sudo dmesg | grep -i digikam
> sudo journalctl -xe
>
> Temporarily set SELinux to permissive mode for testing:
>
> sudo setenforce 0
>
> (Remember to re-enable it later with sudo setenforce 1.)
>
> D. Repair the SQLite Database
>
> If the database is corrupted, try to restore it from a backup
>
> Voilà for a first approach to solve your problem...
>
> Best regards
>
> Gilles Caulier
>
> Le mar. 16 déc. 2025 à 00:14, olivier mimet<omimet at free.fr> a écrit :
>> I just made a BIOS upgrade today, and at first boot, OS started as usual (Fedora 43) but DK (appimage v8.9.0) advise me I've no more rights to access the DK database (SqLite).
>>
>> I get easily a recovery by launching DK 8.8 from a windows partition (thanks to my dual boot, with shared NTFS data partition), which start properly (without any message...) at  first attemp, restoring thus access to the DK database back in Linux ....
>>
>> NB : Unlike legacy BIOS, I'm not so familiar with UEFI BIOS upgrade/boot (it's my first UEFI config., but I suspect Secure Boot to be involved in this behaviour (CSM is deactivated)....
>>
>> My question is : can somebody explain what happens, and how to solve it within a pure linux config. (I suppose that a dual boot is not mandatory to upgrade BIOS without preventing DK to start on a pure Linux config.! )?
>>
>> Thank you very much.
>>
>> BR
>> Olivier
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20251216/73a31a1a/attachment-0001.htm>