You moved the database and KeePassXC refuses to save
You installed Fedora and set up KeePassXC to manage your passwords. The application works perfectly when the database file lives in ~/Documents. You create entries, save changes, and the browser extension fills forms without issue. Then you decide to organize your data. You create a dedicated directory at /srv/passwords to keep the database separate from your personal files, or you mount a network drive for backups. You move the .kdbx file to the new location. KeePassXC opens the file, you edit a password, and click save. The application hangs, or you get a permission error, or the save succeeds but the file size does not change. SELinux is blocking the write operation. The fix is not to disable SELinux. The fix is to label the directory so the policy allows KeePassXC to access it. This article covers the installation, the SELinux configuration for non-standard paths, and the browser integration workflow.
What's actually happening
KeePassXC is a client-side application. There is no background daemon, no network service, and no cloud sync built into the core. The entire state lives in a single .kdbx file. When you open the file, the application decrypts the database into memory, lets you edit entries, and writes the encrypted blob back to disk. The security model relies on file permissions, the encryption key, and the operating system's mandatory access controls.
Fedora enforces SELinux policies that restrict where applications can read and write. By default, GUI applications launched from the desktop session are allowed to access files labeled user_home_dir_t inside your home directory. If you place the database in /srv, /opt, or a mounted NFS share, SELinux sees the access attempt as a violation. The policy denies the write request. KeePassXC cannot save the changes. The error may appear as a generic "Permission denied" or the application may silently fail to update the file.
The .kdbx format uses Argon2d for key derivation by default. This makes brute-force attacks computationally expensive. When you create a database, KeePassXC asks for a master password and optionally a key file. The key file adds a second factor that lives on your disk. If you lose the key file, the database is unrecoverable. Store the key file separately from the database. The file itself is just a binary blob; the security comes from the encryption and the access controls protecting it.
Run dnf upgrade --refresh before installing. Old metadata leads to old packages.
Install KeePassXC
Install the package from the official repositories. The version in the default repos is stable and receives security updates automatically. You do not need a third-party repository for standard use.
sudo dnf upgrade --refresh # refresh metadata to ensure you get the latest available version
sudo dnf install keepassxc # install the password manager and its dependencies
The dnf upgrade --refresh command forces a metadata refresh even if the cache is fresh. This prevents installing an old version because the local cache hasn't updated yet. This is the normal weekly maintenance command on Fedora. Use it before installing new packages to guarantee you are working with current package information.
If you need a development version or a specific plugin not yet in the stable repos, you can enable the COPR repository. This is rarely necessary for general use. The COPR build may contain newer features but lacks the same testing cycle as the official package.
sudo dnf copr enable @fedora-llvm-team/keepassxc # enable the community COPR repository
sudo dnf install keepassxc # install from the enabled repository
Launch the application from the menu or run keepassxc in the terminal. The first run prompts you to create a new database. Choose a strong master password. Enable the key file option if you want two-factor authentication for the database itself. Save the database to your home directory to verify the installation works before moving files.
Label the directory before you move the file. Moving a file to an unlabeled directory breaks access immediately.
Configure SELinux for custom directories
If you store the database in your home directory, no extra configuration is needed. KeePassXC can read and write to ~/ without issues. If you move the database to a shared location like /srv/passwords or a mounted drive, you must adjust the SELinux context. SELinux prevents KeePassXC from writing to directories that are not labeled for user data.
Create the directory and set ownership. Then add a persistent SELinux rule and apply it.
sudo mkdir -p /srv/passwords # create the directory for the database
sudo chown -R $USER:$USER /srv/passwords # set ownership to your user account
sudo semanage fcontext -a -t user_home_dir_t "/srv/passwords(/.*)?" # add a rule to label this path as user home data
sudo restorecon -Rv /srv/passwords # apply the new label recursively to existing files
The semanage fcontext command adds a persistent rule to the SELinux policy store. The rule matches the path /srv/passwords and any files inside it, assigning the user_home_dir_t type. This type allows user applications to read and write files. The restorecon command applies the rule to the filesystem immediately. Without restorecon, the label change only takes effect for new files created after the rule is added. Existing files retain their old labels until you run restorecon.
SELinux contexts are persistent across reboots. The semanage command writes to the policy database. The restorecon command updates the inode labels on disk. If you copy a file from ~/ to /srv/passwords, the file retains the user_home_dir_t label. If you copy a file from /srv/passwords to a new directory without a rule, the file might get default_t or public_content_rw_t, breaking access. Always run restorecon after bulk operations or directory moves.
Check ls -Z before you blame the application. The context tells the truth.
Browser integration and firewall
The browser extension bridges the gap between the locked database and your web browser. KeePassXC does not expose a network port for this. The extension communicates via a local Unix socket. Install the "KeePassXC-Browser" extension from your browser's add-on store. Open KeePassXC, navigate to Tools > Settings > Browser Integration. Click Connect. The browser will prompt you to allow the connection. Once paired, the extension can request credentials from KeePassXC when you visit a login page.
Browser integration uses a local Unix socket on Linux. The extension connects to socket://keepassxc-socket. No TCP port is opened. This is why firewalld does not need configuration. If you see a firewall prompt, it is likely from a different application or a misconfigured custom script. KeePassXC does not require open ports for standard operation. The firewall-cmd --reload command is only needed if you modify firewall rules manually. Since no rules are required, you do not need to reload the firewall.
Trust the local socket. Network exposure is a risk, not a feature.
Verify the configuration
Verify the SELinux context is correct. The directory and files must show user_home_dir_t.
ls -Z /srv/passwords # check the SELinux type of the directory and its contents
The output should show unconfined_u:object_r:user_home_dir_t:s0 for the directory and files. If you see a different type, the restorecon command did not run correctly or the semanage rule is missing. Run restorecon again and check the output for errors.
Open KeePassXC and create a test entry in the custom directory. Save the database. If the save succeeds without errors, the configuration is correct. Close the application and reopen the database to ensure the file is not corrupted.
Close KeePassXC before copying the database. File locks protect against corruption, not backups.
Common pitfalls and error analysis
If you get a permission error, check the audit log. SELinux denials are logged in the audit subsystem. The error message in KeePassXC often lacks detail. The audit log shows the exact denial.
sudo ausearch -m avc -ts recent | grep keepassxc # search for recent access vector cache denials related to keepassxc
The output shows the source process, the target file, and the denied permission. If you see denied { write }, the context is likely wrong. The file might be labeled default_t or public_content_rw_t. If you see denied { open }, the file might not exist or the parent directory lacks execute permissions. If you see denied { getattr }, the application cannot even check the file metadata. Fix the context with semanage and restorecon.
Another common issue is file locking. KeePassXC locks the database file while it is open. If you copy the file while the application is running, you get a corrupt backup. The copy command may succeed, but the file content is incomplete. Always close KeePassXC before copying the database for backup. Use rsync or a backup tool that handles locked files if you need automated backups.
Config files for KeePassXC live in ~/.config/keepassxc/. This directory stores settings, browser integration keys, and auto-type configurations. Never edit system files in /usr/lib/. Files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/ or ~/.config/. Manual edits in /usr/lib/ get overwritten on package updates.
Read the audit log before you disable SELinux. The log points to the exact fix.
When to use KeePassXC versus alternatives
Use KeePassXC when you want a local-only database with no cloud dependency. Use Bitwarden when you need automatic sync across devices without manual file transfers. Use the system keyring when you only need to store browser passwords and do not want to manage a separate file. Use a hardware token when you require physical possession for authentication. Stay on the default home directory location if you do not have a specific backup workflow that requires a separate mount point.
Trust the local file. Sync is a feature, not a requirement.