j'ai sur mon disque quelques fichiers que je n'arrive pas à effacer, que
ce soit en tant qu'user ou en tant que root
les permissions me sont refusées
par exemple:
rm -f xheaders
rm: ne peut enlever `xheaders': Permission non accordée
pareil pour un repertoire et un autre fichier qui encombrent ma
corbeillent et doivent venir d'installations précédentes. Vous avez une
solution pour éradiquer ces geneurs ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TiChou
Dans le message <news:41ded7fa$0$24331$, *toufou* tapota sur f.c.o.l.configuration :
hugh
Yaw,
j'ai sur mon disque quelques fichiers que je n'arrive pas à effacer, que ce soit en tant qu'user ou en tant que root les permissions me sont refusées par exemple:
rm -f xheaders rm: ne peut enlever `xheaders': Permission non accordée
pareil pour un repertoire et un autre fichier qui encombrent ma corbeillent et doivent venir d'installations précédentes. Vous avez une solution pour éradiquer ces geneurs ?
Les raisons peuvent être multiples.
- le système de fichier, sur lequel sont présents les fichiers, est monté en mode read-only : vérifiez le avec la commande 'mount' et si c'est le cas, remontez le avec la commande 'mount -o remount,rw /point/montage',
- les fichiers sont en cours d'utilisation : vérifiez le avec la commande 'fuser fichier' et arrêtez le ou les processus en question,
- les fichiers ont l'attribut imutable définit : vérifiez le avec la commande 'lsattr' et supprimez l'attribut imutable avec la commande 'chattr -i fichier',
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
- le système tourne avec un noyau patché avec un patch sécurité tel que grsecurity et interdit certaines actions de s'effectuer, même au superutilisateur : vérifiez le noyau utilisé avec la commande 'uname -a' et voyez avec la commande 'dmesg' si des messages noyaux signalent le problème.
-- TiChou
Dans le message <news:41ded7fa$0$24331$626a14ce@news.free.fr>,
*toufou* tapota sur f.c.o.l.configuration :
hugh
Yaw,
j'ai sur mon disque quelques fichiers que je n'arrive pas à effacer, que
ce soit en tant qu'user ou en tant que root
les permissions me sont refusées
par exemple:
rm -f xheaders
rm: ne peut enlever `xheaders': Permission non accordée
pareil pour un repertoire et un autre fichier qui encombrent ma
corbeillent et doivent venir d'installations précédentes. Vous avez une
solution pour éradiquer ces geneurs ?
Les raisons peuvent être multiples.
- le système de fichier, sur lequel sont présents les fichiers, est monté en
mode read-only : vérifiez le avec la commande 'mount' et si c'est le cas,
remontez le avec la commande 'mount -o remount,rw /point/montage',
- les fichiers sont en cours d'utilisation : vérifiez le avec la commande
'fuser fichier' et arrêtez le ou les processus en question,
- les fichiers ont l'attribut imutable définit : vérifiez le avec la
commande 'lsattr' et supprimez l'attribut imutable avec la commande
'chattr -i fichier',
- le système de fichier est corrompu : vérifiez le et réparez le avec la
commande 'fsck'.
- le système tourne avec un noyau patché avec un patch sécurité tel que
grsecurity et interdit certaines actions de s'effectuer, même au
superutilisateur : vérifiez le noyau utilisé avec la commande 'uname -a' et
voyez avec la commande 'dmesg' si des messages noyaux signalent le problème.
Dans le message <news:41ded7fa$0$24331$, *toufou* tapota sur f.c.o.l.configuration :
hugh
Yaw,
j'ai sur mon disque quelques fichiers que je n'arrive pas à effacer, que ce soit en tant qu'user ou en tant que root les permissions me sont refusées par exemple:
rm -f xheaders rm: ne peut enlever `xheaders': Permission non accordée
pareil pour un repertoire et un autre fichier qui encombrent ma corbeillent et doivent venir d'installations précédentes. Vous avez une solution pour éradiquer ces geneurs ?
Les raisons peuvent être multiples.
- le système de fichier, sur lequel sont présents les fichiers, est monté en mode read-only : vérifiez le avec la commande 'mount' et si c'est le cas, remontez le avec la commande 'mount -o remount,rw /point/montage',
- les fichiers sont en cours d'utilisation : vérifiez le avec la commande 'fuser fichier' et arrêtez le ou les processus en question,
- les fichiers ont l'attribut imutable définit : vérifiez le avec la commande 'lsattr' et supprimez l'attribut imutable avec la commande 'chattr -i fichier',
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
- le système tourne avec un noyau patché avec un patch sécurité tel que grsecurity et interdit certaines actions de s'effectuer, même au superutilisateur : vérifiez le noyau utilisé avec la commande 'uname -a' et voyez avec la commande 'dmesg' si des messages noyaux signalent le problème.
-- TiChou
l'indien
On Fri, 07 Jan 2005 21:07:30 +0100, TiChou wrote:
Dans le message <news:41ded7fa$0$24331$, *toufou* tapota sur f.c.o.l.configuration :
hugh
Yaw,
j'ai sur mon disque quelques fichiers que je n'arrive pas à effacer, que ce soit en tant qu'user ou en tant que root les permissions me sont refusées par exemple:
rm -f xheaders rm: ne peut enlever `xheaders': Permission non accordée
pareil pour un repertoire et un autre fichier qui encombrent ma corbeillent et doivent venir d'installations précédentes. Vous avez une solution pour éradiquer ces geneurs ?
Les raisons peuvent être multiples.
- le système de fichier, sur lequel sont présents les fichiers, est monté en mode read-only : vérifiez le avec la commande 'mount' et si c'est le cas, remontez le avec la commande 'mount -o remount,rw /point/montage',
Le message d'erreur est différent, dans ce cas, il me semble ('read-only file system, en anglais, code erreur EROFS).
- les fichiers sont en cours d'utilisation : vérifiez le avec la commande 'fuser fichier' et arrêtez le ou les processus en question,
Ah non, ça n'est jamais une cause d'erreur: les fichiers ne sont alors pas supprimés physiquement tant qu'un programme les utilise mais ils sont marqués effacés et ne sont alors plus visible dans l'arborescence.
[...]
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas un 'permission denied'. J'en fait souvent l'expérience sur des devices peu fiables. Je ne sais plus si l'erreur renvoyée est EFAULT ou EINVAL mais de toute façon pas EPERM... Par contre, les messages d'erreurs explicitent n'apparaissent dans ce cas que sur les consoles, pas sur un xterm: il faut donc vérifier avec dmesg...
[...]
On Fri, 07 Jan 2005 21:07:30 +0100, TiChou wrote:
Dans le message <news:41ded7fa$0$24331$626a14ce@news.free.fr>,
*toufou* tapota sur f.c.o.l.configuration :
hugh
Yaw,
j'ai sur mon disque quelques fichiers que je n'arrive pas à effacer, que
ce soit en tant qu'user ou en tant que root
les permissions me sont refusées
par exemple:
rm -f xheaders
rm: ne peut enlever `xheaders': Permission non accordée
pareil pour un repertoire et un autre fichier qui encombrent ma
corbeillent et doivent venir d'installations précédentes. Vous avez une
solution pour éradiquer ces geneurs ?
Les raisons peuvent être multiples.
- le système de fichier, sur lequel sont présents les fichiers, est monté en
mode read-only : vérifiez le avec la commande 'mount' et si c'est le cas,
remontez le avec la commande 'mount -o remount,rw /point/montage',
Le message d'erreur est différent, dans ce cas, il me semble ('read-only
file system, en anglais, code erreur EROFS).
- les fichiers sont en cours d'utilisation : vérifiez le avec la commande
'fuser fichier' et arrêtez le ou les processus en question,
Ah non, ça n'est jamais une cause d'erreur:
les fichiers ne sont alors pas supprimés physiquement tant qu'un
programme les utilise mais ils sont marqués effacés et ne sont alors
plus visible dans l'arborescence.
[...]
- le système de fichier est corrompu : vérifiez le et réparez le avec la
commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas
un 'permission denied'. J'en fait souvent l'expérience sur des devices
peu fiables. Je ne sais plus si l'erreur renvoyée est EFAULT ou EINVAL
mais de toute façon pas EPERM... Par contre, les messages d'erreurs
explicitent n'apparaissent dans ce cas que sur les consoles, pas sur un
xterm: il faut donc vérifier avec dmesg...
Dans le message <news:41ded7fa$0$24331$, *toufou* tapota sur f.c.o.l.configuration :
hugh
Yaw,
j'ai sur mon disque quelques fichiers que je n'arrive pas à effacer, que ce soit en tant qu'user ou en tant que root les permissions me sont refusées par exemple:
rm -f xheaders rm: ne peut enlever `xheaders': Permission non accordée
pareil pour un repertoire et un autre fichier qui encombrent ma corbeillent et doivent venir d'installations précédentes. Vous avez une solution pour éradiquer ces geneurs ?
Les raisons peuvent être multiples.
- le système de fichier, sur lequel sont présents les fichiers, est monté en mode read-only : vérifiez le avec la commande 'mount' et si c'est le cas, remontez le avec la commande 'mount -o remount,rw /point/montage',
Le message d'erreur est différent, dans ce cas, il me semble ('read-only file system, en anglais, code erreur EROFS).
- les fichiers sont en cours d'utilisation : vérifiez le avec la commande 'fuser fichier' et arrêtez le ou les processus en question,
Ah non, ça n'est jamais une cause d'erreur: les fichiers ne sont alors pas supprimés physiquement tant qu'un programme les utilise mais ils sont marqués effacés et ne sont alors plus visible dans l'arborescence.
[...]
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas un 'permission denied'. J'en fait souvent l'expérience sur des devices peu fiables. Je ne sais plus si l'erreur renvoyée est EFAULT ou EINVAL mais de toute façon pas EPERM... Par contre, les messages d'erreurs explicitent n'apparaissent dans ce cas que sur les consoles, pas sur un xterm: il faut donc vérifier avec dmesg...
[...]
TiChou
Dans le message <news:, *l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
-- TiChou
Dans le message <news:pan.2005.01.08.00.02.37.719730@magic.fr>,
*l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec la
commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas
un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
Dans le message <news:, *l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
-- TiChou
toufou
hugh
Les raisons peuvent être multiples.
- le système de fichier, sur lequel sont présents les fichiers, est monté en mode read-only : vérifiez le avec la commande 'mount' et si c'est le cas, remontez le avec la commande 'mount -o remount,rw /point/montage', pas ça, c'est dans mon /home
- les fichiers sont en cours d'utilisation : vérifiez le avec la commande 'fuser fichier' et arrêtez le ou les processus en question,
non plus je donne le chemin exact, vous comprendrez vite: /home/perso/.Trash/Corbeille/.kde/share/apps/knode
- les fichiers ont l'attribut imutable définit : vérifiez le avec la commande 'lsattr' et supprimez l'attribut imutable avec la commande 'chattr -i fichier',
là ça me parle moins # lsattr ./scorefile: Permission non accordée ----------------- ./nntp.1 ./xheaders: Permission non accordée
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
je suis sous reiserfs3 et je pense pas que fsck fonctionne en plus, je ne sais quels arguments lui donner
- le système tourne avec un noyau patché avec un patch sécurité tel que grsecurity et interdit certaines actions de s'effectuer, même au superutilisateur : vérifiez le noyau utilisé avec la commande 'uname -a' et voyez avec la commande 'dmesg' si des messages noyaux signalent le problème.
noyau debian de base (ubuntu pour être plus exact) 2.6.8.1-4-k7. pas de
patch particulier, en tout cas,je n'en ai pas appliqué.
des idées ?
@+
hugh
Les raisons peuvent être multiples.
- le système de fichier, sur lequel sont présents les fichiers, est
monté en mode read-only : vérifiez le avec la commande 'mount' et si
c'est le cas, remontez le avec la commande 'mount -o remount,rw
/point/montage',
pas ça, c'est dans mon /home
- les fichiers sont en cours d'utilisation : vérifiez le avec la
commande 'fuser fichier' et arrêtez le ou les processus en question,
non plus
je donne le chemin exact, vous comprendrez vite:
/home/perso/.Trash/Corbeille/.kde/share/apps/knode
- les fichiers ont l'attribut imutable définit : vérifiez le avec la
commande 'lsattr' et supprimez l'attribut imutable avec la commande
'chattr -i fichier',
là ça me parle moins
# lsattr
./scorefile: Permission non accordée
----------------- ./nntp.1
./xheaders: Permission non accordée
- le système de fichier est corrompu : vérifiez le et réparez le avec la
commande 'fsck'.
je suis sous reiserfs3 et je pense pas que fsck fonctionne
en plus, je ne sais quels arguments lui donner
- le système tourne avec un noyau patché avec un patch sécurité tel que
grsecurity et interdit certaines actions de s'effectuer, même au
superutilisateur : vérifiez le noyau utilisé avec la commande 'uname -a'
et voyez avec la commande 'dmesg' si des messages noyaux signalent le
problème.
noyau debian de base (ubuntu pour être plus exact) 2.6.8.1-4-k7. pas de
patch particulier, en tout cas,je n'en ai pas appliqué.
- le système de fichier, sur lequel sont présents les fichiers, est monté en mode read-only : vérifiez le avec la commande 'mount' et si c'est le cas, remontez le avec la commande 'mount -o remount,rw /point/montage', pas ça, c'est dans mon /home
- les fichiers sont en cours d'utilisation : vérifiez le avec la commande 'fuser fichier' et arrêtez le ou les processus en question,
non plus je donne le chemin exact, vous comprendrez vite: /home/perso/.Trash/Corbeille/.kde/share/apps/knode
- les fichiers ont l'attribut imutable définit : vérifiez le avec la commande 'lsattr' et supprimez l'attribut imutable avec la commande 'chattr -i fichier',
là ça me parle moins # lsattr ./scorefile: Permission non accordée ----------------- ./nntp.1 ./xheaders: Permission non accordée
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
je suis sous reiserfs3 et je pense pas que fsck fonctionne en plus, je ne sais quels arguments lui donner
- le système tourne avec un noyau patché avec un patch sécurité tel que grsecurity et interdit certaines actions de s'effectuer, même au superutilisateur : vérifiez le noyau utilisé avec la commande 'uname -a' et voyez avec la commande 'dmesg' si des messages noyaux signalent le problème.
noyau debian de base (ubuntu pour être plus exact) 2.6.8.1-4-k7. pas de
patch particulier, en tout cas,je n'en ai pas appliqué.
des idées ?
@+
TiChou
Dans le message <news:41df2b42$0$15705$, *toufou* tapota sur f.c.o.l.configuration :
- les fichiers ont l'attribut imutable définit : vérifiez le avec la commande 'lsattr' et supprimez l'attribut imutable avec la commande 'chattr -i fichier',
là ça me parle moins # lsattr ./scorefile: Permission non accordée ----------------- ./nntp.1 ./xheaders: Permission non accordée
Les attributs ne fonctionnent que sur les systèmes de fichiers ext2/3 et je vois ci-dessous que ça n'est pas votre cas. Par contre, même si votre système de fichiers n'est pas ext2/3, le fait que la commande 'lsattr' vous retourne ces messages d'erreurs montre qu'il y a un problème d'accès sur ces fichiers.
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
je suis sous reiserfs3 et je pense pas que fsck fonctionne en plus,
Pourquoi il ne fonctionnerai pas ?
je ne sais quels arguments lui donner
$ fsck [options] -t reiserfs /dev/hdXY
ou
$ fsck.reiserfs [options] /dev/hdXY
ou
$ reiserfsck [options] /dev/hdXY
Bien évidemment il faut que le paquet reiserfsprogs soit installé.
-- TiChou
Dans le message <news:41df2b42$0$15705$626a14ce@news.free.fr>,
*toufou* tapota sur f.c.o.l.configuration :
- les fichiers ont l'attribut imutable définit : vérifiez le avec la
commande 'lsattr' et supprimez l'attribut imutable avec la commande
'chattr -i fichier',
là ça me parle moins
# lsattr
./scorefile: Permission non accordée
----------------- ./nntp.1
./xheaders: Permission non accordée
Les attributs ne fonctionnent que sur les systèmes de fichiers ext2/3 et je
vois ci-dessous que ça n'est pas votre cas.
Par contre, même si votre système de fichiers n'est pas ext2/3, le fait que
la commande 'lsattr' vous retourne ces messages d'erreurs montre qu'il y a
un problème d'accès sur ces fichiers.
- le système de fichier est corrompu : vérifiez le et réparez le avec la
commande 'fsck'.
je suis sous reiserfs3 et je pense pas que fsck fonctionne
en plus,
Pourquoi il ne fonctionnerai pas ?
je ne sais quels arguments lui donner
$ fsck [options] -t reiserfs /dev/hdXY
ou
$ fsck.reiserfs [options] /dev/hdXY
ou
$ reiserfsck [options] /dev/hdXY
Bien évidemment il faut que le paquet reiserfsprogs soit installé.
Dans le message <news:41df2b42$0$15705$, *toufou* tapota sur f.c.o.l.configuration :
- les fichiers ont l'attribut imutable définit : vérifiez le avec la commande 'lsattr' et supprimez l'attribut imutable avec la commande 'chattr -i fichier',
là ça me parle moins # lsattr ./scorefile: Permission non accordée ----------------- ./nntp.1 ./xheaders: Permission non accordée
Les attributs ne fonctionnent que sur les systèmes de fichiers ext2/3 et je vois ci-dessous que ça n'est pas votre cas. Par contre, même si votre système de fichiers n'est pas ext2/3, le fait que la commande 'lsattr' vous retourne ces messages d'erreurs montre qu'il y a un problème d'accès sur ces fichiers.
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
je suis sous reiserfs3 et je pense pas que fsck fonctionne en plus,
Pourquoi il ne fonctionnerai pas ?
je ne sais quels arguments lui donner
$ fsck [options] -t reiserfs /dev/hdXY
ou
$ fsck.reiserfs [options] /dev/hdXY
ou
$ reiserfsck [options] /dev/hdXY
Bien évidemment il faut que le paquet reiserfsprogs soit installé.
-- TiChou
l'indien
On Sat, 08 Jan 2005 01:37:11 +0100, TiChou wrote:
Dans le message <news:, *l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
Ah ? Ca doit dépendre du filesystem utilisé, alors, sans doute...
On Sat, 08 Jan 2005 01:37:11 +0100, TiChou wrote:
Dans le message <news:pan.2005.01.08.00.02.37.719730@magic.fr>,
*l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec la
commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas
un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
Ah ? Ca doit dépendre du filesystem utilisé, alors, sans doute...
Dans le message <news:, *l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
Ah ? Ca doit dépendre du filesystem utilisé, alors, sans doute...
TiChou
Dans le message <news:, *l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
Ah ? Ca doit dépendre du filesystem utilisé, alors, sans doute...
C'était du ext3. Suite à un fsck qui avait mal tourné, j'avais du réinstaller mon système sur un autre disque. Ensuite, quand j'ai voulu récupérer des données et faire le ménage sur l'ancien disque, j'avais été confronté à des 'Permission denied' et le seul moyen de remettre les choses en ordre c'était de refaire un fsck pour réparer le système de fichier qui était endommagé.
-- TiChou
Dans le message <news:pan.2005.01.08.13.04.29.930076@magic.fr>,
*l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec
la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas
un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
Ah ? Ca doit dépendre du filesystem utilisé, alors, sans doute...
C'était du ext3. Suite à un fsck qui avait mal tourné, j'avais du
réinstaller mon système sur un autre disque. Ensuite, quand j'ai voulu
récupérer des données et faire le ménage sur l'ancien disque, j'avais été
confronté à des 'Permission denied' et le seul moyen de remettre les choses
en ordre c'était de refaire un fsck pour réparer le système de fichier qui
était endommagé.
Dans le message <news:, *l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
Ah ? Ca doit dépendre du filesystem utilisé, alors, sans doute...
C'était du ext3. Suite à un fsck qui avait mal tourné, j'avais du réinstaller mon système sur un autre disque. Ensuite, quand j'ai voulu récupérer des données et faire le ménage sur l'ancien disque, j'avais été confronté à des 'Permission denied' et le seul moyen de remettre les choses en ordre c'était de refaire un fsck pour réparer le système de fichier qui était endommagé.
-- TiChou
l'indien
On Sat, 08 Jan 2005 15:22:05 +0100, TiChou wrote:
Dans le message <news:, *l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
Ah ? Ca doit dépendre du filesystem utilisé, alors, sans doute...
C'était du ext3. Suite à un fsck qui avait mal tourné, j'avais du réinstaller mon système sur un autre disque. Ensuite, quand j'ai voulu récupérer des données et faire le ménage sur l'ancien disque, j'avais été confronté à des 'Permission denied' et le seul moyen de remettre les choses en ordre c'était de refaire un fsck pour réparer le système de fichier qui était endommagé.
Je te crois, mais à mon sens, c'est un bug de ext3: root devrait toujours pouvoir d'une manière ou d'une autre supprimer les fichiers corrompus ou les déplacer pour les "soigner".
On Sat, 08 Jan 2005 15:22:05 +0100, TiChou wrote:
Dans le message <news:pan.2005.01.08.13.04.29.930076@magic.fr>,
*l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec
la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas
un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
Ah ? Ca doit dépendre du filesystem utilisé, alors, sans doute...
C'était du ext3. Suite à un fsck qui avait mal tourné, j'avais du
réinstaller mon système sur un autre disque. Ensuite, quand j'ai voulu
récupérer des données et faire le ménage sur l'ancien disque, j'avais été
confronté à des 'Permission denied' et le seul moyen de remettre les choses
en ordre c'était de refaire un fsck pour réparer le système de fichier qui
était endommagé.
Je te crois, mais à mon sens, c'est un bug de ext3: root devrait toujours
pouvoir d'une manière ou d'une autre supprimer les fichiers corrompus ou
les déplacer pour les "soigner".
Dans le message <news:, *l'indien* tapota sur f.c.o.l.configuration :
- le système de fichier est corrompu : vérifiez le et réparez le avec la commande 'fsck'.
Dans ce cas, il y a des messages d'erreurs explicites du noyau, mais pas un 'permission denied'.
Si, j'ai déjà rencontré ce phénomène sur des fs corrompus.
Ah ? Ca doit dépendre du filesystem utilisé, alors, sans doute...
C'était du ext3. Suite à un fsck qui avait mal tourné, j'avais du réinstaller mon système sur un autre disque. Ensuite, quand j'ai voulu récupérer des données et faire le ménage sur l'ancien disque, j'avais été confronté à des 'Permission denied' et le seul moyen de remettre les choses en ordre c'était de refaire un fsck pour réparer le système de fichier qui était endommagé.
Je te crois, mais à mon sens, c'est un bug de ext3: root devrait toujours pouvoir d'une manière ou d'une autre supprimer les fichiers corrompus ou les déplacer pour les "soigner".
