Bigdidou
La mise entre guillemets droits
"" d'un intitulé dans une commande est une façon commode de neutraliser les espaces libres, lorsqu'il y en a dans un nom composé de plusieurs termes. Exemple classique : le nom par défaut du volume d'
OS X :
Macintosh HD doit être écrit
"Macintosh HD", sous peine de casser la ligne de commande par l'espace libre central (une autre méthode est d'échapper l'espace qui suit par un anti-slash
\ à la fin du terme immédiatemement précédent, ce qui donnerait :
Macintosh\ HD - comme cette saisie est moins commode, le recours aux
"" peut être préféré).
Par contre, lorsque l'intitulé d'un objet se compose d'un nom unique - comme le nom du volume
SAMSUNG - l'encadrer par des
"" est superflu. L'absence de
"" dans la commande ne peut donc pas être ici la raison de son inefficacité, pour réactiver la permission d'écriture au volume
SAMSUNG.
J'ai pris une clé USB et je lui ai donné des paramètres logiques comparables a priori à ceux du DDE
SAMSUNG : une table de partition
MBR et un format de partition
exFAT pour le volume
CLE. Le résultat d'un
diskutil list me renvoie bien alors un :
Bloc de code:
/dev/disk1 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: FDisk_partition_scheme *4.1 GB disk1
1: Windows_NTFS CLE 4.1 GB disk1s1
=> il faut seulement admettre que l'utilitaire
diskutil a ses petites manies : il ne désigne pas une table
MBR par
MBR (ce serait trop clair), il la désigne par "
FDisk_partition_scheme" : carte de partition de Disque de type FAT ; et il ne désigne pas le format de la partition par
exFAT (ce serait trop clair encore), il le désigne par
Windows_NTFS, ce qui est un facteur de confusion, parce que cette désignation est capable de pointer aussi bien un format
ntfs proprement dit qu'un format
exFAT.
Enfin : passons sur ces conventions de désignation. Donc j'ai bien une clé en
MRB >
exFAT dans les faits. Si je fais un
ls -al sur le volume
CLE, je lis que l'
user (moi) a bien des permissions
rwx (lecture / écriture / exécution) de haut en bas sur les dossiers du volume. Suppose alors que je passe une commande :
Bloc de code:
sudo chmod -R u-x /Volumes/CLE
le
u-x destiné à supprimer la permission d'écriture
w à l'
user (moi), le
-R appliquant cette modification de haut en bas du volume. La commande passe en apparence (pas de message d'échec), mais si je refais un
ls -al sur le volume
CLE, je retrouve exactement les mêmes permissions
rwx pour l'
user (moi) de haut en bas => la commande
chmod n'a donc eu aucun effet sur une partition formatée en
exFAT. Suppose par contre que la partition ait un format Apple
jhfs+ (Mac OS étendu journalisé) : alors là, pas de lézard --> la permission d'écriture
w est enlevée à l'
user de haut en bas. Inversement, si l'
user manquait de cette permission d'écriture, elle lui est ajoutée de haut en bas par une option
u+w.
J'en conclus qu'en cas de format de système de fichiers
exFAT d'une partition, la commande
chmod n'a aucun effet. Ce n'est pas la seule : si je passais une commande de type :
Bloc de code:
sudo chown -R toto /Volumes/CLE
afin de changer l'
user à
toto (un
admin auxiliaire réel dans mon OS), la commande a l'air de passer sans erreur, mais un
ls -al sur le volume montre qu'il ne s'est rien passé en fait.
Si je fais d'ailleurs un
⌘I sur le volume
CLE pour afficher une fenêtre d'info du
Finder, je n'ai pas du tout l'affichage régulier à la rubrique
Partage et permissions > Lecture et écriture autorisées > user = Lecture et écriture > staff = Lecture seulement > everyone = Lecture seulement ; j'ai seulement les 2 premiers affichages :
Partage et permissions > Lecture et écriture autorisées sans aucun tableau
user > staff > everyone. Je n'ai donc un cadenas permettant de faire varier les permissions pour un des 3 accédants que dans le premier cas (où ils sont affichés), mais pas dans le second cas (où ils ne sont pas affichés).
Je conclus de ces petites expériences, qu'en cas de format
exFAT du système de fichiers d'une partition, les droits sont figés en l'état, et ne sont manipulables ni en ligne de commande (
chown ou
chmod), ni en mode graphique (fenêtre d'info du
Finder).
--------------------
Ce qui me conduit aux réflexions suivantes (je n'ai pas une seconde, malgré les apparences verbales, perdu de vue le problème de
DDC) =>
Je ne comprends pas du tout comment
DDC a pu changer une quelconque permission de l'
user (=
DDC) sur le volume
SAMSUNG dans une fenêtre d'info du
Finder, puisque, un format
exFAT (présumé) caractérisant le système de fichiers de cette partition, les accédants ne sont pas affichés, non plus que leurs permissions, et aucun cadenas ne permet donc une manipulation.
Même si je ne conçois pas comment une telle manipulation graphique a pu s'effectuer, le résultat d'un
ls -al sur le volume
SAMSUNG révèle que, de haut en bas du volume, l'
user (
DDC) a des permissions
rwx (lecture / écriture / exécution). Il s'ensuit qu'il n'y a aucun besoin de s'acharner à vouloir passer un
chmod -R u+x sur le volume, puisque l'
user (
DDC) a déjà la permission
w d'écriture.
Que la présence de ce "
writable_bit" de haut en bas ne lui permette pas, néanmoins, d'écrire à l'espace du volume, me semble alors conduire à la conclusion suivante : l'impossibilité d'écrire à l'espace du volume
SAMSUNG ne découle pas d'un problème de permissions intrinsèquement attachées aux accédants au volume, l'
user en premier lieu (puisqu'il a intrinsèquement la permission d'écrire
w). Il faut chercher une autre raison, capable de « surpasser » ("
override") les permissions fixées localement sur le répertoire d'un volume.
Je suis conduit alors à une nouvelle conjecture qui est la suivante. Un facteur capable d'«
overriding » (surpassement) des permissions intrinsèques d'un volume (et de ses contenus) est le
mode de montage du système de fichiers gestionnaire de la partition. En effet, le système de fichiers d'une partition, s'il monte régulièrement en mode
read_write (lecture & écriture), peut monter avec une restriction d'écriture selon le mode
read_only (lecture seule).
Dans pareille circonstance, le mode de montage
read_only du système de fichiers surpasse (
override) complètement les permissions intrinsèques d'
user et de
groupes fixées sur les répertoires (car ces répertoires sont des objets dépendants du système de fichiers, et donc du mode de son montage). J'ai fait l'expérience de monter le système de fichiers
exFAT de ma clé en mode
read_only : alors même qu'une commande
ls -al sur le volume
CLE continue de me retourner des permissions
rwx pour l'
user (moi), le système de fichiers monté en mode
read_only empêche totalement le moindre acte d'écriture au volume (ajout de fichier > suppression de fichier > modification de fichier > et même renommage du volume). Le volume est littéralement verrouillé en lecture seule. Si je fais un
⌘I sur le volume
CLE, je lis un :
Partage et permissions > Lecture seulement (avec toujours absence de tableau d'accédants et cadenas).
Rien n'y fait : aucun commande
chown ou
chmod ne peut changer quoi que ce soit, même en droit
root, mais retourne un :
Read-only file system.
Je te propose alors,
DDC, une nouvelle expérimentation dans l'optique de cette conjecture, consistant à
démonter d'abord le volume
SAMSUNG pour tenter de
remonter ensuite son système de fichiers en mode
read_write pour voir si c'est possible.
Pour
démonter le volume
SAMSUNG, ne le fais pas dans le
Finder (sélection et
⌘E), car tu éjecterais le disque dans la foulée, ce qui le rendrait inadressable. Ton
SAMSUNG monté sur ton Bureau de session, vérifie d'abord par un
diskutil list dans le «
Terminal» que ce volume est bien toujours identifié comme
disk2s1 (sinon tu changerais le numéro du disque avant le secteur de la partition :
disk3s1,
disk4s1 etc. si tu avais d'autres périphériques attachés en intercalaire). Ensuite, passe la commande de démontage :
Bloc de code:
sudo diskutil umount force /dev/disk2s1
=> si tu touches un :
Bloc de code:
Volume SAMSUNG on disk2s1 force-unmounted
c'est bon (sinon, démonte ce volume dans l'«
Utilitaire de Disque»).
Tente à présent de faire passer une commande de
remontage du système de fichier
exFAT (présumé) en mode
read_write :
Bloc de code:
sudo mount -t exFAT -w /dev/disk2s1 /tmp
par laquelle tu tentes de remonter le système de fichiers de la partition
disk2s1 en format
exFAT (
-t exFAT) et en mode
read_write (
-w) dans le répertoire d'éléments temporaires
/tmp pris comme point de montage.
Est-ce que la commande passe (pas de message d'erreur, l'icône du volume
SAMSUNG réapparaît sur le Bureau de session) ou est-ce qu'elle plante ? - Si elle passe, est-ce que tu peux écrire au volume ?
[Je sens que je vais boire la tasse dans ce fil - beaucoup plus profond que celui du ru de prairie qu'il semblait d'abord...
]
--------------------
D'ailleurs (tu le verras sur la capture par la suite), j'ai l'impression que le "format" annoncé dans la page d'information Finder du DDE a changé depuis la dernière opération ... A ton avis ça peut être ça ? Et si oui, excuse moi du coup d'avoir biaisé ton information (c'était involontaire, tu l'imagines bien). 
