10.11 El Capitan Partage de Fichier en Ecriture

Et pourtant elle tourne :D.
Pour info si je regarde dans options du partage de la machine A et que je connecte la machine B sur l'ordinateur A avec son mot de passe, j'ai :
Partager via SMB 1
et
Partager via AFP 0

Tu remarqueras aussi que si sur le répertoire Test j'ai une entrée acl :
drwxr-x---+ 6 jean staff 204 24 mar 16:31 .
0: user:toto allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity

alors que sur le fichier partagé Test.pages rien de tout ça :
-rw-r--r--@ 1 jean staff 67430 24 mar 16:31 Test.pages
com.apple.FinderInfo 32
com.apple.iwork.documentUUID#PS 16
com.apple.iwork.documentUUID.synced 16
com.apple.quarantine 20
 
Dans ton cas de figure, je ne vois pas comment le fichier Test.pages qui est en -rw-r--r-- jean staff sans ACE dans l'ACL du fichier pourrait jamais être scriptible par toto - lequel n'en est pas l'user POSIX en rw, ni ne bénéficie d'une ACE "toto allow write". Que jean écrive au fichier, pas de problème en l'état ; mais comment fait donc le toto de l'autre Mac qui accède en partage à ce fichier pour faire autre chose que le lire (grâce à son appartenance au groupe staff qui est en r-- sur le fichier) ? [l'ACE sur le dossier Test concerne l'accès à l'espace du dossier, pas l'accès au contenu du fichier Test.pages]

Elle tourne peut-être rond, ta boule, mais je ne conçois ni n'aperçois cette rotation... Ce n'est pas que je tienne de préférence à mon cas, qui signale un échec d'écriture bilatérale, plutôt qu'au tien, qui témoigne d'un succès - ce qui m'intéresse, c'est de saisir ce qui se passe et, pour l'instant, ce que je comprends, c'est que ça ne peut que mal tourner...
361608_original.png

--------------------​

Édit. Une chose qui me vient à l'esprit est la suivante. Il existe concernant les volumes montés externes au volume de l'OS démarré deux options récursives quant au propriétaire de ce volume : soit "absolue" (correspondant à diskutil enableOwnership), qui préserve récursivement l'user statutaire du volume et de ses contenus ; soit "relative" (correspondant à diskutil disableOwnership), qui transforme l'utilisateur dont la session est ouverte en user momentané du volume et de ses contenus.

Serait-il possible qu'un dossier partagé résidant sur un Mac A puisse être traité comme l'équivalent d'un "pseudo-volume" local monté pour le Mac B, de sorte que l'utilisateur du Mac B pourrait bénéficier d'un "disableOwnership" = droit de propriété relatif sur ce dossier et ses contenus ? Ainsi, l'user absolu (jean) serait maintenu en place sur les fichiers, mais c'est l'user relatif toto qui en aurait la propriété momentanée dès lors qu'ils relèveraient d'un "pseudo-volume" monté avec l'option "disableOwnership" ? Alors toto pourrait écrire et sauvegarder aux contenus de ce "pseudo-volume" monté en partage, tandis que, lorsque jean reprendrait la main, le dossier n'aurait plus statut de "pseudo-volume" monté, mais de dossier standard de son OS sur lequel il conserve son statut d'user absolu en mode récursif...
 
Dernière édition par un modérateur:
Dans ton cas de figure, je ne vois pas comment le fichier Test.pages qui est en -rw-r--r-- jean staff sans ACE dans l'ACL du fichier pourrait jamais être scriptible par toto - lequel n'en est pas l'user POSIX en rw, ni ne bénéficie d'une ACE "toto allow write". Que jean écrive au fichier, pas de problème en l'état ; mais comment fait donc le toto de l'autre Mac qui accède en partage à ce fichier pour faire autre chose que le lire (grâce à son appartenance au groupe staff qui est en r-- sur le fichier) ? [l'ACE sur le dossier Test concerne l'accès à l'espace du dossier, pas l'accès au contenu du fichier Test.pages]

Elle tourne peut-être rond, ta boule, mais je ne conçois ni n'aperçois cette rotation... Ce n'est pas que je tienne de préférence à mon cas, qui signale un échec d'écriture bilatérale, plutôt qu'au tien, qui témoigne d'un succès - ce qui m'intéresse, c'est de saisir ce qui se passe et, pour l'instant, ce que je comprends, c'est que ça ne peut que mal tourner...
361608_original.png

