Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
856 connectés 

  FORUM HardWare.fr
  Linux et OS Alternatifs
  Divers

  Problème de permisision pour accès dossier en lecture via session live

 



 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

Problème de permisision pour accès dossier en lecture via session live

n°1451739
corias
Posté le 18-07-2020 à 21:36:21  profilanswer
 

Bonjour,  
Je suis un gros noob en Linux mais j'ai fait qques recherches infructueuse..
J'avais pommé des fichier que j'ai tenté de récupérer avec foremost sauf que dans l'opération Foremost a rempli le disque avec les fichiers récupérés auquel j'essais d'accéder mais comme le disque est plein Ubuntu ne démarre plus.
 
J'ai donc booté sur une clef en mode live mais lorsque j'essaie de copier les fichiers récupérés je n'ai pas la permission de lire sur ces répertoire. J'ai tenté après la création d'un compte admin en plus du live user mais sans succès..Je ne suis pas root sur la partition qui m'intéresse. Je n'ai pas la main pour modifier les permissions n'étant pas owner de ces dossiers.
Je ne peux donc ni récupérer ces dossiers ce qui libererait de l'espace disque pour booter ni pour faire le ménage ne sachant pas d'ailleurs ce que je pourrais supprimer.
 
J'ai déjà tenté en mode recovery quelques lignes de commandes pour purger les anciens paquets ou noyaux mais ça n'a rien libéré malgré l'absence de message d'erreur...
 
Si qqn pouvait m'aider car là je rame et ce n'est qu'une histoire de permissions. Je pète un plomb :pt1cable:  
 
J'ignore si il y a une solution mais
Merci d'avance pour vos suggestions!

mood
Publicité
Posté le 18-07-2020 à 21:36:21  profilanswer
 

n°1451748
kaari
Fuck Yeah !
Posté le 19-07-2020 à 11:25:04  profilanswer
 

Salut,
sudo su -
Pour te logger en root, et si tu aura tous les pouvoir (a quelques exceptions près).

 

Soit dit en passant, pour toutes les opérations de récupérations sur les disques, ils ne fait PAS recover sur le même disque. Si tu fais ça, toutes les données que tu veux récupérer sont écrasées ...

Message cité 1 fois
Message édité par kaari le 19-07-2020 à 11:26:40

---------------
Mon topic ventes ;)
n°1451749
Trit'
Posté le 19-07-2020 à 12:18:33  profilanswer
 


NON !!! Jamais ! :non:
 
Pour passer root en étant déjà connecté sous ton username, tu fais soit « su - » tout court, soit « sudo -i » (ou -s, ou -c,  mais après, c’est le contenu du $PATH qui varie), mais on n’emploie jamais, jamais « su » avec « sudo » ! :non:

n°1451750
kaari
Fuck Yeah !
Posté le 19-07-2020 à 15:34:34  profilanswer
 

Je suis bien curieux des arguments pour justifier cette déclaration.
Les 2 commandes (sudo -i et sudo su -) arrivent sensiblement au même résultat, pourquoi utiliser la 2eme façon serait "dangereux" ?


Message édité par kaari le 19-07-2020 à 15:38:01

---------------
Mon topic ventes ;)
n°1451751
Trit'
Posté le 19-07-2020 à 17:25:35  profilanswer
 

Parce que c’est une manière très crade de passer root (tu demandes de passer en root – « su - » – en tant que root – via « sudo » –, c’est inutilement redondant) quand il y en a des bien plus propres (« sudo -i » ou « su - » tout court) ; et surtout, que la commande « su » n’a pas besoin d’être exécutée avec « sudo » pour fonctionner (surtout si l’utilisateur n’a pas les droits pour utiliser « sudo », ce qui peut arriver selon les distributions).

n°1451754
kaari
Fuck Yeah !
Posté le 19-07-2020 à 18:44:17  profilanswer
 

sudo -i et su - ne sont pas équivalent, l'un appelle sudo pour élever tes droits, l'autre est un login standard. La grosse différence est que dans un cas tu dois entrer le mot de passe root, dans l'autre tu te soumets aux règles des sudoers.
 
L'équivalence ici c'est sudo -i et sudo su -.
Dans un cas tu fais appel à sudo pour Spawn un shell root dans son environment, dans l'autre tu fais appel à sudo pour te login en root. Le résultat est le même, en l'état il y a des différences mais si la seule différence de résultat est que un cas est "crade" parce que tu fais appel à 2 utilitaires au lieu d'un c'est assez subjectif et une affaire de style.
 
Par exemple on pourrait dire que sudo su - est préférable car il affiche un "su", qui est clairement un "login", ce qui est plus clair pour un neophyte. Quelqu'un d'autre pourrait te dire qu'il préfère utiliser sudo su et sudo su - car il "oublie toujours qu'elle option je dois utiliser avec seulement sudo".
 
