Pamac error: Permissions changed on '/var/tmp/pamac/dbs/sync/extra.db'?

Support
1

I just tried running pamac from the command line. This is what happened:

$ pamac update
Preparing...
Synchronizing package databases...
Refreshing AUR...                                                                                                                           
7.9 MB/10.7 MBchmod: changing permissions of '/var/tmp/pamac/dbs/sync/extra.db': Operation not permitted                                    
chmod: changing permissions of '/var/tmp/pamac/dbs/sync/extra.db': Operation not permitted                                                  
Nothing to do.
Transaction successfully finished.
$

I’m afraid I have no idea what to do. sudo pacman -Syu does this:

sudo pacman -Syu
[sudo] password for user: 
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 multilib is up to date
:: Starting full system upgrade...
 there is nothing to do
$

I know I haven’t done anything with file permissions on the cited file. Anyone else in there experience this?

2

Sure, but you did run pamac as root. Therefore:

Ownership changed and a normal user cannot change permissions of the root user.

Just delete the database and run again:

sudo rm -Rf /var/tmp/pamac/dbs/sync/
pamac update

So never run pamac with sudo.

4 Likes
3

Interesting. I know you should never to run pamac as root. To be sure, I just went through my entire.bash_history (which covers probably a few months in my case) and found no instances of sudo pamac.

I just went to the directory /var/tmp/pamac/dbs/sync/ and checked the permissions on the file. For some reason, it belongs to another user/group on the computer. It doesn’t belong to root! Very strange.

4

We had this recently in another topic. Seems that pamac is a bit…single user concept. If the user you are using now was created later, after pamac update was run from the first user it leads to this (d)effect.
Just delete the file. It will recreate it with the current user ownership. If you later login with the other user account you will have the same issue inverted.
Or just update with pacman.
And do not forget to click the solution button on megavolt.

1 Like
5

Similar behavior:

As @Adramyttium no mention of using sudo with pamac (since installation in 2020)

6

It seems that libpamac was updated recently. Might a bug have been inadvertently introduced?

7

Ah alright. But same rule apply. However I agree that only root should download/create the database files to avoid such a behavior. To me it looks like a misconception like Teo mentions:

1 Like
8

Did you recently create another User account, and run pamac from there, perhaps using the original User account/password to authenticate?

9

No. In fact I logged into that account to check the bash history and there was nothing. Something else is up.

10

As it happens, I did the same as I described only a few weeks ago, and with the same result. Two options were given to authenticate (being the two accounts created) and I must have unwittingly pressed 2 instead of 1; I had used the same password as the account was only temporary for testing. Because the option selection was not a command, it would not have shown in history. I used basically the same suggestion given by @megavolt to fix the annoyance.

11

Just to be clear: That command deletes the file contents of that directory recursively, correct? So it will delete extra.db and everything else, right?

2 Likes
12

Correct.
Right.

They should be recreated next time you run pamac update or refresh databases.

13

Thanks for your help. The command did the trick. Would still love to figure out what happened.

14

This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.