Je suis sur une debian 6, à jour.
Dans un shell, je commence avec l'utilisateur "toto" et je passe root
avec la commande "su -"
Ensuite, ça devient amusant....
(j'ai juste changé les noms de machine et d'utilisateur) (toto est un
utilisateur "normal") (il s'agit d'une machine serveur avec ISPConfig)
("rm" n'est pas un alias)
toto@mamachine:~$ su -
Mot de passe :
root@mamachine:~# cd /home/toto/
root@mamachine:/home/toto# ls -ls
76100 -rw-r--r-- 1 users toto 77925092 18 févr. 2011 truc.tar.gz
root@mamachine:/home/toto# rm truc.tar.gz
rm: impossible de supprimer « truc.tar.gz »: Permission non accordée
juste au cas ou :
root@mamachine:/home/toto# chmod 777 truc.tar.gz
root@mamachine:/home/toto# ls -ls
76100 -rwxrwxrwx 1 users toto 77925092 18 févr. 2011 truc.tar.gz
root@mamachine:/home/toto# rm truc.tar.gz
rm: impossible de supprimer « truc.tar.gz »: Permission non accordée
root@mamachine:/home/toto#
En fait, je ne peux rien faire, même sous root, dans ce répertoire...
Je suis sur une debian 6, à jour. Dans un shell, je commence avec l'utilisateur "toto" et je passe root avec la commande "su -" Ensuite, ça devient amusant.... (j'ai juste changé les noms de machine et d'utilisateur) (toto est un utilisateur "normal") (il s'agit d'une machine serveur avec ISPConfig) ("rm" n'est pas un alias)
:~$ su -
Mot de passe :
:~# cd /home/toto/ :/home/toto# ls -ls 76100 -rw-r--r-- 1 users toto 77925092 18 févr. 2011 truc.tar.gz :/home/toto# rm truc.tar.gz rm: impossible de supprimer « truc.tar.gz »: Permission non accordée
juste au cas ou :
:/home/toto# chmod 777 truc.tar.gz :/home/toto# ls -ls 76100 -rwxrwxrwx 1 users toto 77925092 18 févr. 2011 truc.tar.gz :/home/toto# rm truc.tar.gz rm: impossible de supprimer « truc.tar.gz »: Permission non accordée :/home/toto#
En fait, je ne peux rien faire, même sous root, dans ce répertoire...
Mais qu'est ce qui se passe docteur ?
Une petite idée dont personne a parlé
un fsck sur le file system en question corrigerait peut etre le tir j'ai eu le cas il y a peu sur un /boot avec l'initrd
Le 31/05/2013 01:22, Marcel a écrit :
Je suis sur une debian 6, à jour.
Dans un shell, je commence avec l'utilisateur "toto" et je passe root avec la commande "su -"
Ensuite, ça devient amusant....
(j'ai juste changé les noms de machine et d'utilisateur) (toto est un utilisateur "normal") (il
s'agit d'une machine serveur avec ISPConfig) ("rm" n'est pas un alias)
toto@mamachine:~$ su -
Mot de passe :
root@mamachine:~# cd /home/toto/
root@mamachine:/home/toto# ls -ls
76100 -rw-r--r-- 1 users toto 77925092 18 févr. 2011 truc.tar.gz
root@mamachine:/home/toto# rm truc.tar.gz
rm: impossible de supprimer « truc.tar.gz »: Permission non accordée
juste au cas ou :
root@mamachine:/home/toto# chmod 777 truc.tar.gz
root@mamachine:/home/toto# ls -ls
76100 -rwxrwxrwx 1 users toto 77925092 18 févr. 2011 truc.tar.gz
root@mamachine:/home/toto# rm truc.tar.gz
rm: impossible de supprimer « truc.tar.gz »: Permission non accordée
root@mamachine:/home/toto#
En fait, je ne peux rien faire, même sous root, dans ce répertoire...
Mais qu'est ce qui se passe docteur ?
Une petite idée dont personne a parlé
un fsck sur le file system en question corrigerait peut etre le tir
j'ai eu le cas il y a peu sur un /boot avec l'initrd
Je suis sur une debian 6, à jour. Dans un shell, je commence avec l'utilisateur "toto" et je passe root avec la commande "su -" Ensuite, ça devient amusant.... (j'ai juste changé les noms de machine et d'utilisateur) (toto est un utilisateur "normal") (il s'agit d'une machine serveur avec ISPConfig) ("rm" n'est pas un alias)
:~$ su -
Mot de passe :
:~# cd /home/toto/ :/home/toto# ls -ls 76100 -rw-r--r-- 1 users toto 77925092 18 févr. 2011 truc.tar.gz :/home/toto# rm truc.tar.gz rm: impossible de supprimer « truc.tar.gz »: Permission non accordée
juste au cas ou :
:/home/toto# chmod 777 truc.tar.gz :/home/toto# ls -ls 76100 -rwxrwxrwx 1 users toto 77925092 18 févr. 2011 truc.tar.gz :/home/toto# rm truc.tar.gz rm: impossible de supprimer « truc.tar.gz »: Permission non accordée :/home/toto#
En fait, je ne peux rien faire, même sous root, dans ce répertoire...
Mais qu'est ce qui se passe docteur ?
Une petite idée dont personne a parlé
un fsck sur le file system en question corrigerait peut etre le tir j'ai eu le cas il y a peu sur un /boot avec l'initrd
Olivier Miakinen
Le 02/06/2013 10:01, Philippe Weill a écrit :
Une petite idée dont personne a parlé
un fsck sur le file system en question corrigerait peut etre le tir j'ai eu le cas il y a peu sur un /boot avec l'initrd
En fait Sergio et moi en avons parlé et Marcel a dit qu'il allait le faire. Je ne sais pas s'il l'a fait effectivement.
Le 02/06/2013 10:01, Philippe Weill a écrit :
Une petite idée dont personne a parlé
un fsck sur le file system en question corrigerait peut etre le tir
j'ai eu le cas il y a peu sur un /boot avec l'initrd
En fait Sergio et moi en avons parlé et Marcel a dit qu'il allait le
faire. Je ne sais pas s'il l'a fait effectivement.
Je suis sur une debian 6, à jour. Dans un shell, je commence avec l'utilisateur "toto" et je passe root avec la commande "su -" Ensuite, ça devient amusant.... (j'ai juste changé les noms de machine et d'utilisateur) (toto est un utilisateur "normal") (il s'agit d'une machine serveur avec ISPConfig) ("rm" n'est pas un alias)
:~$ su -
Mot de passe :
:~# cd /home/toto/ :/home/toto# ls -ls 76100 -rw-r--r-- 1 users toto 77925092 18 févr. 2011 truc.tar.gz :/home/toto# rm truc.tar.gz rm: impossible de supprimer « truc.tar.gz »: Permission non accordée
Peut être que je dis une bêtise mais il m'est arrivé d'avoir un truc pareil.
Je passe sous mc, en root, et je supprime le fichier avec la touche f8.
Si je me gourre complètement, n'hésitez pas en m'en faire part !
-- Jean-Jacques Gerbaud entre Dauphiné et PACA
Le 31/05/2013 01:22, Marcel a écrit :
Je suis sur une debian 6, à jour.
Dans un shell, je commence avec l'utilisateur "toto" et je passe root
avec la commande "su -"
Ensuite, ça devient amusant....
(j'ai juste changé les noms de machine et d'utilisateur) (toto est un
utilisateur "normal") (il s'agit d'une machine serveur avec ISPConfig)
("rm" n'est pas un alias)
toto@mamachine:~$ su -
Mot de passe :
root@mamachine:~# cd /home/toto/
root@mamachine:/home/toto# ls -ls
76100 -rw-r--r-- 1 users toto 77925092 18 févr. 2011 truc.tar.gz
root@mamachine:/home/toto# rm truc.tar.gz
rm: impossible de supprimer « truc.tar.gz »: Permission non accordée
Peut être que je dis une bêtise mais il m'est arrivé d'avoir un truc pareil.
Je passe sous mc, en root, et je supprime le fichier avec la touche f8.
Si je me gourre complètement, n'hésitez pas en m'en faire part !
Je suis sur une debian 6, à jour. Dans un shell, je commence avec l'utilisateur "toto" et je passe root avec la commande "su -" Ensuite, ça devient amusant.... (j'ai juste changé les noms de machine et d'utilisateur) (toto est un utilisateur "normal") (il s'agit d'une machine serveur avec ISPConfig) ("rm" n'est pas un alias)
:~$ su -
Mot de passe :
:~# cd /home/toto/ :/home/toto# ls -ls 76100 -rw-r--r-- 1 users toto 77925092 18 févr. 2011 truc.tar.gz :/home/toto# rm truc.tar.gz rm: impossible de supprimer « truc.tar.gz »: Permission non accordée
Peut être que je dis une bêtise mais il m'est arrivé d'avoir un truc pareil.
Je passe sous mc, en root, et je supprime le fichier avec la touche f8.
Si je me gourre complètement, n'hésitez pas en m'en faire part !
-- Jean-Jacques Gerbaud entre Dauphiné et PACA
Marcel
Philippe Weill a écrit :
un fsck sur le file system en question corrigerait peut etre le tir j'ai eu le cas il y a peu sur un /boot avec l'initrd
Comme le problème se situe sur un point de montage, j'ai fait (en root) # touch /var/forcefsck # shutdown -r now
Au redémarrage, le /var/forcefsck était toujours dans le répertoire. Donc : # cd / # touch forcefsck # shutdown -r now
Au redémarrage, le /forcefsck avait disparu. Mais le problème est toujours présent...
Je désespère...
Philippe Weill a écrit :
un fsck sur le file system en question corrigerait peut etre le tir
j'ai eu le cas il y a peu sur un /boot avec l'initrd
Comme le problème se situe sur un point de montage, j'ai fait (en root)
# touch /var/forcefsck
# shutdown -r now
Au redémarrage, le /var/forcefsck était toujours dans le répertoire.
Donc :
# cd /
# touch forcefsck
# shutdown -r now
Au redémarrage, le /forcefsck avait disparu. Mais le problème est
toujours présent...
