pxx et dans le groupe wcfipen. Ensuite, il sera possible d'accéder aux ressources avec les droits d'accès définis
sur le serveur.
Pour accéder à l'ensemble des ressources partagées sur le serveur SMB, pour l'utilisateur courant, il est demandé le mot de passe du compte, s'il n'a pas été fourni à la connexion réseau du démarrage.
Naturellement, ensuite les droits des fichiers Linux s'exercent vis
à vis de l'utilisateur connecté.
Si certains dossiers pourtant partagés sont inaccesibles, cela
est du problablement à l'absence de droits suffisants (notamment le droit x sur un rép).
pc2 sous Windows95 connecté via SMB à pc3, se voit refuser l'accès à un dossier pourtant placé dans son répertoire personnel, sur pc3 /home/jean. ls passée sur pc3 donne : drw-r----- root root dns/, ce qui montre que jean n'est pas propriétaire de ce répertoire, et plus grave encore, comme user quelconque il n'a aucun droit sur celui-ci ...
Le super-utilisateur root a enfin rectifié et lui a accordé le droit de propriété :
chown -R jean /home/jean/temp/dns.
L'accès au répertoire est maintenant permis à jean, mais il lui apparait vide sous Windows !
Jean, excédé, passe alors sur la console du serveur pc3, et lance la commande cd dns et ... tout propriétaire qu'il est, il essuie sèchement un refus : "Permission non accordée" !
En revanche, il peut voir son contenu avec ls dns, ce qui lui confirme bien qu'il n'est pas vide.
Pour s'informer de ses droits, il essaie ls -l dns, et il reçoit encore un refus !!
Mais il a (enfin) compris pourquoi et envoie aussitôt un message cinglant à root.
Et vous ? vérification
Naturellement l'utilisateur gère son espace de travail avec l'Explorateur Windows, avec ses applications comme il le ferait avec un autre type de serveur dédié.
Il peut être pratique de créer une unité de lecteur réseau (ici J:) active au démarrage.
L'utilisateur se connecte ici à pc1, un autre serveur Linux, sur lequel d'autres ressources ont été partagés : Cd-rom, et les dossiers stagiaire (privé) et public (pour tous)
