Symptoms & scope
- pacman ends a transaction with conflicting files.
- An incoming file already exists and may belong to another package.
Relevant environment
Arch Linux pacman file-conflict checks; incoming package archives can be inspected without installing them.
Recognizable messages (synthetic examples)
error: failed to commit transaction (conflicting files)Use the preceding path list and ownership queries; the summary does not establish whether the file is manually installed.
Possible causes
These are possible explanations, not a confirmed diagnosis. Several independent faults can coexist.
- A manual installer may have placed unowned files at package-managed paths.
- A packaging transition or third-party package may conflict with an installed owner.
Diagnose safely
Run one command at a time in the relevant session. Read the explanation first. Uppercase placeholders need your own values; tools and privileges vary by distribution. These commands are displayed here and never executed by the website.
Check 1
Replace with the exact path printed by pacman; queries the installed file owner without removing anything.
pacman -Qo /path/to/conflicting-fileInterpret the result: A known package owner rules out blindly deleting the file. No owner suggests a manual file but does not prove it is disposable.
Check 2
Replace with the downloaded archive for the failed transaction; lists incoming paths without extracting or installing it.
pacman -Qlp /path/to/incoming-package.pkg.tar.zstInterpret the result: Compare the conflicting path and directory/file type with the existing object. Missing cache archives require obtaining the supported package before this comparison.
Evidence-guided next steps
Move a confirmed unowned manual file aside
If ownership checks prove the path is an obsolete manual installation and its purpose is understood, preserve a backup and move only that object outside the package path before retrying the reviewed transaction. Keep user data and configuration separate from program files.
Precautions: Do not remove directories recursively merely because one child conflicts. Symlinks and local configuration need explicit review.
Recovery / rollback: Restore the saved manual file only after removing the new owning package through pacman if necessary; never overwrite its managed file behind pacman’s back.
Did this solution help you?
Follow the documented package ownership transition
If another package owns the path, check Arch’s or the repository maintainer’s transition instructions for that exact package pair. Use the supported replacement/removal transaction; consider a narrowly matched --overwrite only when the maintainer explicitly identifies the path and ownership consequences.
Precautions: Never use --overwrite "*" as a generic fix. Save the package/version list and configuration before a replacement.
Recovery / rollback: Restore the prior coherent package snapshot or perform the documented reverse replacement using supported package versions and saved configuration.
Did this solution help you?
References & review
This guide was prepared from primary project or distribution sources and reviewed on the date shown. This is an editorial source check, not evidence that a fix was reproduced on your hardware. Diagnostic log examples are synthetic fixtures. Version-dependent details must be checked against your installed release.
- Arch pacman manual: query, sync and alternate system roots (project or distribution documentation)
- ArchWiki: pacman lock and file-conflict recovery (project or distribution documentation)
- ArchWiki: upgrade and file-conflict maintenance (project or distribution documentation)