--------------------​

Édit. Une chose qui me vient à l'esprit est la suivante. Il existe concernant les volumes montés externes au volume de l'OS démarré deux options récursives quant au propriétaire de ce volume : soit "absolue" (correspondant à diskutil enableOwnership), qui préserve récursivement l'user statutaire du volume et de ses contenus ; soit "relative" (correspondant à diskutil disableOwnership), qui transforme l'utilisateur dont la session est ouverte en user momentané du volume et de ses contenus.

Serait-il possible qu'un dossier partagé résidant sur un Mac A puisse être traité comme l'équivalent d'un "pseudo-volume" local monté pour le Mac B, de sorte que l'utilisateur du Mac B pourrait bénéficier d'un "disableOwnership" = droit de propriété relatif sur ce dossier et ses contenus ? Ainsi, l'user absolu (jean) serait maintenu en place sur les fichiers, mais c'est l'user relatif toto qui en aurait la propriété momentanée dès lors qu'ils relèveraient d'un "pseudo-volume" monté avec l'option "disableOwnership" ? Alors toto pourrait écrire et sauvegarder aux contenus de ce "pseudo-volume" monté en partage, tandis que, lorsque jean reprendrait la main, le dossier n'aurait plus statut de "pseudo-volume" monté, mais de dossier standard de son OS sur lequel il conserve son statut d'user absolu en mode récursif...

En fait je n'avais pas trop regardé ce qu'il se passait coté ordinateur B (celui qui se connecte à la ressource Test de l'ordinateur A avec le User Toto)
Voici les résultats de :

Toto:~ Toto$ mount | grep Test
//Toto@Imac%20de%20jean._smb._tcp.local/Test on /Volumes/Test (smbfs, nodev, nosuid, mounted by Toto)

Toto:~ Toto$ ls -la@e /Volumes/Test
total 224
drwx------ 1 Toto staff 16384 25 mar 15:26 .
drwxrwxrwt@ 8 root admin 272 26 mar 06:30 ..
com.apple.FinderInfo 32
com.apple.progress.fractionCompleted 9
0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit
-rw-r--r--@ 1 Toto staff 6148 25 mar 14:48 .DS_Store
com.apple.FinderInfo 32
drwxrwxrwx@ 1 Toto staff 16384 25 mar 14:48 .TemporaryItems
com.apple.FinderInfo 32
com.apple.quarantine 20
-rw-r----- 1 Toto staff 0 25 mar 14:46 .com.apple.timemachine.supported
-rw-r-----@ 1 Toto staff 70124 25 mar 15:26 Test.pages
com.apple.FinderInfo 32
com.apple.iwork.documentUUID#PS 16
com.apple.iwork.documentUUID.synced 16
com.apple.quarantine 20

Et pour ajouter une info, si j'ouvre les documents sur les 2 machines en même temps, le partage est bien géré et au moment de sauvegarder les modifs sur B, si A à modifié le document, une fenêtre l'indique en proposant :
Test_partage.webp
 
:coucou: Jean

J'obtiens les mêmes informations que toi avec les mêmes commandes. Donc je ne vois rien là-dedans qui fasse ressortir une différence capable de rendre compte du « paradoxe de Jean » (E pur si muove !)...
361608_original.png


Si je reprends l'état des lieux de mon côté : un fichier partagé Test du Mac de maco, qui a au départ pour user maco , avec toto du Mac de toto bénéficiant d'une ACE "toto allow write" (panneau de Partage > sélection du dossier partage BROL > clic_secondaire > "Appliquer les autorisations aux éléments inclus" > création d'une ACE 0: user:toto allow read,write,append,readattr,writeattr,readextattr,writeextattr,readsecurity dans l'ACL du fichier) ; une fois édité et sauvegardé en écriture par toto, ce fichier se retrouve avec toto pour user (lequel n'a plus d'ACE du coup) => conséquence : quand maco, l'ex-user, tente d'écrire au fichier qu'il a créé et qui est stocké sur le Mac de maco, un panneau d'interdiction s'affiche, lui disant qu'il n'a pas les autorisations pour écrire au fichier, mais qu'il peut seulement écrire à un duplicata du fichier.

Le point critique dans mes expérimentations est donc le suivant : toto a accès en écriture au fichier partagé Test dont l'user est maco grâce à l'ACE "toto allow write" de l'ACL du fichier. Il peut donc user de cette permission d'écriture d'ACE, mais, dès qu'il sauvegarde le fichier Test qu'il vient d'éditer, tout se passe comme si cet acte le substituait à maco comme user POSIX du fichier, tout en supprimant l'ACE associée "toto allow write". C'est donc comme si sauvegarder le fichier, c'était écrire l'ACE au fichier comme permission POSIX, au lieu de se contenter d'en user en tant qu'ACE.

En effet, si toto sauvegardait le fichier simplement de par sa permission d'ACE " toto allow write ", alors l'user POSIX du fichier (= maco) ne serait pas affecté, puisqu'il s'agit d'un autre registre de droits. Et là, tout « tournerait » comme il faut en terme de permission d'écriture bilatérale. maco écrirait continûment en tant qu'user maco POSIX en rw sur le fichier, et toto écrirait continûment au même fichier en tant que bénéficiaire d'ACL en w ne supplantant jamais l'user POSIX maco. Mais ce n'est pas ce qui se passe chez moi (non plus que chez Wolf) : quand toto sauvegarde, il convertit en fait sa prérogative d'ACL en privilège d'usership POSIX sur le fichier. C'est ça qui fiche le bazar... Que Jean soit indemne de cette facétie ACE rw => usership POSIX rw, c'est ce que j'aimerais bien comprendre, mais que je ne parviens pas à saisir.

J'ai vérifié sur un dossier partagé entre utilisateurs d'un même OS sur son MBP 17 (maco et toto encore) qu'il en va de même : dès que toto sauvegarde, il convertit son ACE rw => usership POSIX rw et devient l'user du fichier. Donc ça me semble un comportement surprenant, mais itératif. Une variable cachée = x qui opérerait chez Jean ? - Je ne vois que cette possibilité, mais de quoi s'agit-il ? Telle est la question....

--------------------
J'ai trouvé une nouvelle solution de contournement chemin faisant, mais qui ne fait guère avancer la copmpréhension du paradoxe par ailleurs. Je suis parti de mon idée tardive d'hier : à savoir, la possibilité d'« ignorer les autorisations sur un volume » montant à partir d'un disque externe, comme une clé USB. La conséquence de pareille option est que l'utilisateur donc la session est ouverte au moment du montage en volume du disque externe se trouve intronisé (récursivement sur l'arborescence de fichiers du volume) user par provision : il a donc automatiquement permissions de lecture / écriture aux fichiers contenus sans obstacle de droits POSIX fixés à demeure sur les fichiers (qui sont momentanément suspendus).

