Le client Windows demande un mot de passe, mais pas Linux.

2

Je suis sur le point de tirer mes cheveux. Je suis en train de reconstruire ma boîte NAS personnelle et je peine à installer SAMBA.

Je souhaite disposer de partages sans authentification invités basés sur des invités anonymes, accessibles à toutes les machines de mon réseau, notamment les appareils exécutant Windows, Linux et Android.

J'ai oublié de faire une copie de sauvegarde de mon ancienne configuration de samba, mais voici ce que j'ai après des jours de recherche: 

[global]
    workgroup = WORKGROUP
    map to guest = bad user
    guest account = nobody

[share]
        path = /var/samba_lz
        browsable = yes
        guest ok = yes
        read only = no

Le problème est que le partage fonctionne parfaitement sur mes appareils Linux et Android, mais PAS sur Windows! Windows continue à afficher le dialogue d'authentification et aucune combinaison de noms d'utilisateur + mots de passe que je peux penser ne fonctionne et cela ne me permet pas de le laisser vide

Le serveur est Ubuntu 14.04 et la version de Windows que j'ai des problèmes est 7. Le répertoire samba_lz est chmodded à 777 et appartient au compte utilisateur principal de la machine.

Toute aide serait appréciée.

windows samba file-sharing getack
la source
dans Windows, essayez à partir de dos net use x: \\ nomserveur \ nom_partage "" / utilisateur: ""
c4f4t0r
OK votre suggestion a fonctionné ... Il a demandé un nom d'utilisateur et un mot de passe et j'ai fourni les informations d'identification UNIX utilisées sur le serveur. Quand j'ai réessayé le partage, cela a fonctionné ... Pouvez-vous expliquer ce qui s'est passé? Je suppose que même si cela fonctionne, ce n'est pas le compte invité qui me fournit un accès?
getack
Quand je regarde les propriétaires des fichiers de test créés dans le partage, je peux voir que tous les fichiers créés par mes machines Linux appartiennent à nobody et nogroup comme conçu. Les fichiers de test créés via Windows appartiennent toutefois à mon principal utilisateur UNIX, à qui les informations d'identification que j'ai fournies lors de la commande que vous avez suggérée. J'ai ensuite ajouté un guest only = yes directive à la share strophe et même si le partage fonctionne toujours dans Windows, tous les fichiers que je crée appartiennent maintenant à nobody et nogroup comme il est supposé. Je suis complètement confus ...
getack

Réponses:

1

D'accord, le commentaire de l'utilisateur c4f4t0r m'a envoyé dans un terrier de lapin et je pense avoir compris le problème

Étant donné que la boîte NAS porte le même nom et que le partage a le même nom, Windows disposait de certaines informations d'identification stockées pour tenter de se connecter au partage. Comme les informations d'identification ont changé sur le boîtier NAS reconstruit, cela a échoué lorsque Windows a tenté de se connecter. Pour une raison quelconque, les anciennes informations d'identification ont rebondi sur le serveur et je n'ai pas pu entrer.

La suppression de toute instance de ces informations d'identification semble avoir résolu le problème:

  1. Fonctionnement net use in cmd affichera une liste des identifiants mémorisés utilisés lors de l’accès aux ressources du réseau. J'avais un identifiant stocké pour ce partage dans cette liste.

  2. Fonctionnement wmic netuse affichera ensuite le nom d'utilisateur utilisé lors de la connexion au partage.

  3. Et enfin courir net use * \d supprimé toutes les informations d'identification stockées. Si des informations d'identification ne doivent pas être supprimées, quelque chose comme net use \\ProblemServer\ProblemShare /delete devrait alors supprimer uniquement les informations d'identification pour ce partage.

  4. À ce stade, le partage fonctionne toujours, mais seulement pendant un certain temps. Après environ 5 minutes, je reçois à nouveau la boîte des informations d'identification maudites. Seulement maintenant je peux taper littéralement n'importe quoi et ça va marcher!

  5. Donc, pour contourner ce problème, j'ai couru net use \\server\share "" /user:"" et puis la part a travaillé comme par magie. Si j'ai bien compris, j'ai maintenant demandé à Windows de toujours envoyer un nom d'utilisateur et un mot de passe vierles chaque fois que j'essayais d'accéder au partage.

Après cela, j'ai pu ouvrir le partage sans que Windows ne demande plus d'informations d'identification.

N'importe qui avec une meilleure solution ou une explication de la raison pour laquelle cela pourrait se produire est le bienvenu!

getack
la source