Dans tous les cas, rien ne me permet d'affirmer qu'il ne faut jamais jamais utiliser sudo su (-), bref c'est une question de préférence.
 
Et même si c'était une "best practice", cela dépend de chaque individu, c'est peut-être une best practice d'utiliser des tabs pour l'identation du Bash mais j'utilise des spaces pour telle ou telle raison.
 
Alors oui, utiliser sudo -i est plus "propre", ça n'en fait pas une obligation.


Message édité par kaari le 19-07-2020 à 18:50:34

---------------
Mon topic ventes ;)
n°1451759
corias
Posté le 19-07-2020 à 21:33:27  profilanswer
 

Merci pour vos réponses...Je me rends compte que j'suis vraiment nul et suis pas certain d'avoir bien décrit mon pb. :??:  
Ok pour la commande mais ça me met en root dans la session live alors je ne sais pas si ça m'octroie les privilèges pour accéder au fichiers situées sur la partition sur laquelle je ne peux booter...Ou alors oui mais je dois faire toutes les manips dans le terminal ?
En gros je voudrais executer file (l'explorateur de fichier ubuntu) avec des privilèges suffisants pour faire des copiers surtout couper/Colle pour idéalement parvenir à booter à nouveau sur cette partition...
Je sais qu'il ne faut pas réécrire sur un disque sur lequel on tente de récupérer des fichiers mais j'ai eu un peu de mal avec Foremost donc j'ai lancé une recup en fonction de l'extension sans checker ce qui était récupérable...Et j'suis pas super équipé en hdd, docks etc...
 
En gros je veux déplacer 4 répertoires sous
/media/ubuntu/ea9d6add-14bc-47a9-b3e1-0a143fb9a2e7#
vers une clé usb


Message édité par corias le 19-07-2020 à 22:13:08
n°1451764
kaari
Fuck Yeah !
Posté le 20-07-2020 à 00:13:51  profilanswer
 

Tu peux essayer de lancer file avec les droits root:
sudo nautilus


---------------
Mon topic ventes ;)
n°1451794
rat de com​bat
attention rongeur méchant!
Posté le 20-07-2020 à 17:15:39  profilanswer
 

C'est pas une histoire de chown avec le DD si on boote sur un système live? Il me semble que j'avais ce soucis à un moment. :??:

n°1451835
corias
Posté le 21-07-2020 à 20:38:38  profilanswer
 

Merci pour vos msg j'ai réussi à récupérer les données (toutes corrompus) via nautilus avec privilèges sauf que j'ai copier/coller plutot que couper et qu'après suppression des répertoires alors qu'il faisaient plus de 50GO...Aucun espace n'a été libéré! C'est très étrange donc je ne peux plus booter et en mode live avec gparted j'ai tenté de redimensionner la partition swap pour agrandir l'espace de la partition linux je ne peux pas...Elle ne doivent pas être contigus..Je ne sais pas ou sont passé les 50go de données supprimées qui m'auraient permis de booter à nouveau...Très étrange tout ça.  
Y'a-t-il des fichier/répertoires qu'on peut supprimer sans danger ? Peut-on y accéder via windows ?(je suis en dual boot).
Je précise que j'ai déjà executé les commandes de purges de vieux paquets en noyaux sans succès...

mood
Publicité
Posté le 21-07-2020 à 20:38:38  profilanswer
 

n°1451839
rat de com​bat
attention rongeur méchant!
Posté le 21-07-2020 à 23:00:48  profilanswer
 

J'ai du mal à suivre/comprendre ton histoire, mais c'est peut-être moi. Tu n'aurais pas simplement oublié de vider la poubelle (si il y en a une)?
 
Sinon ton file system doit être bien bousillé, à voir si il ne faudrait pas copier toutes les données importantes sur un support externe, formater et repartir sur de bonnes bases.

n°1451848
Fork Bomb
Obsédé textuel
Posté le 22-07-2020 à 09:24:18  profilanswer
 

Un dd if of pourrait aider (en balançant un testdisk sur l’iso/img générée).


---------------
Décentralisons Internet-Bépo-Troll Bingo - "Pour adoucir le mélange, pressez trois quartiers d’orange !"
n°1451849
kaari
Fuck Yeah !
Posté le 22-07-2020 à 09:52:39  profilanswer
 

Toute l'opération était vouée à l'échec dès le début. On ne fait pas de récupération de données sur le même disque au risque d'écraser ces même données lors de la recuperation. Dès le probleme repéré on arrête d'utiliser ce disque et la seule chose qu'on fait avec c'est le monter en read-only. De plus, plus le disque est plein, plus la chance de récupérer des données non corrompue est réduite.
 
