Hello,

J'ai un potentiel très gros soucis, j'ai un disque interne en ext4 de 1.5 Tio uniquement pour les data

Lorsque je le monte en faisant mount /dev/sdc1 /media et que je fais un ls -lhi, je me retrouve avec ca :
myu localhost  /media $ ls -lhi
ls: cannot access FHS: Permission denied
total 184M
25034753 drwxrwxrwx. 10 myu  myu  4.0K Jun 26 22:48 Data
      ? d??????????  ? ?    ?       ?            ? FHS
36700161 drwxrwxrwx.  9 myu  myu  4.0K Jul  6 20:59 Linux
19791873 drwxrwxrwx+  2 root root 4.0K Oct 21 01:59 myu
      14 -rwxrwxrwx.  1 myu  myu  184M Nov 10 22:37 slax-7.0-kde4-2012-11-06-i486.iso

Ca a vraiment l'air d'une mauvaise blague...le FHS est normalement un dossier ou je maintient un hiérarchie spéciale pour mes fichiers (différents dossiers, etc)

Je pense l'avoir éclaté, peut être a cause d'un script rsync concu pour copier des fichiers de mon /home vers ce disque dur dans le répertoire FHS... qui fait le malin, tombe dans le ravin x)

Quelqu'un aurait une idée de comment "récupérer" ? 🙁
Si tu peux vraiment pas récupérer la partition de manière classique, tu peux toujours tout récupérér "à la main", en utilisant foremost (par exemple) :
# foremost -vi /dev/sdb1 -o /recup
Avec /dev/sdb1 la bonne partition de ton disque externe et /recup le dossier où tu vas récupérer tout le bazar.

Par contre, ça va être hypra long. Ça prend une bonne demie-heure sur une clé de 2Go (si ma mémoire est bonne)...
Bonsoir Valdes,

Merci pour la commande, je l'avais déja utilisée en son temps.

J'ai juste encore un truc qui me tracasse, j'ai des données encore OK sur ce disque, foremost va t'il les faire sauter ? J'imagine que c'est pas l'idée, mais je ne sais pas ce qu'il reste du système de fichiers cible après ce genre de restauration...
foremost ne supprime rien, il se contente de tout copier ailleurs, en lisant directement sur le disque.

Mais bon, avant d'en arriver là, je te conseille d'attendre les avis d'autres personnes. Il y a peut-être un moyen de réparer ça plus rapidement.
Permission denied
Tu as essayé sous root ?
nouvo09 wrote:
Permission denied

Tu as essayé sous root ?
Oui, rien n'y fait :/ ce dossier n'a plus de permissions, impossible de les redéfinir même en root
[root@localhost media]# ls -lhi
ls: cannot access FHS: Permission denied
ls: cannot access lost+found: Permission denied
total 184M
25034753 drwxrwxrwx. 10 myu  myu  4.0K Jun 26 22:48 Data
       ? d??????????  ? ?    ?       ?            ? FHS
50987009 drwxrwxr-x.  9 myu  myu  4.0K Dec  2 20:16 HS
36700161 drwxrwxrwx.  9 myu  myu  4.0K Jul  6 20:59 Linux
       ? d??????????  ? ?    ?       ?            ? lost+found
19791873 drwxrwxrwx+  2 root root 4.0K Oct 21 01:59 myu
70647809 drwxrwxr-x.  2 myu  myu  4.0K Dec  2 20:58 recup
      14 -rwxrwxrwx.  1 myu  myu  184M Nov 10 22:37 slax-7.0-kde4-2012-11-06-i486.iso
tu peux essayer un fsck -P (il ne répare rien, il fait juste le diagnostic)
Salut,

J'ai eu le même problème ce soir avec 4 partitions (2 de type ext4, une de type ext3 et une autre de type xfs) sur 3 disques différents (ce qui réduit la probabilité de l'hypothèse "panne de disque"), fsck me signalant que les systèmes de fichier sont propres.

Rien à signaler par contre (une bonne prise de tête évitée pour le moment) sur l'une ou l'autre des partitions en passant sous Fedora 17 8-)
Cela devrait te redonner le sourire si tu as pensé avoir perdu tes données :-D

C'est probablement une mise à jour d'aujourd'hui ou d'hier qui passe mal, vu qu'en rédémarrant ensuite sur Spherical Cow, le problème est à nouveau présent... le plus étrange étant que mes partitions / et /boot ne sont pas impactées.

