Warning: directory permissions differ on /etc/bluetooth/

( 1/17) upgrading bluez                                                                                       [-----------------------------------------------------------------] 100%
warning: directory permissions differ on /etc/bluetooth/
filesystem: 755  package: 555
( 2/17) upgrading bluez-libs                                                                                  [-----------------------------------------------------------------] 100%
( 3/17) upgrading bluez-utils                                                                                 [-----------------------------------------------------------------] 100%
warning: directory permissions differ on /etc/bluetooth/
filesystem: 755  package: 555

got 2 warnings when updating bluez and bluez-utils, I don’t think I have modified the mentioned file before, what cause it?

Anyway, should I do something or just leave it alone? Have the packages updated successfully?

The permissions you have are more permissive than the ones the package has, so everything should continue to work fine and you probably don’t have to do anything.

But if you want, you could fix it by running:

sudo chmod 555 /etc/bluetooth/
5 Likes

I used sudo chmod -R 555 /etc/bluetooth
Is this wrong?

It’s unnecessary (there are no subdirectories within /etc/bluetooth/) and the error only reports the directory itself having different permissions than the package.

Also, the files within that directory should probably be 644, not 555. So it probably is wrong…

3 Likes

download

As a general rule it is very dangerous to use octal permissions with chmod -R. That can cause some serious havoc if used in the wrong place.

When recursively changing permissions, use additive or subtractive permissions. For example chmod -R o-w /my/cool/directory

5 Likes

images

5 Likes

No, thanks :joy: :joy:

1 Like

I almost always do that anyway, simply because most of the time I can’t be bothered to convert octal to binary just to figure out what is and what isn’t permitted.

I know that sysadmins who do this often have it memorised and can say 5 means r-x without even thinking about it, but I have to count in my head.

2 Likes

I’d just like to take it one step further and add onto the current discussion, which I know is already solved of course. When these permission warnings occur, it may be beneficial at times to check the package on https://archlinux.org and view the latest commit. Honestly, I find it a good habit to get into viewing some of the latest commits, but you don’t really have to unless there’s an issue or just generally curious.

Now using the sites top right search bar, for bluez and going to that package’s page, on the top right is something called “Package Actions” and under that is a couple of useful links you can click, one of them being a link I frequently check called “View Changes” (this is where to view the latest commits).

The following link will direct you to the latest github commit on the bluez package the Arch devs did and in this case that particular commit can be seen here: https://github.com/archlinux/svntogit-packages/commit/d9c16b5f78e466b3270d2b649d8ade14671070b7

I’m not an experienced coder by any means, but for commits it’s important to focus on the color coding: red means removed, and green means added. Kind of like how it looks on these forums when you edit a post multiple times, it shows what is removed and what is added in a color code.

So in this commit you can see in red it says install -dm755 "${pkgdir}"/etc/bluetooth so that got removed and in green they added install -dm555 "${pkgdir}"/etc/bluetooth

Essentially, this confirms the best approach you need to know in order to handle this permissions warning. In this case just as @Kresimir said sudo chmod 555 /etc/bluetooth/ will fix your permissions warning and after that you’re all set!

This was just a long (or mini) rant of me saying it’s a good habit (dare I say fun?) to check some of the latest commits the Arch devs are doing so you’re more able to deal with any issues appropriately.

8 Likes

I mean, the warning you get with the update tells you how to fix it, but yes, if you want to investigate it further to discover the cause of it, you can look at the diffs in the official PKGBUILDs, that’s a good idea.

1 Like

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