Forum général.général Partager des folders d'un serveur entre utilisateurs locaux/distants sans faille

Posté par voxdemonix le 08 septembre 2018 à 16:44. Licence CC By‑SA.

Étiquettes :

sept.

2018

Admettons que sur une machine type NAS sous debian on dispose d'un dossier Coucou.
Ce dossier Coucou doit être utilisé (RW) par l'utilisateur www-data, l'utilisateur www-data-backup et l'utilisateur www-data-remote utilisé par d'autres machines pour monter le dossier.

Comment partager le plus proprement le dossier ? (chaque users devant pouvoir lire, modifier, créer, supprimer et ce sans passer par un chmod 776 -R)

J'ai déjà testé de mettre les utilisateurs dans les mêmes groupes via usermod -g user1 user2 mais ca marche quand ca veut.

# GRoupes

Posté par ʭ ☯ le 08 septembre 2018 à 18:22. Évalué à 3. Dernière modification le 08 septembre 2018 à 18:22.

Il te faut utiliser les groupes :
1. tu crées un groupe coucou dont tous tes utilisateurs sont membres.
2. tu donnes les droits au groupe.
3. tu changes le mode de création par défaut des fichiers pour ces utilisateurs afin qu'il donne le droit d'écrire au groupe.

⚓ À g'Auch TOUTE! http://afdgauch.online.fr
- [^] # Re: GRoupes
  
  Posté par voxdemonix le 08 septembre 2018 à 19:48. Évalué à 1. Dernière modification le 08 septembre 2018 à 19:51.
  
  Je bloque sur le point 3.
  
  La pour le test j'ai usermod -G user1,user2,user3 userX pour chaque utilisateur et j'ai encore des permission denied en série.
  - [^] # Re: GRoupes
    
    Posté par flavien75 le 08 septembre 2018 à 20:00. Évalué à 1. Dernière modification le 08 septembre 2018 à 20:00.
    
    Est-ce que tu as mis un sticky bit sur le dossier qui contient les fichiers ?
    Si le dossier s'appelle coucou et est censé avoir les permissions 770:
    chmod 2770 coucou/
    
    ça permettra que tous les dossiers et sous dossiers créés dans ce dossier appartiennent au groupe.
    
    Les vrais naviguent en -42
    - [^] # Re: GRoupes
      
      Posté par voxdemonix le 08 septembre 2018 à 21:32. Évalué à 1. Dernière modification le 08 septembre 2018 à 21:34.
      Lorsque www-data-remote crée un dossier, les fichiers se retrouvent avec comme droit
      
      drwxr-sr-x 1 www-data-remote www-data
      
      Se qui provoque un permission denied pour www-data.
    - [^] # Re: GRoupes
      
      Posté par Cyril Brulebois (site web personnel) le 09 septembre 2018 à 04:00. Évalué à 4.
      J'en profite pour détailler un peu comment cela fonctionne :
      
      on connaît les fameux r, w, x pour chaque utilisateur (u), groupe (g) et autre (o) ;
      
      il y a également le bit setuid, qui correspond à u+s ;
      
      mais aussi le bit setgid, qui correspond à g+s ;
      
      et enfin le bit sticky, qui correspond à o+t (ou +t).
      
      Les trois derniers ont comme poids respectifs 4, 2 et 1, d'où le 2 en préfixe des permissions usuelles.
      
      Le bit setgid, c'est ce que j'appelle le mode « collaboratif », et c'est ce qui permet de créer des fichiers/répertoires dans le même groupe que le répertoire parent plutôt que d'avoir le comportement par défaut, qui est de mettre les nouveaux items dans… le groupe principal de l'utilisateur en question.
      
      Vu les besoins décrits, c'est effectivement probablement suffisant (modulo le problème d'umask). Alternativement, il est possible de positionner des ACL au niveau du système de fichiers (si les outils sont installés — paquet acl sous Debian — et si l'option est activée sur le système de fichiers — acl dans /etc/fstab) si on n'a pas la possibilité de régler le problème d'umask. Mais cela sous-entend de savoir reconnaître que des ACL sont positionnées, et comment les consulter/modifier (chacl, getfacl, setfacl). Flexibilité++ mais complexité++… ;)
      
      Debian Consultant @ DEBAMAX
      - [^] # Re: GRoupes
        
        Posté par voxdemonix le 10 septembre 2018 à 13:21. Évalué à 1. Dernière modification le 10 septembre 2018 à 13:24.
        
        Merci pour tes détails :)
        
        Vu les besoins décrits, c'est effectivement probablement suffisant (modulo le problème d'umask). Alternativement, il est possible de positionner des ACL au niveau du système de fichiers (si les outils sont installés — paquet acl sous Debian — et si l'option est activée sur le système de fichiers — acl dans /etc/fstab) si on n'a pas la possibilité de régler le problème d'umask. Mais cela sous-entend de savoir reconnaître que des ACL sont positionnées, et comment les consulter/modifier (chacl, getfacl, setfacl). Flexibilité++ mais complexité++… ;)
        
        Je n'ai pas encore testé cette piste qui me fait un peu peur (de break mes services).
        Y a-t-il un risque à installer les paquets nécéssaire ou bien rien ne se passe tant que je ne vais pas moi-même éditer le /etc/fstab ?
        
        Quand j'aurai enfin réussi a résoudre le soucis de ce thread, j'ouvrirai un tuto sur la création de cluster web histoire que les suivants évitent cette galère :)
  - [^] # Re: GRoupes
    
    Posté par gaaaaaAab le 08 septembre 2018 à 20:03. Évalué à 3.
    tu peux configurer le umask (masque de permission pour la création de fichiers)