maco a donc attaché une clé USB au MBP 17 de maco, ce qui donne lieu à un volume monté CLE. Dans ce volume, maco a créé un dossier partagé BROL-CLE contenant un double du fichier Test. maco s'est assuré que l'ownership est bien désactivée sur le volume en question. Cela fait, dans le panneau Partage, il a intronisé toto comme associé au partage du dossier BROL-CLE et appliqué aux éléments inclus. On obtient sur le fichier Test un état de droits équivalent à celui du dossier partagé BROL précédemment utilisé => -rw-r--r-- maco staff + ACE "toto allow write" écrite par l'acte de propagation précédent.

toto se connecte au dossier BROL-CLE comme il le faisait avant à BROL : il écrit au fichier Test de part son ACE "toto allow write" et une fois qu'il a sauvegardé, les droits du fichier, vus de son côté, sont devenus : -rw-r--r-- toto staff. Plus d'ACE. Bref : exactement la même conversion ACE rw => usership POSIX rw qui fichait le bazar précédemment.

Revenons à maco : maco de son côté va à l'espace du volume monté CLE de sa clé USB, entre dans le dossier partagé BROL-CLE et ouvre le fichier Test. Il esquisse un acte d'écriture et... ça marche sans problème. Il sauvegarde : pas davantage de problème. maco a donc écrit à un fichier Test dont l'user POSIX est toto (sans avoir non plus d'ACE qui le lui permette). Et si toto de son côté réouvre le fichier Test partagé, les droits demeurent -rw-r--r-- toto staff dessus, donc il peut continuer à écrire peinard sans plus d'ACE.