SELinux est-il en mode "appliqué" sur ta machine ? Sur la mienne, il l'est. Et dans la liste de paquets mis à jour, seuls ceux le concernant me paraissent à première vue susceptibles de provoquer des conflits niveau permissions d'accès. Une piste peut-être...
Dec 03 21:16:28 Updated: pango-1.32.3-1.fc18.x86_64
Dec 03 21:16:30 Updated: selinux-policy-3.11.1-59.fc18.noarch
Dec 03 21:16:32 Updated: telepathy-logger-0.6.0-3.fc18.x86_64
Dec 03 21:16:34 Updated: anaconda-widgets-18.34-1.fc18.x86_64
Dec 03 21:16:39 Updated: xulrunner-17.0.1-1.fc18.x86_64
Dec 03 21:16:40 Updated: libnfnetlink-1.0.1-1.fc18.x86_64
Dec 03 21:16:41 Installed: libmnl-1.0.3-4.fc18.x86_64
Dec 03 21:16:42 Installed: python-zope-event-3.5.1-4.fc18.noarch
Dec 03 21:16:43 Updated: xorg-x11-server-common-1.13.0-11.fc18.x86_64
Dec 03 21:16:44 Updated: xorg-x11-server-Xorg-1.13.0-11.fc18.x86_64
Dec 03 21:16:46 Updated: python-zope-interface-4.0.2-3.fc18.x86_64
Dec 03 21:16:47 Updated: libnetfilter_conntrack-1.0.2-1.fc18.x86_64
Dec 03 21:16:57 Updated: firefox-17.0.1-1.fc18.x86_64
Dec 03 21:17:05 Updated: anaconda-18.34-1.fc18.x86_64
Dec 03 21:17:08 Updated: gnome-shell-3.6.2-3.fc18.x86_64
Dec 03 21:17:17 Updated: empathy-3.6.2-2.fc18.x86_64
Dec 03 21:18:08 Updated: selinux-policy-targeted-3.11.1-59.fc18.noarch
Dec 03 21:18:12 Updated: selinux-policy-doc-3.11.1-59.fc18.noarch
Dec 03 21:18:46 Updated: selinux-policy-devel-3.11.1-59.fc18.noarch
Dec 03 21:18:48 Updated: pango-devel-1.32.3-1.fc18.x86_64
Dec 03 21:18:51 Updated: tzdata-java-2012j-1.fc18.noarch
Dec 03 21:18:56 Updated: tzdata-2012j-1.fc18.noarch
Dec 02 00:18:12 Installed: selinux-policy-doc-3.11.1-57.fc18.noarch
Dec 02 00:20:30 Installed: policycoreutils-devel-2.1.13-37.fc18.x86_64
Dec 02 01:59:56 Installed: libxml++-2.36.0-1.fc18.x86_64
Dec 02 01:59:58 Installed: libffado-2.1.0-1.fc18.x86_64
Dec 02 02:00:02 Installed: jack-audio-connection-kit-1.9.8-13.fc18.x86_64
Dec 02 02:00:04 Installed: zbar-0.10-11.fc18.x86_64
Dec 02 02:00:04 Installed: gstreamer1-plugins-bad-free-extras-1.0.3-1.fc18.x86_64
Dec 02 02:00:05 Installed: gstreamer1-plugins-good-extras-1.0.3-1.fc18.x86_64
Dec 02 02:00:07 Installed: gstreamer1-libav-1.0.2-2.fc18.x86_64
Dec 02 02:00:08 Installed: gstreamer1-plugins-bad-freeworld-1.0.2-2.fc18.x86_64
Dec 02 02:00:10 Installed: gstreamer1-plugins-ugly-1.0.2-2.fc18.x86_64

Edit: Il s'agit bien d'un problème SELinux et le bug semble confirmé. Il faut passer en mode "permissif" en attendant la prochaine mise à jour.

Soit via la console d'administration SELinux, à installer avec la commande :
$ su -lc 'yum -y install policycoreutils-gui'
Soit via la commande :
$ su -lc 'setenforce 0'
Soit encore en éditant le fichier /etc/sysconfig/selinux, changeant
SELINUX=enforcing
en
SELINUX=permissive
avant de rebooter.

Pour basculer du mode "appliqué" au mode "permissif" temporairement (pas persistant au reboot) :
$ su -lc setenforce
Bonjour,

Pour info : J'avais aussi le même problème sur 3 partitions (présence des ??????) depuis 2 jours et l'avais résolu par setenforce 0
sestatus m'a indiqué le fichier config a modifier (/etc/selinux/config) :
[root@localhost ~]# sestatus 
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          permissive
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28
Grand merci à tous dont CanalGuada et Did qui ont trouvé la racine du bousin, un setenforce 0 à tout résolu, SELinux était bien en mode "appliqué" auparavant et c'est cela qui causait problème

Ouf ! Mes données sont là 🙂

PS : @nouvo09 : le fsck n'aura pas fait de mal, 182 montage du disque sans check !