```
$ umask
0022
$ touch tst_umask
$ umask 0002
$ touch tst_umask_1
$ ls -l tst_umask*
-rw-r--r-- 1 gab gab 0 Sep  8 20:01 tst_umask
-rw-rw-r-- 1 gab gab 0 Sep  8 20:01 tst_umask_1
```
    - [^] # Re: GRoupes
      
      Posté par voxdemonix le 08 septembre 2018 à 21:54. Évalué à 1. Dernière modification le 08 septembre 2018 à 21:56.
      
      L'équivalent du chmod 770 est donc umask 007, sauf qu'il agira au niveau utilisateur ? (en se basant sur wiki)
      Un peu flippant la commande ^ ^ (si ça foire ça va provoquer une cascade ^ ^ )
      - [^] # Re: GRoupes
        
        Posté par gaaaaaAab le 08 septembre 2018 à 22:44. Évalué à 3.
        
        non, ce n'est pas la même chose. umask définit le masque de permission qui va être appliqué pour tous les nouveaux fichiers. Tant que tu ne crées pas de nouveaux fichiers, l'effet d'umask est nul. D'autre part, quand tu modifies ton umask, ça n'a aucune incidence sur les fichiers déjà créés. Je pense que pour toi, c'est intéressant de combiner les deux. umask pour que les nouveaux fichiers soient créés avec le droit en écriture pour le groupe, et chmod pour que les fichiers déjà existants obtiennent ce droit.
        
        Soit-dit en passant, chmod 770, c'est un peu violent. Tu peux faire plus fin. C'est possible de ne rajouter que le droit en écriture pour le groupe sans toucher aux autres permissions (avec chmod g+w)
        
        $ umask 0022 $ touch fichier1 $ ls -l fichier1 -rw-r--r-- 1 gab gab 0 Sep 8 22:39 fichier1 $ umask 0002 $ touch fichier2 $ ls -l fichier* -rw-r--r-- 1 gab gab 0 Sep 8 22:39 fichier1 -rw-rw-r-- 1 gab gab 0 Sep 8 22:40 fichier2 $ chmod g+w fichier1 $ ls -l fichier* -rw-rw-r-- 1 gab gab 0 Sep 8 22:39 fichier1 -rw-rw-r-- 1 gab gab 0 Sep 8 22:40 fichier2
        
        Note qu'après la modif du umask, les droits de fichier1 n'ont pas été modifié.
        
        La configuration d'umask se fait souvent dans le .profile.
        
        [^] # Re: GRoupes
        
        Posté par voxdemonix le 09 septembre 2018 à 00:15. Évalué à 1. Dernière modification le 09 septembre 2018 à 00:16.
        
        umask est définitif ou sa respawn a chaque reboot? (je pense pas qu'il y aille de .profile pour les utilisateurs sans home)
        
        Je pense tester avec umask u+rwx,g+rwx,o-rwx je retirerai l’exécution si elle n'est pas nécessaire pour les scripts php.
        
        Merci pour les infos :)
        
        [^] # Re: GRoupes
        
        Posté par gaaaaaAab le 09 septembre 2018 à 01:04. Évalué à 3.
        
        Ça se comporte comme les variables d'environnement (même si ça n'en est pas). Si tu modifies le umask dans un processus, tous les processus fils hériteront de cet umask, mais pas les autres processus.
        
        Pour tes utilisateurs qui sont des serveurs web, ça vaut le coup de regarder dans la doc ce qui est préconisé pour la config de l'umask.
        
        [^] # Re: GRoupes
        
        Posté par voxdemonix le 10 septembre 2018 à 12:44. Évalué à 1. Dernière modification le 10 septembre 2018 à 12:48.
        
        Alors j'ai tenté de forcer l'umask pour www-data en éditant /etc/init.d/apache2 et /etc/apache2/envvars afin d'y ajouter umask 0007 (j'ai aussi testé avec 007).
        
        root@machine:/# ls -l /media/ssd/folder/from_www-data.test -rw-r--r-- 1 www-data www-data 0 Sep 10 12:47 /media/ssd/folder/from_www-data.test
        
        A noter que hier pendant un moment j'ai eu des fichiers créé en drwxrws--- mais dont les fichiers créé par www-data dedans se retrouvaient a nouveau avec rw-r--r--.
        
        Pour SSHFS, j'ai ajouté umask 0007 dans le /home/www-data-remote/.profile, /etc/profile et ai édité /etc/ssh/sshd_config
        
        afin de faire remplacer
        
        Subsystem sftp /usr/lib/openssh/sftp-server
        
        par
        
        Subsystem sftp /usr/lib/openssh/sftp-server -u 0007
        
        Résultat:
        
        -rw-r----- 1 www-data-remote www-data 0 Sep 10 12:43 from_sshfs.test
        
        Mais rien n'y fait, après avoir eu très temporairement un comportement qui semblait proche de celui escompté, je n'ai de nouveau plus que des fichiers en rw-r--r--.
        
        [^] # Re: GRoupes
        
        Posté par gaaaaaAab le 10 septembre 2018 à 13:26. Évalué à 3. Dernière modification le 10 septembre 2018 à 13:26.
        
        je viens de faire quelques tests avec sftp, et, en dehors du fait qu'il faut redémarrer le serveur ssh après la modif de la config, j'attire ton attention sur le fait que sftp ne rajoute pas le droit w sur le groupe. Il applique juste le umask. Donc si le droit w n'est pas présent pour le groupe sur le fichier avant le transfert par sftp, il n'y sera toujours pas après.
        
        Plus globalement, vu que tu as trois sources potentielles de nouveaux fichiers dans tes répertoires, ça sera plus simple si tu découpes ton problème en trois questions distinctes, et que tu debug ta config en les prenant une par une.
        
        [^] # Re: GRoupes
        
        Posté par voxdemonix le 10 septembre 2018 à 13:34. Évalué à 1. Dernière modification le 10 septembre 2018 à 13:36.
        
        Plus globalement, vu que tu as trois sources potentielles de nouveaux fichiers dans tes répertoires, ça sera plus simple si tu découpes ton problème en trois questions distinctes, et que tu debug ta config en les prenant une par une.
        
        C'est déjà se que je tente :)
        Actuellement je tente de partager un dossier pour www-data et www-data-remote (dédié a sshfs), le troisième user (www-data-backup) se débrouille pour le moment avec sa rustine (cron qui chmod/chown toutes les deux minutes).
        Précisément voici l'origine du problème : [Retour] Test - Migration Zoneminder Server from X64 to ARM without break
        
        Donc si le droit w n'est pas présent pour le groupe sur le fichier avant le transfert par sftp, il n'y sera toujours pas après.
        
        Tu parles du fichiers local avant d'être envoyé sur le remote storage? Pourtant il me semble avoir lu que l'umask côté client, pour sshfs, n'était qu'une simulation de fuse qui n'avait rien a voir avec la réalité.
        Toujours est-il que j'ai tenté
        
        mount /media/storage -o umask=0007
        
        Mais cela n'avait l'air d'avoir aucun effet.
        
        [^] # Re: GRoupes
        
        Posté par gaaaaaAab le 10 septembre 2018 à 13:44. Évalué à 3.
        
        j'ai peut-être répondu à côté. J'ai vu passer sftp, j'ai répondu sftp :)
        
        Mais sur le fond, c'est la même question. Est-ce que tes fichiers sont bien créés avec le droit w pour le groupe, et sshfs, pour une raison encore à trouver, le zappe au moment du transfert, ou est-ce que sshfs n'y est pour rien ?
        
        (c'est facile à tester. un fichier local avec les bons droits et une copie sur le montage en sshfs)
        
        [^] # Re: GRoupes
        
        Posté par voxdemonix le 10 septembre 2018 à 13:55. Évalué à 1. Dernière modification le 10 septembre 2018 à 13:58.
        
        Ta remarque semble juste d'après ce test :
        
        Sur le client sshfs
        
        root@ClusterOne:/home/# cd /tmp root@ClusterOne:/tmp# touch from_sshfs.test root@ClusterOne:/tmp# ls -l from_sshfs.test -rw-r--r-- 1 root root 0 sep 10 13:46 from_sshfs.test root@ClusterOne:/tmp# chmod 770 from_sshfs.test root@ClusterOne:/tmp# ls -l from_sshfs.test -rwxrwx--- 1 root root 0 sep 10 13:46 from_sshfs.test root@v:/tmp# mv ./from_sshfs.test /media/storage_SSHFS/ mv: failed to preserve ownership for '/media/storage_SSHFS/from_sshfs.test': Permission denied root@ClusterOne:/tmp# touch /media/storage_SSHFS/from_sshfs_without_chmod.test root@ClusterOne:/tmp# ls -l /media/storage_SSHFS/ total 12 -rwxrwx--- 1 1002 www-data 0 sep 10 13:48 from_sshfs.test -rwxrwx--- 1 1002 www-data 0 sep 10 13:50 from_sshfs_without_chmod.test
        
        (on remarquera que fuse signale des droits identiques)
        
        Sur le serveur :
        
        root@machine:/home/# ls -l /media/ssd/folder/ -rwxrwx--- 1 www-data-sshfs www-data 0 Sep 10 13:48 from_sshfs.test -rw-r----- 1 www-data-sshfs www-data 0 Sep 10 13:50 from_sshfs_without_chmod.test
        
        A noter que mon script de montage a déjà -o umask=0007, comment je peux forcer ce droit (c'est root qui s'occupe du montage)?
        
        [^] # Re: GRoupes
        
        Posté par gaaaaaAab le 10 septembre 2018 à 14:20. Évalué à 3.
        
        sur ClusterOne, d'après les droits sur from_sshfs.test créé dans /tmp, le umask de root sur ClusterOne ne donne pas le droit gw. Qu'est ce que ça donne si tu changes le umask de root avant de faire le touch sur la partition sshfs ?
        
        [^] # Re: GRoupes
        
        Posté par voxdemonix le 10 septembre 2018 à 14:29. Évalué à 1. Dernière modification le 10 septembre 2018 à 14:30.
        
        Qu'est ce que ça donne si tu changes le umask de root avant de faire le touch sur la partition sshfs ?
        
        Les permissions semblent bonne.
        
        Sur le client
        
        root@ClusterOne:/tmp# umask 007 root@ClusterOne:/tmp# touch /media/storage_SSHFS/from_sshfs_without_chmod.test root@ClusterOne:/tmp# mkdir /media/storage_SSHFS/test root@ClusterOne:/tmp# touch /media/storage_SSHFS/test/from_sshfs_without_chmod.test
        
        Sur le serveur
        
        root@machine:/# ls -l /media/ssd/folder/ total 0 -rw-rw---- 1 www-data-sshfs www-data 0 Sep 10 14:25 from_sshfs_without_chmod.test drwxrws--- 1 www-data-sshfs www-data 58 Sep 10 14:28 test root@machine:/# ls -l /media/ssd/folder/test total 0 -rw-rw---- 1 www-data-sshfs www-data 0 Sep 10 14:28 from_sshfs_without_chmod.test
        
        J'ai tenté de forcer le umask sur le client en modifiant /etc/profile pour ajouter umask 007 mais même après reboot cela ne change rien.
        
        [^] # Re: GRoupes
        
        Posté par gaaaaaAab le 10 septembre 2018 à 14:37. Évalué à 3.
        
        ok. Si je comprends bien ce que je vois, sshfs transfert correctement les permissions à partir de ClusterOne ver le serveur. Pour les fichiers créés sur la partition sshfs de ClusterOne, les fichiers sont listés avec les droits 770, mais c'est peut-être trompeur.
        
        J'ai l'impression que ton utilisateur local ne crée pas les fichiers avec les bons droits sur ClusterOne.
        
        Si tu as assez d'espace disque sur ClusterOne, tu peux tenter démonter la partition sshfs et vérifier avec quels droits ton utilisateur créé les fichiers.
        
        [^] # Re: GRoupes
        
        Posté par voxdemonix le 10 septembre 2018 à 14:49. Évalué à 1. Dernière modification le 10 septembre 2018 à 14:54.
        
        Ca avance grâce a toi, merci :)
        
        Si tu as assez d'espace disque sur ClusterOne, tu peux tenter démonter la partition sshfs et vérifier avec quels droits ton utilisateur créé les fichiers.
        
        Je dois passer par la ligne de commande, si je démonte la partition ZoneMinder ne retrouve plus ses jeunes.
        
        Sur le client
        
        root@ClusterOne:/tmp# sudo -u www-data touch /media/storage_SSHFS/from_sshfs_by_www-data_user.test root@ClusterOne:/tmp# ls -l /media/storage_SSHFS/ total 12 -rw-r----- 1 1002 www-data 0 sep 10 14:41 from_sshfs_by_www-data_user.test root@ClusterOne:/tmp# sudo -u www-data touch /var/www/html/local_file_from_www-data.test root@ClusterOne:/tmp# ls -l /var/www/html/local_file_from_www-data.test -rw-r----- 1 www-data www-data 0 sep 10 14:43 /var/www/html/local_file_from_www-data.test
        
        Sur le serveur
        
        root@machine:/# ls -l /media/ssd/folder/ total 0 -rw-r----- 1 www-data-sshfs www-data 0 Sep 10 14:41 from_sshfs_by_www-data_user.test
        
        Il semble donc falloir aussi forcer le umask de www-data sur le client (j'ai déjà tenté vainement sur le serveur).
        C'est fort contre-intuitif.
        
        [^] # Re: GRoupes
        
        Posté par gaaaaaAab le 10 septembre 2018 à 14:59. Évalué à 3.
        
        Ca avance grâce a toi, merci :)
        
        cool :)
        
        Elle semble donc falloir aussi forcer le umask de www-data sur le client (j'ai déjà tenté vainement sur le serveur).
        
        oui, mais je n'appellerais pas ça du forçage, c'est modifier les permissions par défaut pour les nouveaux fichiers. Il y a toujours un umask.
        
        C'est fort contre-intuitif.
        
        c'est parce que tu continues de penser à umask comme un équivalent à chmod, alors que ce n'est pas ça. Tu as du voir sur le net que le système applique un XOR entre les permissions du fichier et l'umask. L'application de umask ne peut aboutir, au maximum, qu'à un retrait de permissions, jamais à un ajout. C'est un masque (il peut masquer certaines permissions).
        
        Quand tu changes l'umask en 0002 (resp. 0007), tu dis simplement que tu acceptes les droits rwxrwxr.x (resp. rwxrwx…), pas que tu les imposes. Donc si ton fichier n'a pas le droit gw quand il est créé, aucune configuration de umask ne va jamais le rajouter.
        
        [^] # Re: GRoupes
        
        Posté par voxdemonix le 10 septembre 2018 à 15:26. Évalué à 1. Dernière modification le 10 septembre 2018 à 15:28.
        
        oui, mais je n'appellerais pas ça du forçage, c'est modifier les permissions par défaut pour les nouveaux fichiers. Il y a toujours un umask.
        
        Je suppose donc qu'il est obligatoire de passer par les ACL expliquées brièvement plus haut?
        
        Donc si je résume :
        -umask côté serveur pour "ne pas interdire" des permissions
        -acl côté serveur pour forcer les bonnes permissions
        -acl côté client pour forcer les bonnes permissions
        ?
        
        [^] # Re: GRoupes
        
        Posté par gaaaaaAab le 10 septembre 2018 à 15:41. Évalué à 1.
        
        non ! je disais juste qu'à partir du moment ou umask est de la configuration, le terme "forçage" est discutable :)
        
        Normalement, des umask bien réglés partout, ça devrait fonctionner.
        
        Côté serveur, le bon umask fait que tes droits ne seront pas tronqués lors du transfert par ssh (dans ton montage sshfs).
        Et côté clients, l'umask s'applique lors de la création des fichiers pour éventuellement retirer certaines permissions des permissions par défaut du système pour les fichiers et répertoires.
        
        Là, c'est perturbant parce qu'on utilise umask côté serveur dans un rôle étendu par rapport à son rôle initial. Au départ, umask servait juste à définir les permissions par défaut pour un utilisateur en appliquant un XOR entre les permissions par défaut du système et le umask de l'utilisateur. (Les permissions par défaut du système étant rwxxrwxrwx pour les répertoires, et rw.rw.rw. pour les fichiers)
        
        [^] # Re: GRoupes
        
        Posté par voxdemonix le 10 septembre 2018 à 15:59. Évalué à 1. Dernière modification le 10 septembre 2018 à 15:59.
        
        Vu que tantôt ca avait l'air d'avoir l'effet escompté en lancant umask 007 avant de créer des fichiers : je tente de forcer l'umask de www-data afin de refaire le test.
        Mais actuellement PAS MOYEN.
        J'ai édité /etc/profile, /etc/init.d/apache2 et /etc/apache2/envvars puis reboot, rien n'y fait 😭
        
        [^] # Re: GRoupes
        
        Posté par gaaaaaAab le 10 septembre 2018 à 16:30. Évalué à 3. Dernière modification le 10 septembre 2018 à 16:30.
        
        hmmm … tu parlais là d'un souci potentiel avec fuse. On en est peut-être arrivé là. À tout hasard, est-ce que les gid pour le groupe www-data sont les même sur toutes les machines ?
        
        Par rapport à ton test là, qu'est-ce que ça donne si tu fais:
        
        sudo -u www-data -c "umask 0007; touch /media/storage_SSHFS/from_sshfs_by_www-data_user.test"
        
        [^] # Re: GRoupes
        
        Posté par voxdemonix le 10 septembre 2018 à 17:25. Évalué à 1. Dernière modification le 10 septembre 2018 à 17:30.
        
        Alors il semblerait que je me trompais ici.
        
        Je pense peut-être avoir réussi à régler le www-data sur ClusterOne. J'ai répliqué l'exacte même modifs sur le serveurs. Mais … Permission Denied.
        
        Il ne faut pas tester les droits d'apache2 via ligne de commande mais en appelant une page web. (source)
        J'ai donc créé un script (inspiré d'un recup dans le lien précédent)
        
        <?php $path = "/media/storage_SSHFS/"; mkdir( $path . "test" ); if ($fp = fopen($path . "/test/" . time() . '.txt', 'w')) { fwrite($fp, 'This is a simple test.'); fclose($fp); echo "done"; } else { echo "error - cannot create file"; } ?>
        
        (il crée un dossier test dans $path et un fichier time.txt dedans)
        
        Résultat sur le client :
        
        root@ClusterOne:/# ls -l /media/storage_SSHFS/ total 20 -rwxrwx--- 1 1002 www-data 22 sep 10 17:08 1536592133.txt drwxrwx--- 1 1002 www-data 28 sep 10 17:16 test root@andromede1:/home/voxpopuli# ls -l /media/storage_SSHFS/test/ total 4 -rwxrwx--- 1 1002 www-data 22 sep 10 17:16 1536592563.txt
        
        Résultat sur le serveur :
        
        root@machine:/# ls -l /media/ssd/folder/ total 4 -rw-rw---- 1 www-data-sshfs www-data 22 Sep 10 17:08 1536592133.txt drwxrws--- 1 www-data-sshfs www-data 28 Sep 10 17:16 test root@machine:/# ls -l /media/ssd/folder/test/ total 4 -rw-rw---- 1 www-data-sshfs www-data 22 Sep 10 17:16 1536592563.txt
        
        Ca avait l'air parfait et donc :
        J'ai testé en lançant zoneminder et en changeant une camera de serveur (et donc l'enregistrement est passé de www-data a www-data-sshfs) et les "Can't mkdir events/16/18/09/10/17/04: Permission denied" ré-apparaissent.
        
        Dans les fichiers je peux voir ce genre de choses :
        
        root@serveur:/# ls -l /media/ssd/folder/events/16/18/09/10/ total 0 drwxrws--- 1 www-data www-data 24 Sep 10 14:50 14 drwxrws--- 1 www-data www-data 28 Sep 10 15:50 15 drwxrws--- 1 www-data www-data 36 Sep 10 16:50 16 drwxr-sr-x 1 www-data www-data 8 Sep 10 17:02 17
        
        (j'avais chown www-data:www-data et chmod 2770 tout les folders avant le test, le folder 17 a probablement été créé après le chmod/chown)
        
        [^] # Re: GRoupes
        
        Posté par voxdemonix le 10 septembre 2018 à 17:55. Évalué à 1. Dernière modification le 10 septembre 2018 à 17:57.
        
        Par rapport à ton test là, qu'est-ce que ça donne si tu fais:
        
        sudo -u www-data -c "umask 0007; touch /media/storage_SSHFS/from_sshfs_by_www-data_user.test"
        
        Ta commande renvoie sudo: umask: command not found
        
        [^] # Re: GRoupes
        
        Posté par gaaaaaAab le 10 septembre 2018 à 21:24. Évalué à 1.
        
        je pense que c'est le code de zone minder. En tout cas, j'ai récupéré le code source de la branche master de leur version libre. Dans src/zm_event.cpp, il y a plusieurs :
        
        if ( mkdir(path, 0755) ) {
        
        Donc, à moins que je n'ai pas localisé le bon endroit dans le code source, ce n'est pas un paramétrage de l'utilisateur, c'est le code qui force directement ces permissions.
        
        Plusieurs options possibles :
        - faire une remontée de bug et espérer que le dév en tiennent compte assez vite
        - proposer un patch (mais ça nécessite probablement de discuter avec eux pour voir comment ils veulent le gérer. Perso, je leur suggérerais de laisser le umask à la discrétion de l'utilisateur en utilisant 0777, ou de le mettre en paramètre de l'appli)
        - recompiler une version à toi locale avec un patch
        - utiliser des trucs genre inotify pour aller changer les permissions à la volée (ce qui devraient bien marcher tant qu'il n'y a pas trop de trafic mais qui, dans l'absolu, n'est pas 100% fiable)
        - avoir un seul utilisateur plutôt que trois
        - … si quelqu'un a une bonne idée, c'est le moment ! :)
        
        [^] # Re: GRoupes
        
        Posté par gaaaaaAab le 11 septembre 2018 à 00:53. Évalué à 3.
        
        ou il y a peut-être une solution à base d'ACL, mais je ne m'en suis jamais servi. Je ne sais pas bien ce que ça peut faire. à creuser
        
        [^] # Re: GRoupes
        
        Posté par voxdemonix le 11 septembre 2018 à 02:04. Évalué à 1. Dernière modification le 11 septembre 2018 à 02:07.
        
        Donc, à moins que je n'ai pas localisé le bon endroit dans le code source, ce n'est pas un paramétrage de l'utilisateur, c'est le code qui force directement ces permissions.
        
        Ca ne m'avait même pas traversé l'esprit. Il est plus que probable que le soucis viennent de là.
        Je viens de tenter de changer l'utilisateur de ZoneMinder mais ca amène pas mal de problèmes/bugs. Donc le prochain test de demain sera de monter localement (127.0.0.1) le remote storage via SSHFS. Ainsi ZM continuera d'utiliser www-data et le storage son propre user.
        
        PS : excuse pour les -1 sur deux de tes msg, mais les boutons pertinents/inutile c'est une horreur avec les écrans tactiles ^ ^

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.