Dans tous les cas, tous ces problèmes et tout ce temps passé auraient pu être évités grâce à un backup. Les problèmes "peuvent" arriver donc ils "vont" arriver, et grâce à un backup, la majorité de ces problèmes passent à 5mn de temps de résolution.
 
En ce qui concerne ton problème actuel, tu as probablement fait une erreur, tente de supprimer ces fichiers à nouveaux depuis un disque live.


Message édité par kaari le 22-07-2020 à 09:54:08

---------------
Mon topic ventes ;)
n°1451875
corias
Posté le 22-07-2020 à 13:40:52  profilanswer
 

@Kaari je suis entièrement d'accord avec toi et suis d'ailleurs parano la dessus je fais des backup régulièrement à 2 lieux géographiques mes disques du pc fixe sont en RAID. Helas sur ce PC portable ou j'ai fraichement installé linux je n'avais pas de backup encore moins en temps réel...Je maitrise pas assez linux et foremost...J'ai un dock pourtant et un autre disque mais pas d'autre PC sous linux et dans les live on ne peut rien installer je crois...Enfin tant pis je vais faire le deuil des documents que j'ai produits et pommé.

n°1451886
Trit'
Posté le 22-07-2020 à 18:50:46  profilanswer
 

corias a écrit :

Dans les live on ne peut rien installer je crois...


Si, mais live oblige, ça ne restera installé que durant la session en cours (vu que c’est la RAM qui sert de disque système).
 

corias a écrit :

Enfin tant pis je vais faire le deuil des documents que j'ai produits et pommé.


Paumés. [:aloy]

n°1451912
corias
Posté le 24-07-2020 à 10:08:37  profilanswer
 

Bon je m'acharne un peu mais j'aimerais bien capter pourquoi après suppression de 50 go de fichiers le disque est toujours plein d'ailleurs vu que je les ai supprimé depuis une session live ils n'ont pas pu être déplacé vers la corbeille ?!
Quand je me balade dans l'arborescence du dd je ne vois pas de dossier Trash sous home/user/
 

n°1451924
Fork Bomb
Obsédé textuel
Posté le 24-07-2020 à 18:10:53  profilanswer
 

corias a écrit :

Bon je m'acharne un peu mais j'aimerais bien capter pourquoi après suppression de 50 go de fichiers le disque est toujours plein d'ailleurs vu que je les ai supprimé depuis une session live ils n'ont pas pu être déplacé vers la corbeille ?!
Quand je me balade dans l'arborescence du dd je ne vois pas de dossier Trash sous home/user/
 


/home/<user>/.local/share/Trash/


---------------
Décentralisons Internet-Bépo-Troll Bingo - "Pour adoucir le mélange, pressez trois quartiers d’orange !"
n°1452003
corias
Posté le 27-07-2020 à 10:24:23  profilanswer
 

Yep! Merci j'ai fini âr treouvé

n°1452305
kaari
Fuck Yeah !
Posté le 02-08-2020 à 20:32:34  profilanswer
 

Trit' a écrit :

Parce que c’est une manière très crade de passer root (tu demandes de passer en root – « su - » – en tant que root – via « sudo » –, c’est inutilement redondant) quand il y en a des bien plus propres (« sudo -i » ou « su - » tout court) ; et surtout, que la commande « su » n’a pas besoin d’être exécutée avec « sudo » pour fonctionner (surtout si l’utilisateur n’a pas les droits pour utiliser « sudo », ce qui peut arriver selon les distributions).


Weird, je pensais que les 2 commandes étaient similaires mais apparemment pas partout :o

[kaari@rancher ~]$ sudo su -
Last login: Sun Aug  2 20:30:03 CEST 2020 on pts/0
[root@rancher ~]# echo $PATH
/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
[root@rancher ~]# exit
logout
[kaari@rancher ~]$ sudo -i
[root@rancher ~]# echo $PATH
/usr/local/sbin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin


---------------
Mon topic ventes ;)

Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Linux et OS Alternatifs
  Divers

  Problème de permisision pour accès dossier en lecture via session live

 

Sujets relatifs
[Centos] Dossier partis en sucetteProblème avec Yum install : Error: Unable to find a match
TP en acces à distance en X[GNU/Linux][Debain] Problème de path entre console et xterm
Android sur pc, problème d'affichage[RESOLU]Problème de droits d'écriture pour Apache sous CentOS
Linux Live et monter disques SSD NTFSClé USB Linux Live refuse de booter
[RESOLU] Un problème que je n'arrive pas à régler sur postfix.[DEBIAN] Problème de nginx avec Lemonldap
Plus de sujets relatifs à : Problème de permisision pour accès dossier en lecture via session live


Copyright © 1997-2018 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR