impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

geole · Le 07/08/2023, à 10:36

Bonjour.
Solution standard
Pour créer un utilisateur sur le disque A, les commandes devraient ressembler à.

sudo mkdir -v  /media/$USER/PointDeMontageDiskA/$USER

sudo chown $USER /media/.......

Pour lister les répertoires présents.

ls -ls /media/.....

Pour les répertoires mal stockés.

mv -v /media/$USER/PointDeMontageDiskA/NomRepertoire    /media/$USER/PointDeMontageDisKA/$USER

Solution pratique
Autoriser l'utilisateur a être propriétaire des données du disque qu'il branche.
Je n'arrive pas à comprendre pourquoi le logiciel ne le fait pas automatiquement vu qu'il ne sait pas l'interdire.

sudo chown $USER /media/$USER/PointDeMontageDiskA/*

Dernière modification par geole (Le 07/08/2023, à 10:44)

Coeur Noir · Le 21/02/2024, à 21:43

En clair, on fait un très mauvais choix en utilisant un système de fichier ext4 en support externe et il n'est pas du tout prévu que cela soit simplifié.
et si on n'est pas administrateur, on peut aller se rhabiller

un utilisateur normal n'a pas le droit d'écrire dans une partition formatée en EXT4

re
S'il y a dans cette partition un dossier appartenant à cet utilisateur normal et accordant les droits rwx à cet utilisateur, alors si.
Voire, si la partition est en mode 1777 appartenant à root:root, un utilisateur normal ( non-administrateur donc, sans accès à sudo ) pourra y écrire.

On peut tout à fait avoir un disque externe avec une ou des partitions EXT4, inscriptible pour tout le monde, mais où seul le propriétaire d'un élément a le droit d'effacer cet élément.
Ça s'appelle le sticky-bit. Et c'est facile à mettre en œuvre, une fois pour toutes :

sudo chown -c root:root /chemin/vers/partition   # là on gère un périphérique, du matériel, donc l'appartenance à root est légitime.
sudo chmod -c 1777 /chemin/vers/partition

…et hop, te v'là avec un stockage externe nomade, qui donne à tous le droit d'écrire mais restreint l'effacement au propriétaire de l'élément, qui peut donc se brancher à n'importe quelle machine gérant l'EXT4.

C'est le même fonctionnement que le dossier /tmp dans un système Linux.

Dernière modification par Coeur Noir (Le 21/02/2024, à 23:57)

Coeur Noir · Le 21/02/2024, à 22:02

Vobul a écrit :

@iznobe, tu ne devrais pas promouvoir exfat comme système de fichier passe-partout qui résout tous les problèmes du monde. Ça reste un truc propriétaire de microsoft et ça a été pensé pour les cartes SD et clés USB.
Perso j'ai une fois (au boulot) utilisé un disque exfat, et je me suis retrouvé avec BEAUCOUP d'erreurs dans le système de fichiers (il faut dire que j'avais beaucoup de fichiers sur ce disque de 4 To plein).
C'est bien moins fiable qu'un NTFS ou ext4. Perso je déconseille fortement.

Tu confondrais pas avec le FAT tout court ?
À l'origine tu as raison, c'est un produit de Microsoft mais moins depuis 2019 → https://cloudblogs.microsoft.com/openso … ux-kernel/
car ses spécifications ont été publiées via l'Open Invention Network.
Cela dit tes pépins avec l'ExFAT viennent probablement du fait qu'il n'est pas journalisé par défaut, contrairement à EXT4 ou NTFS…

geole · Le 21/02/2024, à 22:06

Les chiens errants n'ont pas de propriétaire.
Soit au courant que si par hasard quelqu'un écrit 777, il est menacé d'être viré du forun.
C'est un cas vécu qui a donné cette réponse dans la discussion et la mise à niveau de ma signature.

rappel Tu sembles ignorer que tout le monde n'est pas autorisé à faire la commande sudo..
En conclusion. il ne peut pas modifier ses donnés stockées dans son support USB EXT4.
Il n'a que ce qu'il mérite.

Dernière modification par geole (Le 21/02/2024, à 22:13)

geole · Le 21/02/2024, à 22:22

Coeur Noir a écrit :

Vobul a écrit :
@iznobe, tu ne devrais pas promouvoir exfat comme système de fichier
Cela dit tes pépins avec l'ExFAT viennent probablement du fait qu'il n'est pas journalisé par défaut, contrairement à EXT4 ou NTFS…

En fait. la réparation devient totalement inutile puisqu'un fichier en mauvais état n'est pas enregistré.
Lorsqu'on sait qu'une réparation peut durer des heures pour un disque de 16To, il y a lieu de réfléchir avant de formater en système de fichier journalisé.

Dernière modification par geole (Le 21/02/2024, à 22:23)

Coeur Noir · Le 21/02/2024, à 23:51

Monsieur Geole qui veut toujours avoir raison

1⋅ Je n'ai pas écrit 777 mais 1777 et encore, dans ce contexte ciblé, particulier et documenté.
Pas de ma faute à moi si tu ne veux pas t'intéresser à ces questions.

2⋅ Je semble ignorer que … ? Non, non. Sur les machines que je gère aucune utilisateur n'est administrateur SAUF un, moi.
Parce qu'au quotidien, y'a pas besoin d'être dans une session « administrateur » en permanence.
→ La session créée lors de l'installation, on ne s'en sert que pour administrer le système.
Pour le quotidien, on se créé une ( ou des ) autre(s) session(s) avec un compte utilisateur de type normal, qui n'a pas accès à sudo.

3⋅ Pour l'ExFAT, sa non-journalisation par défaut et sa fragmentation, je n'ai pas d'avis ni de conseils à donner, n'ayant jamais eu de problèmes avec jusque là.

4⋅ Revenons-en au sujet de départ : où vois-tu que herveD « n'est pas autorisé à faire la commande sudo » ?
Moi ce que je vois c'est que ses disques amovibles nomades externes semblent chiffrés ( luks ) et c'est ça qui fout la m…
Surtout qu'il y a eu changement de version d'OS entre-temps.
Voilà un bel exemple du pourquoi il ne faut pas chiffrer sans être super confort et à l'aise avec tous les tenants et aboutissants du chiffrement.
Et ta conclusion c'est : « Il n'a que ce qu'il mérite. » Sympa. Super constructif.

Sais-tu donc pourquoi herveD ne parvient plus à utiliser ses disques comme il le faisait auparavant ?

Est-ce qu'on sait au moins si ces périphériques sont vus par le système auquel ils sont branchés ?
Des

lsblk -fe7 -o +size,model,pttype | cat

ou

ls -l /dev/disk/by-uuid/

seraient bienvenus.

Puisqu'il s'agit de périphérique externes amovibles nomades, est-ce que le problème n'a lieu qu'avec ces disques en particulier ou avec tout type de stockage externe amovible ( clé usb, DD externe non chiffré par ex. ) ?
Histoire de valider que le problème est lié au chiffrement OU à l'automatisme de montage des médias amovibles ( udiksctl, acl sur dossier /media/$USER ).

geole · Le 22/02/2024, à 01:50

Coeur Noir a écrit :

Monsieur Geole qui veut toujours avoir raison
1⋅ Je n'ai pas écrit 777 mais 1777 et encore, dans ce contexte ciblé, particulier et documenté.
Pas de ma faute à moi si tu ne veux pas t'intéresser à ces questions.
2⋅ Non, non. Sur les machines que je gère aucune utilisateur n'est administrateur SAUF un, moi.

C'est vraiment trop drole comme remarques. Ce serait moi qui imposerait de ne pas utiliser EXT4?
Un ordinateur personnel doit être aux ordres de la personne qui l'utilise et pas d'un intervennant externe.

Dernière modification par geole (Le 22/02/2024, à 01:55)

Vobul · Le 22/02/2024, à 02:13

Coeur Noir a écrit :

Tu confondrais pas avec le FAT tout court ?

Non, non !

Coeur Noir a écrit :

À l'origine tu as raison, c'est un produit de Microsoft mais moins depuis 2019 → https://cloudblogs.microsoft.com/openso … ux-kernel/
car ses spécifications ont été publiées via l'Open Invention Network.

Ah ça je ne le savais pas, tant mieux, mais ça reste quand même un truc de cartes SD. Pour une clé USB ok, mais pas plus quoi...

Coeur Noir · Le 22/02/2024, à 02:58

geole a écrit :

Ce serait moi qui imposerait de ne pas utiliser EXT4?
Un ordinateur personnel doit être aux ordres de la personne qui l'utilise et pas d'un intervennant externe.

Euh… là je ne suis plus sûr de qui ne comprend pas l'autre

Personne n'impose de ne pas utiliser l'EXT4 ( sinon bah c'est toi qui as écrit qu'il ne fallait pas l'utiliser pour un DD externe, pas moi, moi je te dis comment on peut. )

Même sur un ordinateur personnel, c'est inutile d'être en permanence dans une session de type administrateur.
Il faut au moins une session de type administrateur ( impossible de ne pas en avoir une de toute façon ) mais il n'y a nul besoin que ce soit celle-là qui tourne tout le temps.

Et depuis un compte normal, on peut lancer un terminal et switch user ;
les utilitaires graphiques d'administration permettent de s'identifier avec un autre compte (admin ) que le courant ( normal )… suffit de pas donner le mot de passe admin' à n'importe qui.

Sinon, une idée de pourquoi herveD ne parvient plus à utiliser ses disques comme il le faisait auparavant ?

Dernière modification par Coeur Noir (Le 22/02/2024, à 03:11)

Coeur Noir · Le 22/02/2024, à 03:16

ça reste quand même un truc de cartes SD. Pour une clé USB ok, mais pas plus quoi...

Possible, j'en vois passer de temps en temps au boulot, et je dirais que ça vient d'endroits où cohabitent du Mac et du Win, sans Linux.

geole · Le 22/02/2024, à 11:44

Coeur Noir a écrit :

:
1⋅ Je n'ai pas écrit 777 mais 1777 et encore, dans ce contexte ciblé, particulier et documenté.
Pas de ma faute à moi si tu ne veux pas t'intéresser à ces questions.
.

Bonjour.
Ote-moi d'un doute. Ce bit à la valeur 1 est bien le stycky bit.?
Tu conseillerais donc de polluer les sauvegardes avec des fichiers potentiellement remplis de zéros. Peut-être devenus de taille ridiculement petite ou grande, plutôt que de permettre leur suppression.

il me semble plus facile de s'apercevoir qu'un fichier à disparu que de voir que son contenu laisse à désirer.

Nota: un ordinateur individuel n'est pas obligatoirement utilisé par un seul individu.
Il peut y en avoir un second qui ne connait pas le mot sudo ou qui n'est pas autorisé et qui ne sait pas comment fabriquer et utiliser une live USB et qui récupére un support externe formaté en EXT4 et qui n'a pas son professeur sous la main, est fort démuni.

C'est malheureusement un cas classique si la famille possêde deux ordinateurs dans lesquels l'identifiant de l'utilisateur sous tutelle, n'est pas identique.
Les autres systèmes de fichiers considèrent que la personne physique qui branche le disque a e droit d'y écrire. EXT4 ne le permet pas.

Dernière modification par geole (Le 22/02/2024, à 12:01)

Coeur Noir · Le 23/02/2024, à 03:59

Qu'il est têtu

Ote-moi d'un doute

Relis #27, il y avait déjà un lien vers une doc' sticky-bit.

la personne physique qui branche le disque a e droit d'y écrire. EXT4 ne le permet pas.

Misère. Si, si, bien sûr qu'EXT le permet.
Quand on sait qu'un support EXT aura un usage amovible externe nomade, on le règle en conséquence :
c'est bien l'un des rares cas ou les modes 0777 ou 1777 rendent service.

Sous Linux, les droits/permissions sont des informations portées directement par les éléments eux-mêmes ( fichiers, dossiers ), elles sont inscrites dans leur inode.
Pour les supports avec des syst. de fichiers non-Linux, comme toujours ils seront montés par défaut « à poil » en mode… 777 ( puisqu'eux n'ont pas dans leur inode des infos de droits/permissions que Linux saurait exploiter. )
Dès lors qu'on est face à un syst. de fichiers Linux, ce sont ses permissions incluses à lui qui s'appliquent ( puisque là il y a des infos de droits/permissions exploitables par Linux.)
Si ton support EXT externe amov… est en mode 755, forcément seul le propriétaire peut y écrire, et par défaut c'est root ( souvent, puisque pour partitionner / formater, on passe par root. Il y a une exception dans gnome-disks pour l'EXT justement… mais ça attribue la partition à l'utilisateur courant, ce n'est donc pas pertinent pour un support externe amovible nomade. )

Tu conseillerais donc de polluer les sauvegardes avec des fichiers potentiellement remplis de zéros.

D'où sors-tu cette curieuse idée ?
Le sticky-bit sur un dossier ( le point de montage de la partition = la racine du système de fichiers monté ) ne change rien à la façon d'y effacer les éléments.
Il ne fait que restreindre l'effacement au seul propriétaire d'un élément.
Puisque le support EXT externe amovi… est en mode 0777 ou 1777, des corbeilles se créent dans cette partition dès lors qu'un effacement a lieu depuis celle-ci ( c'est le fonctionnement des corbeilles sous Linux, une par utilisateur ET par partition. ) Comme toujours, avant de démonter puis éjecter un périphérique de stockage externe, il faut d'abord jeter un œil à la corbeille ( celle du bureau, qui est une vue globale de toutes les corbeilles accessibles par l'utilisateur ) et supprimer définitivement ce qui concerne ce périphérique de stockage. Ensuite on procède au démontage / à l'éjection du périphérique.

Bref.
Si herveD maîtrise une session admin' quelque part, il y branche à chaud un de ses disques récalcitrants et consulte les retours de

lsblk -fe7 -o +size,model,pttype | cat

et

ls -l /dev/disk/by-uuid/

Cas normal : le syst. de fichiers de la partition du disque monte dans /media/$USER/label_ou_uuid_périphérique
Il peut alors tenter :

sudo chown -c root:root /media/$USER/label_ou_uuid_périphérique
sudo chmod -c 1777 /media/$USER/label_ou_uuid_périphérique

et vérifier s'il peut dorénavant écrire dans cette partition.
Lui et n'importe qui d'autre, si tout va bien.

Le syst. de fichiers ne monte nulle part automatiquement : vérifier qu'il n'y a pas un couac dans la gestion du montage automatique des supports externes « hotpluggables ».

id
ls -la /media
ls -la /media/$USER
ls -lna /media/$USER

Normalement on doit trouver un + à la droite des permissions du dossier $USER, signifiant la présence d'ACL et ce dossier $USER appartient à… root:root ( et non à l'$USER, c'est les ACL qui autorisent l'$USER ici. )
Si ça n'est pas le cas il faudra s'attarder un peu sur ce point.

Si on est dans le cas normal MAiS qu'il est toujours impossible pour herveD de déchiffrer les données qui l'intéressent, ALORS :
⋅ il ne s'agit pas d'un problème de droits / permissions
⋅ ni d'un couac dans le montage automatique donc
⋅ c'est un souci lié au chiffrement.

Et à ce sujet que je ne maîtrise absolument pas, je m'attends à ce que toi Geole, tu aides ( si herveD re-passe par là ) car tu sembles habitué au chiffrement - enfin en tout cas ça t'arrive d'en parler et de le « promouvoir ».
C'est parce que je te réponds à toi Geole que je parle d'herveD à la troisième personne, avant que tu me le reproches

Je n'invente rien, hein, des supports EXT nomades, il m'en passe des douzaines par mois au boulot, avec diverses configurations et celle-ci ( root:root + mode 1777 sur la racine du syst. de fichiers ) est la moins compliquée à l'usage ( elle se met en place une seule fois ) et limite le risque d'effacer par inadvertance ce qui ne nous appartient pas sur ces supports. On peut toujours le faire sciemment via sudo…

un ordinateur individuel n'est pas obligatoirement utilisé par un seul individu

Oh c'est vrai, tu me prends pour une huître ?
Et alors ? Où as-tu vu que herveD n'avait nulle part accès de plein droit à une session admin' ? Au moins la sienne, sur son ordi je suppose. Il peut donc modifier là les droits et permissions de ses fameux disques.
À moins que la question du chiffrement complique les choses à ce niveau là - au pif puisque ça n'est pas mon sujet de prédilection, une histoire de clé publique ou privée ou de passphrase à mettre au bon endroit ?

Sinon un utilisateur solo sur une machine peut aussi avoir plusieurs sessions dans son ordi' : une pour administrer, une pour le boulot, une pour les loisirs, une pour tester des trucs aventureux, etc.
Il n'y a nul besoin d'avoir en permanence une session admin' en route.
Et si besoin d'administrer depuis un compte « normal » sans sudo, tu peux switch user en console/terminal ou, dans les utilitaires graphiques d'admin', tu t'identifies en tant qu'admin' si tu en connais le mot de passe.
Mot de passe que seul le « vrai » admin' doit connaître, sinon ça n'a plus de sens, évidemment.

geole · Le 23/02/2024, à 11:59

Coeur Noir a écrit :

Bref.
Si herveD maîtrise une session admin

Inutile de continuer cette discussion puisque tu refuses de prendre en compte la seconde alternative dans laquelle initialement et de façon classique, la partition n'est pas fabriquée
en écriture générale pour tout le monde.

Coeur Noir a écrit :

D'où sors-tu cette curieuse idée ?

Alors je redéveloppe en moins de mille mots.

Si le sticky bit n'est pas possitionné
une personne nom propriétaire peut supprimer le fichier.
Il est possible que le propriétaire s'apperçoive que le fichier à disparru.

Si le sticky bit est positionné, cette action n'est pas possible, mais toute personne pourra réduire facilement la taille du fichier à un byte ( je ne donne pas la recette, moko138 l'a suffisamment développée) et je crains que le propriétaire ne s'en apperçoive pas lorsqu'il sauvegardera la partition si tant est qu'il le fasse.

Dernière modification par geole (Le 23/02/2024, à 12:16)

Coeur Noir · Le 23/02/2024, à 13:33

Mais bon sang…

la partition n'est pas fabriquée en écriture générale pour tout le monde.

…on peut justement changer ses droits n'importe quand, à cette partition. Qu'est-ce que tu ne veux pas voir là ?

toute personne pourra réduire facilement la taille du fichier

Ou le modifier d'une façon ou d'une autre : ça n'est pas un problème du sticky-bit,
ce sera un problème avec n'importe quel support qu'on veut rendre ( facilement ) nomade, externe, amovible, multi-utilisateurs et multi-sessions.
Ça n'est pas un argument valable, c'est une conséquence difficilement évitable si on veut un support ouvert à tous.

L'autre solution étant le schéma plus classique :
⋅ on laisse la racine du système à root:root en mode 755 ;
⋅ on place là un dossier par utilisateur en mode 755 appartenant à chaque uid d'utilisateur potentiel.
Ça a ses limites aussi : le jour où un utilisateur a un uid pour lequel il n'y a pas déjà un dossier, il faut qu'un admin' passe par là pour lui en créer un.

Alors je redéveloppe en moins de mille mots.

Je sais lire. Pas toi on dirait.

Dernière modification par Coeur Noir (Le 23/02/2024, à 13:36)

geole · Le 23/02/2024, à 13:41

Mais tu shuntes ce qui ne te plait pas.
dans laquelle initialement et de façon classique
Pour expliquer qu'il suffit de ne pas être standard.
on peut justement changer ses droits n'importe quand.

Je constate que tu as enfin compris que le sticky bit ne sert pratiquement à rien dans la vraie vie.

Dernière modification par geole (Le 23/02/2024, à 13:44)

Coeur Noir · Le 24/02/2024, à 02:05

Tu vas troller indéfiniment, ou bien ? Et j'ai l'impression que tu en oublies des mots…

Je shunte ? C'est l'hôpital qui se fout de la charité : c'est toi qui shuntes les possibilités en affirmant que l'EXT ne peut pas faire ci ou ça.

C'est assez standard de souhaiter qu'un support amovible externe nomade reste accessible en écriture qu'importe où on l'utilise.
Et c'est faisable en EXT. Puisque c'est un syst. de fichiers Linux dont on parle, il faut se soucier de ses permissions : c'est standard. La base.
J'y peux rien moi si tu ne veux pas entendre ça.

Dans la vraie vie, le sticky-bit limite les risques d'effacement par inadvertance - genre un ctrl+A, supprimer. Ça suffit à éviter des boulettes dans un contexte normal, bienveillant.

Dans la vraie vie, celui qui cherche à modifier des fichiers qui ne lui appartiennent pas dans le but de les vider / réduire à zéro pour emmerder l'auteur légitime de ces fichiers,
c'est un connard qui agit sciemment, c'est pas un accident qui arrive par inadvertance. Contre ça il n'y a pas de solution miracle. Nulle part.

Faut-il (te) rappeler qu'un support amovible externe nomade ( quel que soit son « format » et les OS concernés ) doit s'utiliser dans un environnement de confiance ???
En cas de doute on s'abstient de faire circuler un tel support entre des mains inconnues.
Ça aussi c'est standard, le b-a ba des gestes simples souvent oubliés, avant même de parler de résilience, sauvegarde ou chiffrement :
la sécurité n'est jamais qu'un sentiment, basé sur un rapport de confiance entre des gens, des humains.

Bref, plutôt que de chercher des poux dans mes cheveux propres, et aligner des non-arguments, qu'as-tu de concret à conseiller à herveD ?

geole · Le 24/02/2024, à 11:50

Coeur Noir a écrit :

Tu vas troller indéfiniment....
Qu'as-tu de concret à conseiller à herveD ?

La réponse que j'ai donnée en N°26 il y a plus de six mois (Le 07/08/2023 à 9 heures 36) êtait certainement débile puisque le demandeur n'a pas donné suite et que tu as enchaîné expliquant clairement ce que doit faire HervéD.
.

Dernière modification par geole (Le 24/02/2024, à 11:51)

herveD · Le 26/02/2024, à 12:03

Bonjour
Je n'ai pas tout compris, c'est vrai que j'avais un peu laissé tombé, d'autant que je n'ai pas souvent accès à l'autre portable. Je relis tout cela dès que possible. Merci

Coeur Noir · Le 26/02/2024, à 13:53

Le disque externe ne te pose problème que sur un seul ordi' en particulier ?
Alors quelle que soit la modif' que tu apporteras aux droits de ce disque, sois en mesure de le tester ensuite sous diverses machines histoire de s'assurer d'un comportement cohérent.
Si sur une des machines le disque ne monte pas, il y aura lieu d'enquêter davantage.

Coeur Noir, message #37 a écrit :

Si herveD maîtrise une session admin' quelque part, il y branche à chaud un de ses disques récalcitrants et consulte les retours de
lsblk -fe7 -o +size,model,pttype | cat
et
ls -l /dev/disk/by-uuid/
Cas normal : le syst. de fichiers de la partition du disque monte dans /media/$USER/label_ou_uuid_périphérique
Il peut alors tenter :
sudo chown -c root:root /media/$USER/label_ou_uuid_périphérique
sudo chmod -c 1777 /media/$USER/label_ou_uuid_périphérique
et vérifier s'il peut dorénavant écrire dans cette partition.
Lui et n'importe qui d'autre, si tout va bien.
Le syst. de fichiers ne monte nulle part automatiquement : vérifier qu'il n'y a pas un couac dans la gestion du montage automatique des supports externes « hotpluggables ».
id
ls -la /media
ls -la /media/$USER
ls -lna /media/$USER
Normalement on doit trouver un + à la droite des permissions du dossier $USER, signifiant la présence d'ACL et ce dossier $USER appartient à… root:root ( et non à l'$USER, c'est les ACL qui autorisent l'$USER ici. )
Si ça n'est pas le cas il faudra s'attarder un peu sur ce point.

Dernière modification par Coeur Noir (Le 26/02/2024, à 13:59)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 07/08/2023, à 10:36

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#27 Le 21/02/2024, à 21:43

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#28 Le 21/02/2024, à 22:02

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#29 Le 21/02/2024, à 22:06

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#30 Le 21/02/2024, à 22:22

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#31 Le 21/02/2024, à 23:51

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#32 Le 22/02/2024, à 01:50

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#33 Le 22/02/2024, à 02:13

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#34 Le 22/02/2024, à 02:58

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#35 Le 22/02/2024, à 03:16

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#36 Le 22/02/2024, à 11:44

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#37 Le 23/02/2024, à 03:59

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#38 Le 23/02/2024, à 11:59

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#39 Le 23/02/2024, à 13:33

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#40 Le 23/02/2024, à 13:41

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#41 Le 24/02/2024, à 02:05

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#42 Le 24/02/2024, à 11:50

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#43 Le 26/02/2024, à 12:03

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

#44 Le 26/02/2024, à 13:53

Re : impossible d'utiliser un disque données PCI NVME sur un autre ordi :-(

Pied de page des forums