pacman "exists on filesystem" error

Question

I ran sudo pacman -Syu and I got some interesting errors reading:

error: failed to commit transaction (conflicting files)

and a long list of files followed by exists in filesystem. Full output is here: http://ix.io/lLw

It appears that many of these files are not associated with a package when I checked them with pacman -Qo <path-to-file>, but I did not check them all. I had a weak connection when I ran pacman -Syu, but I get the same errors when I updated later: http://ix.io/lLx

What should I do? Should I check all files and delete the ones that do not have an associated package? Should I force update (with sudo pacman -S --force <package-name>?)

Update

I tried running sudo pacman -S --force <package-name> and got this:

[my-pc]/home/average-joe$ pacman -Qo /usr/lib/python3.5/site-packages/PyYAML-3.11-py3.5.egg-info
error: No package owns /usr/lib/python3.5/site-packages/PyYAML-3.11-py3.5.egg-info

It looks like pacman -S --force <package does not overwrite directories that contain files. From the man:

Using --force will not allow overwriting a directory with a file or installing packages with conflicting files and directories.

Should I just delete the conflicting directories? (they do not have associated packages)

why do you have conflicting files in the first place? when using a package manager, try not to tap on its toes (e.g. by installing software in places the package manager rightfully thinks is theirs; if you must install things manually, install to `/usr/local/` rather than `/usr/`) — umläute, Nov 02 '15 at 12:37
@umläute I am not exactly sure where the conflicting files came from, but I suspect they are related to my installation of [docker-compose](https://docs.docker.com/compose/install/) which I installed using `sudo pip install -U docker-compose==1.5.0rc3` [on this page](https://github.com/docker/compose/releases). Perhaps `sudo pip install` conflicts with pacman? — modulitos, Nov 03 '15 at 07:47
@umläute Getting wrong `-S` updates (partial installs, etc) will let you that scenario. Case of me `--force` worked all times. — m3nda, May 23 '17 at 17:15
See comment below to "fast" usage of the `--overwrite` command, because `--force` is not working anymore. — m3nda, Jan 30 '20 at 01:53
This will often happen for CUPS wrappers: Brother printer config files and libraries are packaged in several AUR sources. And `trizen -S --overwrite "*"` or `\*` won’t work: the `*` argument isn’t passed on to `pacman`. Not sure how to properly escape this, but after downloading all packages, `trizen` will tell you the exact `pacman` command it is going to execute. Then simply `Ctrl` + `C`, copy that command, fix the `"*"` argument and hit `Enter`. — Sebastian Simon, Dec 30 '20 at 01:55

score 93 · Accepted Answer · edited Feb 05 '21 at 10:39

93

After pacman finally deprecated the --force option and made the surrogate --overwrite option work as expected, the following usage pattern should be noted.

A command to reproduce the --force option that blindly overwrites anything that conflicts is this:

sudo pacman -S --overwrite \* <package_name>

Or

sudo pacman -S --overwrite "*" <package_name>

The tricky part is escaping the wildcard to stop the shell from expanding it first.

edited Feb 05 '21 at 10:39

Matthias Braun

7,797
7
45
54

answered Oct 30 '19 at 05:51

nix

1,046
6
4

This time nothing worked for me, caused by dependancy loop, I had no more choice than uninstall the module with pip then issue again the pacman install one. So sad :-/ that creators or those packages don't look at those problems. – m3nda Jan 30 '20 at 01:57
Doesn't work. It still prints an error about existing file in the filesystem. However, suggested idea below about simply removing the conflicting files and then installing as usual worked for me. – Hi-Angel Apr 07 '22 at 19:47
It worked for me. In my case I had faced a package issue like `edk2-armvirt already exists in filesystem`. – joseluisq May 10 '22 at 06:24

modulitos · Answer 2 · 2018-06-20T06:25:18.483

34

Ok, it looks like running sudo pacman -S --force <package-name> works, but it doesn't resolve conflicting directories. In such cases, running sudo rm -rf on the conflicting directories, followed by sudo pacman -S --force <package-name> works.

Now my pacman -Syu resolves well.

edited Jun 20 '18 at 06:25

answered Nov 02 '15 at 11:43

modulitos

3,097
8
29
44

15

--force is deprecated; use --overwrite instead. – Ankit Balyan Jun 14 '18 at 08:37
7

--force is working for me but --overwrite is not – eirenikos Jun 18 '18 at 13:19
3

`sudo pacman -Syu --force` worked for me, but overwrite wasn't recognized. – spydon Jul 02 '18 at 08:03
no syntax works with `--force`, this answer should be edited to refer to the other one – Labo Nov 09 '20 at 15:00
This is out of date. You need to use --overwrite instead of --force. – Volker Weißmann Dec 13 '20 at 14:12
@Kryptomatrix Could you possibly suggest an update to this answer? – Kusalananda Dec 13 '20 at 16:10
@Kusalananda This one is correct https://unix.stackexchange.com/a/549419/434628 – Volker Weißmann Dec 13 '20 at 22:07
@Kryptomatrix Whether one or the other is "correct" appears to depend on the version of `pacman` being used. – Kusalananda Dec 14 '20 at 05:41
Yes, and for the newest verision of pacman the correct answer is --overwrite. – Volker Weißmann Dec 14 '20 at 11:57

l0b0 · Answer 3 · 2015-11-03T08:16:45.883

tl;dr: Uninstall the conflicting application before running pacman.

pacman (and other package managers) keep an index of packages and files that they manage (pacman --query --list). Some files, such as configuration, will be marked as modifiable and will not be overwritten during upgrade (except in special circumstances, where the package manager will typically move away the old file before creating the new one). Other files will be marked as unmodifiable. If another application changes those files in any way without updating the index accordingly there's no way for the package manager to know what to do with those files during an upgrade.

Many applications installed using the standard ./configure && make && sudo make install pattern can be uninstalled using sudo make uninstall. If you have installed the application in some other way you might have to something else to uninstall it. In general it can be a good idea to keep a copy of installation files somewhere (for example ~/install) to be able to reliably uninstall them in such cases. Just removing the conflicting files will probably leave other files lying around, which could conceivably cause other problems.

When installing software with other package managers there are ways to isolate those from the system files. This is an established best practice for example during software development, where you really want to keep versions consistent and avoid conflicts with other software. Examples include:

See my comment to @umlaute above. I think the conflict was from a `sudo pip install` command. Perhaps I should avoid using pip with sudo? — modulitos, Nov 03 '15 at 07:48

score 13 · Answer 4 · answered Nov 18 '20 at 20:29

13

The correct way to upgrade and overwrite conflicting packages is:

sudo pacman --overwrite "*" -Syu

answered Nov 18 '20 at 20:29

hLk

230
2
5

Fin Hirschoff · Answer 5 · 2019-03-08T02:28:14.850

TLDR;

Get a list of the offending files (copy and paste pacman's output into a file).
Use awk to strip out everything but the file paths into a new list.
Use while to move the offending files out of the way, based on the list.
Run sudo pacman -Syu again.

edited to add TLDR and fix typos

Although I'm pretty sure I haven't been doing anything stupid, I've had this problem maybe every other time I've tried to update since I've been using Manjaro; three or four times within two months. Point being, this fixes it.

Get a list of your files.

When the update fails in your terminal window, you get this:

error: failed to commit transaction (conflicting files)
evilfile: /usr/bin/evilfile exists in filesystem
libx000: /usr/lib/libx000.so.f.u.loser exists in filesystem
accountsservice: /usr/share/locale/ru/LC_MESSAGES/accounts-service.mo.yu.dnt.evn.spk.russian exists in filesystem

... and a lot more.

Copy the output from the terminal, and put it in a file. I used nano, and named mine "files," as in ~/work/files.
Strip extraneous info:

cat files | awk '{print $2}' >> ~/work/files2

This takes the second "word" from each line and prints it to files2.

Deal with the files

You could delete them, move them, or rename them.
If something breaks, it's easiest to fix if we break it by moving it instead of deleting or renaming it:
mkdir ~/work/oldfiles while read -r file; do sudo mv -- "$file" ~/work/oldfiles/$file; done < files2
If you really want to delete them, which there is no reason to do (DANGER DANGER): while read -r file; do sudo rm -- "$file"; done < files2

Updating

To get --overwrite to work, which we need to do to get pacman to realize the package isn't broken, you need the following syntax:

sudo pacman -S package_name --overwrite /location/of/thing
- In my case: sudo pacman -S libidn2 --overwrite /usr/lib/libidn2.so.0
- Following the example: sudo pacman -S libx000 --overwrite /usr/lib/libx000.so.f.u.loser
I had a cute problem where if I deleted the libidn2.so.0 symlink, nothing worked, and when I put it back, I got the "exists on filesystem" error. The above, with --overwrite, is all that worked for me.
Finally:

sudo pacman -Syu

This solved the problem for me, thank you very much! Though I used the following routine as the other gave me a double forward slash in file name. `for file in $(cat ./files.txt); do sudo mv "$file" ./oldfiles; done` — Nikole, Dec 12 '22 at 16:20

score 3 · Answer 6 · answered Jul 25 '18 at 16:48

I was installing packages that I usually install with pip via pacman because of this. But some packages arent found in pacman repos. I think we should avoid installing pip with sudo privilegies and istead:

pip install pillow --user

--user flag makes pip install packages in your home directory instead, which doesn't require any special privileges.https://stackoverflow.com/questions/42988977/what-is-the-purpose-pip-install-user

score 0 · Answer 7 · edited May 21 '19 at 12:37

0

If you have many files as me,

sudo pacman --force -Syyu

resolves all issues.

edited May 21 '19 at 12:37

Jeff Schaller

66,199
35
114
250

answered May 21 '19 at 11:08

Mohamed Hedi Kestouri

31
1

option --force is deprecated; use --overwrite instead – Mahmoud Jul 04 '19 at 22:01
--overwrite seems must specify what to overwrite. currently use --force every thing is fine – xsilen T Sep 29 '19 at 13:03

score 0 · Answer 8 · answered Apr 16 '20 at 07:54

when you conflicting files/ file already exists. do the following.

pacman -Qo "path_to_file"

if the out is "No package owns this file" then you can delete the file without any worry.

for me usually i get file already exists error on /usr/lib/python3.8/"folder_X"/.... so i run pacman -Qo /usr/lib/python3.8/folder_X which usually return "No Package owns this file" and i just remove it.

sudo rm -rf /usr/lib/python3.8/folder_X

till date i have not had a situation where a file or folder was actually owned by a package. so i can't really advice on what to do in that situation.

Hope this Helps

pacman "exists on filesystem" error

8 Answers8

TLDR;

Get a list of your files.

Deal with the files

Updating

Linked