chmod -R 777 /

S

Serow

0
Hi,

durch einen Flüchtigkeitsfehler habe ich den im Subject aufgeführten Befehl ausgeführt. Ich denke das gröbste hab ich schon wieder gefixt, aber wie kann ich sicher gehen? Gibt es eine Möglichkeit irgendwie alle Files mit den entsprechenden DEB Packet Infos abzugleichen und am besten noch automatisch zu korrigieren?

cu
serow
 
Serow hat gesagt.:
Hi,
Gibt es eine Möglichkeit irgendwie alle Files mit den entsprechenden DEB Packet Infos abzugleichen und am besten noch automatisch zu korrigieren?
Zum Vergrößern anklicken....

Nein, da teilweise auch Berechtigungen durch post-install-scripte gesetzt werden. Die Berechtigungen im Paket selber sind also nicht immer so wie sie später im System sind.

Ich würde sagen wenn du das als root ausgeführt hast, dann ist das wirklich übel ;). Im Ernstfall das System beobachten (/var/log/* brav lesen) und die letzten Reste von Hand fixen.
 
Hi,

was soll ich denn in den Logs suchen? Hab da noch nie was bzgl File Permissions gesehn :D Also dürfte ne Neuinstallation das beste sein oder?

cu
serow
 
Theoretisch sollte es reichen alle Pakete nochmal mit force-Option zu reinstallieren. Welche Pakete installiert sind, kann man ja mit 'dpkg -l' ermitteln und den Output dann so weiterverarbeiten, dass sich die Reinstallation eigentlich in einem 1-Zeiler lösen lassen sollte.
 
Hi,

hab das mal vosichtig mit 1 Packet probiert:

Code: 
ironman:~# apt-get install --reinstall nfs-kernel-server
Reading package lists... Done
Building dependency tree       
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0B/162kB of archives.
After this operation, 0B of additional disk space will be used.
Do you want to continue [Y/n]? Y
(Reading database ... 55560 files and directories currently installed.)
Preparing to replace nfs-kernel-server 1:1.1.2-6lenny1 (using .../nfs-kernel-server_1%3a1.1.2-6lenny1_amd64.deb) ...
Unpacking replacement nfs-kernel-server ...
Processing triggers for man-db ...
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
fopen: Permission denied
Setting up nfs-kernel-server (1:1.1.2-6lenny1) ...
Stopping NFS kernel daemon: mountd nfsd.
Unexporting directories for NFS kernel daemon....
Exporting directories for NFS kernel daemon....
Starting NFS kernel daemon: nfsd mountd.
ironman:~#

Ich hab zwar keine Ahnung von Programmierung unter Linux aber fopen war doch ein System Call oder? Klingt nicht gut dieses Permission denied ^^

cu
serow
 
Offenbar konnten die Manpages nicht generiert werden, da vermutlich die Rechte dafür irgendwo nicht stimmen.
 
Hi,

man-db war das Packet. Ich hab jetzt mit

Code: 
for i in `dpkg -l | awk '{print $2}'` do
apt-get install --reinstall -y $i
done

das ganze angestoßen. Nachdem man-db installiert wurde tauchte der Fehler nicht mehr auf.

Danke für die Hilfe!

cu
serow
 
Hmm Misst, scheinbar ist das fopen Problem doch nicht weg. Er hat jetzt alle Packete drüber installiert. Wie kann ich jetzt rausfinden warum das immernoch kommt?

cu
serow
 
Führe mal 'mandb' manuell aus. Ich vermute mal, dass das Anlegen eines neuen Manpage-Indexes dem ganzen schon Abhilfe verschaffen könnte, da es immer ausgelöst wird, wenn Manpages generiert werden sollen. Ggf. wird durch einen defekten Manpages-Index versucht auf Dateien zuzugreifen, die nicht existieren. Stelle ausserdem sicher, dass die Manpage-Dateien alle root gehören und global lesbar sind.
 
Hi,

hab ich gerade gemacht. Permissions in /usr/share/man sind alle rw-r--r--. Das Problem besteht weiterhin...

cu
serow
 
Hm, schade. ;) Dann nimm dir mal irgendein Paket aus deinem Apt-Cache, das diesen Fehler triggert (also z.B. nfs-kernel-server) und schau mal, ob das Problem beim 'dpkg -i paketdatei' auch auftritt. Wenn ja, kannst du ein 'strace' davor setzen und schauen welche Dateien da durch fopen geöffnet werden sollen.
 
Hi,

hier der strace Output reduziert auf Zeilen die mit "open" beginnen:

Code: 
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/libpthread.so.0", O_RDONLY)  = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/etc/selinux/config", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/proc/mounts", O_RDONLY)          = 3
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
open("/etc/dpkg/dpkg.cfg", O_RDONLY)    = 3
open("/home/mathias/.dpkg.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/var/lib/dpkg/lock", O_RDWR|O_CREAT|O_TRUNC, 0660) = 3
open("/usr/share/locale/locale.alias", O_RDONLY) = 4
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/var/lib/dpkg/status", O_RDONLY)  = 4
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 5
open("/var/lib/dpkg/updates/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
open("/var/lib/dpkg/updates/0000", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0001", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0002", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0003", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0004", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0005", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0006", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0007", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0008", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0009", O_RDONLY) = 4
open("/var/lib/dpkg/updates/0010", O_RDONLY) = 4
open("/var/lib/dpkg/status-new", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
open("/var/lib/dpkg/available", O_RDONLY) = 4
open("/var/lib/dpkg/updates/tmp.i", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4
...

Kann ich anhand dieser Zeilen erkennen ob das open funktioniert hat? Wenn ja wie? Das sind irgendwas um die 10 Seiten Output :D

cu
serow
 
Code: 
open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US.utf8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en_US/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.UTF-8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en.utf8/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/locale/en/LC_MESSAGES/dpkg.mo", O_RDONLY) = -1 ENOENT (No such file or directory)

Ich würde mal sagen, dass es diese Dateien sind, die Probleme machen. Wurde evtl. das dpkg-Paket nicht neu installiert?
 
chmod -R 777 /
Zum Vergrößern anklicken....

In diesem Fall betrifft das ja nicht nur die Pakete.
Mit einer Neuinstallation bist du wesentlich besser bedient.

Btw. Ich habe auf einigen wirklich heiklen Maschinen solche Befehle durch Scripte ersetzt, die in genau so einem Fall meckern :)
 
Hi,

das Verzeichnis /usr/share/locale/ existiert noch, ab da gibts aber keine Übereinstimmung mehr mit diesen Pfaden. Das dpkg Package hab ich nochmal drübergebügelt, aber auch das hat den fopen Fehler gezeigt. Danach auch keine Besserung. Die Dateien existieren nachwievor nicht.

Zu welchem Packet gehören denn diese en_US.* Verzeichnisse?

cu
serow
 
Permissions in /usr/share/man sind alle rw-r--r--
Zum Vergrößern anklicken....

Auch von den Ordnern? Die koennen naemlich nur durchsucht (und folglich Dateien in ihnen zum Schreiben geoeffnet) werden, wenn sie das Executable Bit haben.

Code: 
find /usr/share/man -type d | while read d; do chmod +x $d; done
sollte Abhilfe schaffen.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben