préserver les autorisations de fichier pour les partages samba lorsque le fichier est modifié

Les bases de code, je travaille avec des extraits de dépôts Git sur ma machine Linux. Depuis notre production de code est écrit pour être déployé sur Linux, j'ai fais tous les tests sur ma machine Linux, mais comme l'utilisation de Windows pour l'utilisation de tous les jours, y compris le code de montage et de création.

Pour cela, j'ai créé un partage Samba du dossier (mon dossier d'accueil) où j'ai la caisse le code, comme ceci:

[wgrover]
    path = /home/wgrover
    available = yes
    valid users = wgrover
    read only = no
    browsable = yes
    public = yes
    writable = yes

Cependant, quand j'ai modifier un fichier depuis le partage samba \\linux-box\wgrover dans Windows, la permission de fichier sous Linux ne cesse de changer de 755 même si elle a été 644 avant de modifier.

Cela continue de s'afficher dans mon git diff comme ceci:

diff --git a/debian/maggie.nginx.conf b/debian/maggie.nginx.conf
old mode 100644
new mode 100755
index 7cda506..7eab574

Il est possible de définir une create mask dans smb.conf mais qui ne le seront pas "préserver" l'origine des autorisations de fichier. Je peux ignorer des fichiers les changements de mode de git par la mise en fileMode = false dans .gitconfig mais qui ignore le problème.

Est-il un moyen de préserver les permissions sur les fichiers lorsqu'ils sont modifiés à partir de linux?

  • mon /etc/login.defs dit UMASK 022, est pertinente?
  • j'ai essayé de jouer avec le umask de la valeur, mais sans succès. avez-vous une référence à la documentation que vous avez vu sur qui?
  • je sais que sur umask. je voulais savoir pourquoi pensez-vous umask a de quoi faire de samba de création de fichier et si il y avait tous les documents se référant à la.
  • Oui. J'ai trouvé quelques morceaux de documentation.
  • Ceux qui étaient à la fois des questions d'utilisateurs à propos de umask affectant samba de création de fichier. À ma connaissance, il n'a pas. C'est la raison pour laquelle il est create mask et directory mask paramètres dans Samba. Si vous avez un peu de temps libre, lisez la section Création de Masques ici: samba.org/samba/docs/using_samba/ch08.html - ça explique pourquoi umask n'a pas d'effet de la samba.
InformationsquelleAutor recognosco | 2014-01-06
  1. 71

    Pourrait enfin comprendre pourquoi la permission a été en train de changer. La confusion est née de la map archive = yes étant la valeur par défaut dans Samba. Après le réglage de map archive = no, le propriétaire bit d'exécution commencé à se comporter comme j'ai prévu de se comporter.

    Trouvé la réponse en lisant la documentation ici: http://www.samba.org/samba/docs/using_samba/ch08.html dans le les Autorisations de Fichier et les Attributs sur MS-DOS et Unix section. Il mentionne clairement de ce côté-effet:

    Par conséquent, ce n'est pas pour tout de trois Unix bits exécutables qui sont présents sur un fichier dans une Samba disque partager. Les fichiers DOS, cependant, ont leurs propres attributs qui doivent être conservées lorsqu'elles sont stockées dans un environnement Unix: l'archive, le système et cachés bits. Samba est possible de conserver ces bits grâce à la réutilisation de l'exécutable de l'autorisation de bits du fichier côté Unix--s'il est invité à le faire. La cartographie de ces bits, cependant, a un effet pervers: si un utilisateur Windows stocke un fichier dans un partage Samba, et vous l'affichez sur Unix avec la ls -al commande, certains de l'exécutable bits ne veut pas dire que ce que vous attendez d'eux.

    Toutefois, il mentionne également:

    Nous devons vous avertir que la valeur par défaut de la map archive option est yes, tandis que les deux autres options ont une valeur par défaut de no. C'est parce que de nombreux programmes ne fonctionnent pas correctement si le bit d'archive n'est pas stocké correctement pour DOS et Windows fichiers. Les attributs système et cachés, cependant, ne sont pas critiques pour un fonctionnement du programme et sont laissées à la discrétion de l'administrateur.

    Vous pouvez également lire plus sur le bit d'archive ici: http://en.wikipedia.org/wiki/Archive_bit

    • WOW, magnifique travail!!!
    • Merci pour le suivi; j'ai eu le même problème aujourd'hui et cette réponse a sauvé la journée!
    • Hah, je suis ici avoir le exact même problème (git diff en me montrant 644-755 modification des autorisations), merci pour cette
    InformationsquelleAutor recognosco