Pourquoi Mercurial retour “Abort: Accès Refusé” lorsque vous essayez de pousser un référentiel?

Je suis confronté à un problème avec un utilisateur de ne pas être en mesure de pousser sa s'engage dans un dépôt Mercurial et je suis perplexe quant à pourquoi il ne travaille pas pour lui. J'ai essayé plusieurs choses pour comprendre ce qui est en place, Googler n'est pas quelque chose d'utile... alors je suis ici.

Tout d'abord, la configuration. Nous avons un Windows XP SP2 x64 machine sur notre réseau agissant à titre officiel du repository server. Il contient plusieurs référentiels. Nous cloner /pousser /tirer à l'aide d'un dossier sur le lecteur partagé. Les autorisations sont donné à tout le monde pour l'accès en lecture. Les utilisateurs qui peuvent pousser (y compris l'utilisateur qui a des problèmes), le plein contrôle. La machine de l'utilisateur est Win XP. Ma machine (utilisé pour aider à résoudre les choses), c'est aussi Gagner des XP.

Deuxième, les symptômes. L'utilisateur est à l'aide de TortoiseHg 2.1.1 pour faire son travail. Il peut cloner un peu fine, s'engage à son local de pensions sont un-o-k, etc. Quand il essaie de pousser, cependant, TortoiseHg retourne un "abandon, ret 255" du code. Pas très utile. Nous sommes donc passés à la ligne de commande et ont émis des "hg push -v --debug". Ici, il renvoie à "abandonner: l'Accès est Refusé". Ce même utilisateur peut écrire dans le dossier partagé du serveur pas de problème, il peut créer des fichiers, de répertoires et de les supprimer. Ainsi, la lecture /écriture de l'accès au disque /dossier n'est pas un problème.

Troisièmement, nos résultats de l'expérimentation. Ici sont quelques-uns bizarre résultats de l'essai. L'utilisateur a créé un nouveau test local repo. Je suis connecté sur la machine serveur et créé un test de repo pour lui pour le pousser à. L'utilisateur vérifiée dans un fichier et ensuite poussé jusqu'à l'épreuve repo sur la machine serveur. Cela a bien fonctionné. N'abandonne. La vie était bonne. Il a été en mesure de faire un peu plus pousse et il a continué à fonctionner comme prévu. J'ai ensuite cloné le repo de ma machine, mise à jour d'un fichier, et poussé à revenir. Après que l'utilisateur a alors tiré dans mes changements et a essayé de pousser vers le serveur, il a encore une fois rencontré le redoutable "Accès Refusé" message. En attendant, je peux toujours mettre à jour le projet sans aucun problème.

Comme une autre expérience, nous avons eu l'utilisateur de se déconnecter et d'un autre utilisateur à se connecter. Ils l'ont fait et ont réussi à pousser vers le serveur repo sans problème. Original utilisateur se connecte à nouveau, fait quelques changements, etc. et encore une fois frappe le mur de brique "Accès Refusé".

Aussi loin que nous pouvons dire, le problème n'est pas lié à des informations d'identification Windows. Sinon, nous nous attendons à ce que la création de fichiers arbitraires sur le serveur du dossier partagé ne fonctionnerait pas. De plus, jusqu'à ce que j'ai fait une mise à jour du test de pensions de l'utilisateur créé, il pourrait pousser à particulier des pensions de l'amende juste.

Des idées? Quelles sont les autres informations d'identification des contrôles Mercurial décisions qui pourraient en être la cause?

Mise à JOUR:

Après un bout de Wim, j'ai commencé à regarder les autorisations sur les différents objets de l'opération à l'aide de la "cacls'. C'est un outil de Windows qui "affiche ou modifie les listes de contrôle d'accès de fichiers". J'ai eu l'utilisateur créer un nouveau repo et puis il a pris un instantané des autorisations. J'ai ensuite vérifié dans un fichier au même repo et a pris un autre aperçu de ces changements.

Il s'avère qu'il y a plusieurs pensions de permissions de fichiers mis à jour à la suite de cette: annuler.signets, annuler.branche, annuler.desc, annuler.dirstate, branchheads, 00changelog.j', 00manifest.j', annuler, et le seul fichier du référentiel. Tous ces fichiers avaient autorisations semblable à la suivante:

C:\Projects\Mercurial\hgtest4\.hg\store\undo BUILTIN\Administrators:F 
                                         NT AUTHORITY\SYSTEM:F 
                                         DOMAINxxxx\USERIDxxxx:F 
                                         BUILTIN\Users:R 

(réelle DOMAINxxxx et USERIDxxxx les valeurs ont été modifiées). Avant mon arrivée, DOMAINxxxx & USERIDxxxx reflète le domaine de l'utilisateur et nom d'utilisateur. Après mon check-in, la ces s'est mis à jour à la mienne (nous sommes sur le même domaine, mais le nom d'utilisateur est évidemment différente.) J'ai été en mesure de vérifier les choses et même si mon userid n'était pas dans la liste parce que je suis un membre du groupe BUILTIN\Administrateurs. L'utilisateur avec le problème n'est pas. Donc, j'imagine qu'après que j'ai vérifié les choses, le système n'est plus vu comme un utilisateur identifié après les accès en écriture (BUILTIN\Utilisateurs:R indique que l'accès en Lecture seule) et donc causé le déni d'accès.

J'ai terriblement Q&D pour la fixer en place dès maintenant (l'utilisateur est maintenant partie du groupe Admin...) La vraie solution va être d'obtenir les pensions de titres hors de Partage de Windows et sur un bon serveur de configuration.

OriginalL'auteur MutantXenu | 2011-12-01