[fedora] gnome vind permissie verandering /tmp niet lief

[Sailorman]

Vandaag heb iets potencieels heel doms gedaan met mijn vrij verse Fedora Core 1 installatie.

Ik had het perl programma dvd::rip geinstalleerd maar dit werkte niet goed, aangezien dvd::rip allerlei lege vreemde bestanden in /tmp neersmeet en deze vervolgens niet meer weghaalde wilde ik die verwijderen, echter dit lukte niet zomaar met een rm -r --force vandaar dat ik eerst chmod -r 777 /tmp gedaan heb.

Vanaf dat moment functioneerd geen enkel gnome programma nog goed. Gelukkig draai ik KDE dus zo'n ernstige ramp is het niet, maar het is wel onhandig dat ik programma's als Evolution niet meer aan de gang krijg. Ook bij het starten van KDE krijg ik nogal wat foutmeldingen. Deze zijn allemaal toe te spitsen op het feit dat er een bestand dat in /tmp moet staan niet meer gelezen/gevonden kan worden ORBit en GConf crashen met deze mededelingen en ik krijg segfaults in XMMS als ik muziek probeer af te spelen via de Arts plugin. De betreffende directory in /tmp die aangeroepen wordt is leeg.

Ik neem aan dat de permissie verandering van /tmp naar 777 een hele domme actie van mij is geweest. Ik weet echter niet welke permissies deze directory standaard hoort te hebben, en als ik deze eenmaal terug gezet heb of ik dit probleem nog opgelost krijg zonder fedora opnieuw te installeren. Ik heb geprobeerd om GConf en ORBit te deinstalleren en opnieuw te installeren via apt-get. Dit mocht echter niet baten.

De exacte foutmeldingen kan ik hier niet weergeven omdat ik op dit moment niet thuis ben. Mocht dit nodig zijn dan kan ik die vanavond nog wel even achter dit bericht aan plakken.

Iemand enig idee in welke richting ik de oplossing kan zoeken?

[Verwijderd]

chmod -r 777 doet niks met die 777 volgens de manual page. Je voert alleen een -r (weghalen read access) uit. Makkelijk op te lossen met chmod +r /tmp.
Ik neem aan dat je chmod -R 777 /tmp had willen uitvoeren...

[AlterEgo]

/tmp (de dir) is bij bij 1777

De directories in /tmp worden na een reboot opnieuw opgebouwd (dat weet ik zeker, want /tmp is een ramdisk bij mij). Dus zou je vanaf init 1 alles binnen /tmp moeten kunnen weggooien, en vervolgens weer terug naar init 5 gaan. Dat zou je permissies hersteld moeten hebben.

[Wilke]

Wat AlterEgo zegt.

Waarschijnlijk heb je nu per ongeluk het 'sticky' bit uitgezet, en kan alleen de eigenaar (waarschijnlijk root.root) nog in /tmp schrijven. Aangezien veel programma's toch echt /tmp nodig hebben, werkt daardoor van alles en nogwat niet goed meer, tenzij je het als root draait (slecht plan!)

Uitleg uit 'man chmod':

The `sticky bit' [..], when
set for a directory, means that only the owner of the file and the
owner of that directory may remove the file from that directory. (This
is commonly used on directories like /tmp that have general write per-
mission.)

Waarmee ik maar wil zeggen: lees de volgende keer ook eerst even de manpage door voor je een vraag stelt! Je wist tenslotte al hoe het commando heette waarmee je het per ongeluk had gesloopt, en door de manual page te lezen was je er ws. zelf ook wel opgekomen dat hier het probleem lag

[_JGC_]

alle progsels afsluiten, dan inloggen als root in de console:

rm -r /tmp/*
chmod 777 /tmp
chmod +t /tmp

kan zijn dat je moet rebooten om bepaalde lockfiles voor X weer aan te maken, maar meestal zou je zo weer progsels kunnen starten.

[Sailorman]

Mensen, bedankt voor de reply's. Hier kan ik wat mee.
Teneerste, het uitgevoerde commando was natuurlijk chmod -R 777 voor recursive en niet met een kleine r zoals in mijn openingspost, mijn fout.

Het verwijderen van alle bestanden uit /tmp en het terugzetten van +t bleek de oplossing te zijn. Uiteindelijk dus een simpel probleem met een simpele oplossing

En wat hebben we hiervan geleerd? Niet zomaar kloten met commando's waar je de uitwerking niet van kent