Comment se fait-il donc que maco puisse écrire au fichier -rw-r--r-- toto staff at: /Volumes/CLE/BROL-CLE/Test dont il n'est pas l'user, et sur lequel il n'a pas d'ACE de type "maco allow write" ? - la réponse est dans l'activation de l'option : "disableOwnership" sur le volume monté CLE. En effet, de par cette fonctionnalité active au montage du volume CLE, l'usership récursif du volume CLE est détenu par l'utilisateur donc la session est actuellement ouverte. Il s'ensuit, pour le fichier Test qui nous importe ici, que : si l'ownership fixée sur le fichier est bien toujours -rw-r--r-- toto staff dans l'absolu ; la désactivation de cette ownership sur le volume monté établit momentanément les autorisations d'usage à : -rw-r--r-- maco staff => il y a là un surclassement (overriding) à la volée, qui fait que maco aura toujours un droit d'user par provision sur les contenus du volume CLE ; tandis que toto, qui n'a pas accès au volume monté CLE, mais au dossier partagé BROL-CLE, lui, après sa première édition sauvegardée du fichier Test, conserve son statut d'user POSIX rw- sur le fichier Test => il pourra donc de son côté continuer d'écrire tant qu'il voudra.

On a donc affaire à un curieux « renversement de statut de propriété » ici : l'user POSIX maco, créateur du fichier partagé Test, se trouve dépossédé de cet ownership, pour passer à un statut d'user par provision grâce à la désactivation des autorisations sur le volume ; tandis que le bénéficiaire d'ACE toto, à partir de sa première sauvegarde d'écriture à Test, se retrouve intronisé user POSIX statutaire du fichier comme s'il l'avait créé.

=> il suffirait donc que Wolf déplace son dossier partagé sur une clé USB en répétant dessus la procédure de Partage avec son collègue et j'ai tout lieu de penser que ça se passerait comme je viens de le décrire, s'il s'assure, en faisant un I sur le volume monté de sa clé, que la case tout en bas du panneau : "Ignorer les autorisations de ce volume" est bien cochée.

--------------------​

Peut-on tirer des enseignements de cette méthode de contournement au cas d'un dossier partagé résidant dans le volume de l'OS ? - Ça ne me semble pas le cas pour la raison suivante :

- dans le cas de ma clé, le volume CLE est monté pour maco, et c'est seulement le dossier inclus BROL-CLE qui se trouve monté pour toto comme un "pseudo-volume" ;

