You are not logged in.
I am getting an error when downloading and installing packages with pacman.
This is what I get:
$ sudo pacman -S nitrogen
warning: nitrogen-1.2-1 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...
Targets: nitrogen-1.2-1
Total Download Size: 0.00 MB
Total Installed Size: 0.13 MB
Proceed with installation? [Y/n]
checking package integrity...
(1/1) checking for file conflicts [#####################] 100%
(1/1) upgrading nitrogen [#####################] 100%
warning: directory permissions differ on usr/man/man1/
filesystem: 755 package: 700
I don't know if that has a serious impact, but I am sure it shouldn't be like that...
Offline
Submit a bug report.
Offline
Wow, that was my first bug report. I hope, the info I provided is sufficient; I have no idea what else to write...
http://bugs.archlinux.org/task/9215
Last edited by Stalafin (2008-01-15 01:00:16)
Offline
Ever since I upgraded to pacman 3.1, I've been getting a ton of these errors. Should I submit bug reports for each program?
Edit:
Actually, looking at my log, most of the errors are similar to the following:
warning: directory permissions differ on lib/
filesystem: 2755 package: 755
what does the 2755 mean?
Last edited by sinister99 (2008-01-15 16:54:11)
Offline
Ever since I upgraded to pacman 3.1, I've been getting a ton of these errors. Should I submit bug reports for each program?
It depends on which permissions look wrong. If it's the filesystem one, just consider fixing the permission manually on your system.
If it's the package one, consider reporting a bug for the package, indeed.
Edit:
Actually, looking at my log, most of the errors are similar to the following:warning: directory permissions differ on lib/ filesystem: 2755 package: 755
what does the 2755 mean?
In this case, it's the filesystem one that look strange.
You could have a look at man 2 stat, after this line : The following flags are defined for the st_mode field.
But maybe there are other man pages I don't know about.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
In this case, it's the filesystem one that look strange.
You could have a look at man 2 stat, after this line : The following flags are defined for the st_mode field.But maybe there are other man pages I don't know about.
I checked out that man page, but I don't understand it. I didn't ever touch the permissions on these folders, so I guess it was from a package install or something.
I have lots of folders like this. Even the kernel folders have these permissions.
Offline
Submit a bug report.
This is one way and i hope it helps you and the other devs. But what do you think about that the systems can repair this by itselfs? On my opensuse server i have a tool named chkstat which runs as a cronjob and set the file permissions as loaded from a file.
Source: http://ftp.gwdg.de/pub/opensuse/distrib … 11.src.rpm
manpage: http://www.trinler.de/de/linux/man.html?command=chkstat
The advantage from my side is that one or a group of devs define the file permissions standard for arch linux and everyone can choose to use it or to append own more or less secure/paranoid settings. Another sideeffect is that every dev can take a look inside this config file to see what permission the own PKGBUILD need so that in the best case we will not see such messages in the future. The source includes config files so there is no need to restyle this all from zero.
Offline
I'm having these permission errors all the time after upgrading to pacman 3.1. Is it bad for my system?
Offline
Me too just after pacman upgrade. Anyway system seems to be OK
Offline
In this case, it's the filesystem one that look strange.
You could have a look at man 2 stat, after this line : The following flags are defined for the st_mode field.But maybe there are other man pages I don't know about.
I read the man page, but it was a foreign language to me...
what does the 2 in 2755 mean? something to do with groups?
Is this at all bad?
Offline
I'm having these permission errors all the time after upgrading to pacman 3.1. Is it bad for my system?
Well, it's not worse than it was on 3.0, which didn't even mention these permission inconsistencies (they obviously already existed before).
At least now, you know they exist. But if you can figure out whether there is a problem or not, then I would suggest just keeping doing what we have always done in the past. That is, simply ignoring these warnings.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
2755 is normal, GID, RTFM (i love saying this):
man chmod
A numeric mode is from one to four octal digits (0-7) ... except that if the first digit is omitted, a directory's set user and group ID bits are not affected ... The first digit selects the set user ID (4)
and set group ID (2) and restricted deletion or sticky (1) attributes. The second digit selects permissions for the user who owns the file
The first is the 2 - the UID/GID, it can be left alone to preserve, and usually that's the norm. The second is the 7 we see before 55. Anyway if you're concerned:
chmod 755 $dir/$file
And as for the warnings, maybe it's due to the new pacman, but as far as security is concerned it's fine.
Last edited by schivmeister (2008-01-21 16:49:38)
I need real, proper pen and paper for this.
Offline
Thanks for the explanation schivmeister.
Note to self: RTFM
Offline
While trying to correct permission on /var/log after pacman update
warning: directory permissions differ on var/log/
filesystem: 777 package: 755
I did what schivmeister suggested "find / -type d -exec chmod 755 {} \;"
Then I couldn't login to xfce4 using other users, than "root"
then I figured users couldn't write to /tmp
so I did this.
chmod 1777 /tmp
chgrp root /tmp
chown root /tmp
chmod 1777 /var/tmp
chgrp root /var/tmp
chown root /var/tmp
and now it works :-) dam I should RTFM, but its hard to find one for noobs like myself to understand.
That's what i like about Archlinux, I break it so often , that I'm forced to learn.
Offline
I suspect the problem with perms 2755 is that /var/abs/local is by default 2755 (IIRC), so packages inherit the 2, and bad pkgbuilds (i.e. ones that use "cp" command instead of "install -m644" don't chop off the 2.
The 2 exists so that local packages can be compiled as non-root, presumably.
This is why I fix the permissions using a script:
cd /var/abs/local/ && chown root:root * && chmod -s *
cd /var/abs/local/${pkgname}/ || exit 1
rm -rf src pkg && chown root:root * && chmod -s * && makepkg -fi --asroot || exit 1
Offline
my bad, shouldn't have pasted that as a workaround. it changes permission recursively for every directory under the one specified and I typed /
brebs: cp $dir would carry over the GID bit even if $dir doesn't have it? is there an alternative safer route to take with directories?
I need real, proper pen and paper for this.
Offline
brebs: At first that seemed like the right idea, it's just that there is no /var/abs/local by default, for quite a while already.
1000
Offline
byte: So whaddaamisupposedtodo, reinstall? Or come up with some hacks to fix the previous bugs (preferable)?
If this required a reinstall, I would switch distros in the process
Offline
I've set up four Arch installations in two years and played quite a bit with ABS and AUR packages, and I've yet to see that permissions warning.
No idea what people have done to get that far, but it's certainly nothing to do with the normal base system or packages from [core].
1000
Offline
byte: How do you compile packages from AUR (which of course is necessary for a complete installation of Linux on the desktop)?
I installed Arch in Nov-2007, so the excuse that this is an "old problem" is of course garbage.
Offline
/var/abs/local is still my workdir though but it differs for everyone else. i would have to agree with byte that i have yet to come across this myself.
I need real, proper pen and paper for this.
Offline
brebs: Depends, really. In the past I've used aurbuild, nowadays yaourt, and I also use plain makepkg.
1000
Offline
The same thing started happening to me after i updated pacman around the same time the OP occurred... and the newest pacman update didn't solve it either.
Offline
The same thing started happening to me after i updated pacman around the same time the OP occurred... and the newest pacman update didn't solve it either.
Hmm... There is nothing that pacman has to solve here. It is not a pacman bug, it's a feature that can help detecting eventual packaging errors.
pacman roulette : pacman -S $(pacman -Slq | LANG=C sort -R | head -n $((RANDOM % 10)))
Offline
OK, so let me see if I understand this correctly: This error, while annoying, is not critical, right? Will this problem affects the package installation? Is it safe to ignore it?
Also, what is the proper directory permissions? 755? On my system the directories that have problem are /usr/man and /etc (which are both 2755) and /proc (which is 555). Do I need to changes these directories permission to 755 or can I safely ignore them?
Last edited by zodmaner (2008-01-23 15:27:19)
Offline