- dans le cas du dossier /Shared/BROL, pour maco, ce n'est qu'un dossier de son OS et c'est seulement pour toto qu'il a le statut de "pseudo-volume" monté (à l'instar du BROL-CLE).​

Conséquence : toto va chaque fois, à sa première édition sauvegardée au fichier Test de chacun des dossiers partagés (BROL-CLE et BROL) s'instaurer en user du fichier. Pour ce qui est de maco, lorsque le fichier relève du dossier BROL-CLE du volume monté pour lui CLE de la clé, l'ownership étant désactivée sur ce volume, il a la « propriété d'usage provisoire » du fichier, et peut donc y écrire ; mais lorsque le fichier relève du dossier partagé BROL de son Mac (at: /Shared/BROL), comme il ne s'agit pas d'un volume monté pour lui, l'ownership n'est pas désactivée, et c'est donc toto qui reste instauré en user POSIX sur le fichier => conséquence : maco ne peut pas écrire.
 
Dernière édition par un modérateur:
Bonjour,

je m'immisce avec une question. Est-il envisageable de créer ex nihilo un groupe qui partagerait des droits analogues à ceux de staff sur un dossier commun ?
Ce groupe n'inclurait que les deux comparses concernés.
 
Bonjour,

je m'immisce avec une question. Est-il envisageable de créer ex nihilo un groupe qui partagerait des droits analogues à ceux de staff sur un dossier commun ?
Ce groupe n'inclurait que les deux comparses concernés.
Oui mais là on retombe dans les bricolages.
Je précise que je n'ai personnellement utilisé que les outils de base et que ça fonctionne parfaitement.
 
=> il suffirait donc que Wolf déplace son dossier partagé sur une clé USB en répétant dessus la procédure de Partage avec son collègue et j'ai tout lieu de penser que ça se passerait comme je viens de le décrire, s'il s'assure, en faisant un I sur le volume monté de sa clé, que la case tout en bas du panneau : "Ignorer les autorisations de ce volume" est bien cochée.

Bonjour à tous, j'espère que vous avez passé un bon w-e (de Pâques)
Merci pour toutes vos réponses. Je pensais que ça serait plus simple et que j'avais juste omis un paramètre ...

Mettre ça sur clé USB correspond à ce que je fais actuellement ou presque ... puisque je lui transmet le document en iMessage pour qu'il puisse par la suite travailler depuis son MBP.
Je voulais faire plus pratique, mais ça à l'air au final plus compliqué :p

Merci de vos aides en tout cas.
 
:coucou: Wolf

Malgré mes expérimentations et mes spéculations, je n'ai pas réussi à éclaircir le mystère (pourquoi ça coince chez toi et moi - pas chez Jean).

Sinon, il suffit que tu vires le groupe staff en lecture & écriture (par ⌘I sur ton document) pour débloquer le fichier en écriture pour vous deux (ce qui est hyper simple comme manipulation).
 
Bonjour, je souhaite partager un fichier en écriture entre mon iMac et un Macbook Pro.

C'est un fichier que j'utilise quotidiennement et je souhaite que le MBP prenne la main dessus le à J+1 pour saisir la facturation.
Par la suite je reprend la main dessus pour mon écriture quotidienne.

J'ai donc depuis mon iMac autorisé l'accès au MBP à mon dossier partagé via
"Préférence Système / Partage / Partage de Fichiers"
La, je renseigne le dossier à partager et j'ajoute le compte Utilisateur qui peut intervenir sur ce fichier en lui donnant la permission "Lecture / Ecriture".

Ensuite sur mon fichier Cmd+i et la Partage et Permission et je vérifie que l'utilisateur y soit avec la permission d'écrire sur mon fichier.
Jusque la, tout fonctionne.

L'utilisateur, prend sur son MBP le relais, fais ses écritures et sauvegarde le fichier modifié.
Par contre, lorsque je reprends le relais je peux consulter, mais ne peut plus écrire sur ce même fichier sans faire au préalable une duplication.

Ma question est donc : comment faire pour avoir un fichier qui puisse être consulté et modifié à souhait par les 2 comptes utilisateurs ?

Merci de votre aide.

Une raison particulière pour ne pas te tourner vers Dropbox, Box, iCloud Drive, etc, voire un NAS local ?
 
:coucou: Wolf

Malgré mes expérimentations et mes spéculations, je n'ai pas réussi à éclaircir le mystère (pourquoi ça coince chez toi et moi - pas chez Jean).

Sinon, il suffit que tu vires le groupe staff en lecture & écriture (par ⌘I sur ton document) pour débloquer le fichier en écriture pour vous deux (ce qui est hyper simple comme manipulation).
Ta manip fonctionne, mais encore une fois lorsque le second utilisateur écrit derrière moi puis sauvegarde, mes autorisations d'écriture disparaissent lorsque je réouvre ce document.

Une raison particulière pour ne pas te tourner vers Dropbox, Box, iCloud Drive, etc, voire un NAS local ?
Simplement par question de confort.
C'était plus simple pour moi, nous de travailler sur un même fichier.
 
Ta manip fonctionne, mais encore une fois lorsque le second utilisateur écrit derrière moi puis sauvegarde, mes autorisations d'écriture disparaissent lorsque je réouvre ce document.


Simplement par question de confort.
C'était plus simple pour moi, nous de travailler sur un même fichier.

Important le confort effectivement. Crée un compte générique Dropbox ou Box qui sera utilisé/partagé par les utilisateurs. D'expérience, je n'ai pas trouvé plus simple et plus souple.
 
Salut Wolf

lorsque le second utilisateur écrit derrière moi puis sauvegarde, mes autorisations d'écriture disparaissent lorsque je réouvre ce document

Si au départ tu as donné à staff des permissions rw (lecture & écriture) => quand toto (ton collègue) sauvegarde son écriture au fichier, ça ne change rien aux permissions du groupe staff qui restent rw- (lecture & écriture) => quand tu reprends la main sur le fichier, tu peux donc logiquement y écrire (et sauvegarder), en tant que membre de staff qui a la permission d'écriture. Je ne vois pas du tout pourquoi le fichier te reviendrait avec les permissions de staff virées à lecture seule...

Chez moi, il n'y a pas de problème : je peux écrire derrière la sauvegarde de l'utilisateur d'un autre Mac qui partage le fichier, justement parce que je suis membre d'un staff en lecture & écriture - permissions qui n'ont pas varié d'un iota et qui me permettent d'écrire au fichier, quand bien même l'autre (toto) est-il devenu l'user du fichier...