OVH Cloud OVH Cloud

smb.conf

43 réponses
Avatar
Maclin
Bon, on continue dans la lancée, pourquoi se retenir :)
sur un réseau local j'ai trois pécés (ouiouin 2000 +1serveur 2000) qui
se connecte trés bien à un serveur Mac OsX, donc samba, mais comme
chacun sait, il suffit pour cela, sur mac, de cliquer sur un bouton
(+600€, mieux que bill et moins con, mais quand même). je me suis donc
dit que si ça marchait avec un Mac il ne serait pas si difficile de se
connecter à un serveur samba Linux (fedora core 1) et ça n'est pas le
cas, "testparm" se contente de "Loaded services file OK.", les logs
/samba/nmbd.log ne contiennent pas grand chose et /samba/smbd.log encore
moins, mais aucun des pécés ne voit le serveur, rien dans le voisinage
réseau; voici mon smb.conf inspiré de Lealinux :
# testparm
Load smb config files from /etc/samba/smb.conf
Processing section "[homes]"
Processing section "[printers]"
Processing section "[SambaGG]"
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

# Global parameters
[global]
server string = Serveur Samba
log file = /var/log/samba/%m.log
max log size = 500
printcap name = /etc/printcap
preferred master = Yes
domain master = Yes
dns proxy = No
wins support = Yes
hosts allow = 192.168.3.
cups options = raw

[homes]
comment = Home Directories
path = /home/%u
read only = No
create mask = 0750

[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No

[SambaGG]
comment = SambaGG
path = /home/laurent
valid users = laurent+
read only = No
hosts allow = localhost, 192.168.3.

Merci d'avance pour votre aide

10 réponses

1 2 3 4 5
Avatar
Jerome Lambert
Le Wed, 11 Aug 2004 15:26:50 +0200, Maclin a écrit :
Jerome Lambert wrote:
(...)

D'après ce que j'ai pu découvrir ça et là sur le net, il y *aurait* un
conflit sur les IP.

La machine a-t-elle deux cartes réseau ou une carte réseau et un modem?

elle a bien 2 cartes reseau, mais je pense n'en avoir activé qu'une,

maintenant ...


Autre piste que je viens de découvrir à la 2345ème page de résultats
Google, samba se bat avec un autre programme qui squatte le port 139.

Il est alors conseillé de faire lsof -i:139 en root pour voir qui est le
squatteur, et éventuellement le dégager de là...

--
Jerome
"Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux.
Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo."
M. in fr.comp.os.linux.debats


Avatar
Jerome Lambert
Le Wed, 11 Aug 2004 15:29:51 +0200, Jerome Lambert a écrit :

Le Wed, 11 Aug 2004 15:26:50 +0200, Maclin a écrit :
Jerome Lambert wrote:
(...)

D'après ce que j'ai pu découvrir ça et là sur le net, il y *aurait* un
conflit sur les IP.

La machine a-t-elle deux cartes réseau ou une carte réseau et un modem?

elle a bien 2 cartes reseau, mais je pense n'en avoir activé qu'une,

maintenant ...


Autre piste que je viens de découvrir à la 2345ème page de résultats
Google, samba se bat avec un autre programme qui squatte le port 139.

Il est alors conseillé de faire lsof -i:139 en root pour voir qui est le
squatteur, et éventuellement le dégager de là...


Je viens de reproduire l'erreur sur ma machine perso.

J'ai d'abord bricolé mon serveur ssh pour qu'il squatte le port 139,

ensuite:
[]~# /etc/rc.d/init.d/sshd start
Démarrage de sshd : [ OK ]
[]~# /etc/rc.d/init.d/smb start
Démarrage des services SMB : [ OK ]
Démarrage des services NMB : [ OK ]
[]~# /etc/rc.d/init.d/smb status
smbd est mort mais le fichier pid existe
nmbd (pid 4994) en cours d'exécution...
[]~# more /var/log/samba/smbd.log
(...)
[2004/08/11 15:38:49, 0] lib/util_sock.c:open_socket_in(689)
bind failed on port 139 socket_addr = 0.0.0.0.
Error = Adresse déjà utilisée

[]~# lsof -i:139
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
sshd 5025 root 3u IPv6 11294 TCP *:netbios-ssn (LISTEN)

sshd squatte effectivement le port 139...

Si je remets sshd sur le port 22 (port par défaut) et que je restart sshd
et smb, tout rentre dans l'ordre...

--
Jerome
"Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux.
Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo."
M. in fr.comp.os.linux.debats



Avatar
Maclin
Autre piste que je viens de découvrir à la 2345ème page de résultats
Google, samba se bat avec un autre programme qui squatte le port 139.
Il est alors conseillé de faire lsof -i:139 en root pour voir qui est le
squatteur, et éventuellement le dégager de là...
J'ai d'abord bricolé mon serveur ssh pour qu'il squatte le port 139,

ensuite:
[]~# /etc/rc.d/init.d/sshd start
Démarrage de sshd : [ OK ]
[]~# /etc/rc.d/init.d/smb start
Démarrage des services SMB : [ OK ]
Démarrage des services NMB : [ OK ]
[]~# /etc/rc.d/init.d/smb status
smbd est mort mais le fichier pid existe
nmbd (pid 4994) en cours d'exécution...
[]~# more /var/log/samba/smbd.log
(...)
[2004/08/11 15:38:49, 0] lib/util_sock.c:open_socket_in(689)
bind failed on port 139 socket_addr = 0.0.0.0.
Error = Adresse déjà utilisée

[]~# lsof -i:139
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
sshd 5025 root 3u IPv6 11294 TCP *:netbios-ssn (LISTEN)
Ben moi j'ai :

# lsof -i:139
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
xinetd 1597 root 6u IPv4 1714 TCP *:netbios-ssn (LISTEN)


sshd squatte effectivement le port 139...

Si je remets sshd sur le port 22 (port par défaut) et que je restart sshd
et smb, tout rentre dans l'ordre...




Avatar
Jerome Lambert
Le Wed, 11 Aug 2004 15:52:53 +0200, Maclin a écrit :
(...)
Ben moi j'ai :
# lsof -i:139
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
xinetd 1597 root 6u IPv4 1714 TCP *:netbios-ssn (LISTEN)


On dirait que xinetd a lancé un truc sur le port 139...

Que donne ls /etc/xinetd.d/ ?


--
Jerome
"Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux.
Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo."
M. in fr.comp.os.linux.debats

Avatar
Maclin
Ben moi j'ai :
# lsof -i:139
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
xinetd 1597 root 6u IPv4 1714 TCP *:netbios-ssn (LISTEN)


On dirait que xinetd a lancé un truc sur le port 139...
Que donne ls /etc/xinetd.d/ ?

# ls /etc/xinetd.d/

chargen daytime-udp gssftp netbios-ns sgi_fam tftp
chargen-udp echo klogin netbios-ssn swat time
cups-lpd echo-udp krb5-telnet rsync swat.rpmsave time-udp
daytime eklogin kshell services telnet


Avatar
Jerome Lambert
Le Wed, 11 Aug 2004 15:59:28 +0200, Maclin a écrit :

Ben moi j'ai :
# lsof -i:139
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
xinetd 1597 root 6u IPv4 1714 TCP *:netbios-ssn (LISTEN)


On dirait que xinetd a lancé un truc sur le port 139...
Que donne ls /etc/xinetd.d/ ?

# ls /etc/xinetd.d/

chargen daytime-udp gssftp netbios-ns sgi_fam tftp
chargen-udp echo klogin netbios-ssn swat time
cups-lpd echo-udp krb5-telnet rsync swat.rpmsave time-udp
daytime eklogin kshell services telnet


Les coupables seraient netbios-ns et/ou netbios-ssn.

Le mieux est d'éditer ces fichiers et de positionner la variable disable
sur yes pour que xinetd ne les lance pas.

Ensuite un petit /etc/rc.d/init.d/xinetd restart pour prendre en compte
les nouveaux paramètres, et puis on peut tenter de lancer à nouveau
samba...

--
Jerome
"Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux.
Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo."
M. in fr.comp.os.linux.debats



Avatar
Maclin
Jerome Lambert wrote:
Les coupables seraient netbios-ns et/ou netbios-ssn.
Le mieux est d'éditer ces fichiers et de positionner la variable disable
sur yes pour que xinetd ne les lance pas.
Ensuite un petit /etc/rc.d/init.d/xinetd restart pour prendre en compte
les nouveaux paramètres, et puis on peut tenter de lancer à nouveau
samba...
C'est OK Maestro samba est reparti, j'ai rien compris du pourquoi

netbios, du comment xinetd mais faut avouer que c'est efficace, si un
jour tu as une mn :) ...
mais c'est pas fini, parceque redhat-config-samba dans "paramettre
serveurs" ne veut pas se lancer, de temps en temps il demande le mot de
passe root puis glisse un sablier une vingtaine de secondes puis
s'éclipse sans même ouvrir la moinde fenêtre,HTTP, Booting, NFS, DNS,
Services, eux s'ouvrent très bien mais pas samba ???

Avatar
Maclin
Maclin wrote:
Redhat-config-samba dans "paramettre
serveurs" ne veut pas se lancer, de temps en temps il demande le mot de
passe root puis glisse un sablier une vingtaine de secondes puis
s'éclipse sans même ouvrir la moinde fenêtre,HTTP, Booting, NFS, DNS,
Services, eux s'ouvrent très bien mais pas samba ???


En saisissant la commande voilà ce que m'a répo,du le terminal :
# redhat-config-samba
Traceback (most recent call last):
File "/usr/share/redhat-config-samba/redhat-config-samba.py", line 20,
in ?
mainWindow.MainWindow(debug_flag)
File "/usr/share/redhat-config-samba/mainWindow.py", line 58, in
__init__
self.samba_data = sambaParser.SambaParser(self)
File "/usr/share/redhat-config-samba/sambaParser.py", line 24, in
__init__
self.parseFile()
File "/usr/share/redhat-config-samba/sambaParser.py", line 55, in
parseFile
token = self.createToken(line)
File "/usr/share/redhat-config-samba/sambaParser.py", line 127, in
createToken
token sambaToken.SambaToken(sambaToken.SambaToken.SAMBA_TOKEN_KEYVAL,
(nam e, value), self.parent)
File "/usr/share/redhat-config-samba/sambaToken.py", line 20, in
__init__
raise AttributeError, value
AttributeError: ('cups options', 'raw')

Bizare non ? un conflit avec cups cette fois ?

Avatar
Jerome Lambert
Le Wed, 11 Aug 2004 16:32:21 +0200, Maclin a écrit :

Jerome Lambert wrote:
Les coupables seraient netbios-ns et/ou netbios-ssn.
Le mieux est d'éditer ces fichiers et de positionner la variable disable
sur yes pour que xinetd ne les lance pas.
Ensuite un petit /etc/rc.d/init.d/xinetd restart pour prendre en compte
les nouveaux paramètres, et puis on peut tenter de lancer à nouveau
samba...
C'est OK Maestro samba est reparti, j'ai rien compris du pourquoi

netbios, du comment xinetd mais faut avouer que c'est efficace, si un
jour tu as une mn :) ...


C'est parti (et relativement simple, d'ailleurs...)

Samba, ou plutot le démon smbd écoute sur le port 139 pour accepter les
connections
Xinetd est une sorte de "super démon" qui lance toute une série de
services.

Un de ces services (netbios-ns et/ou netbios-ssn) squatte le
port 139, ce qui entraîne un sévère dysfonctionnement de Samba.

Donc pour faire fonctionner Samba, il faut empecher Xinetd de lancer ces
deux squatteurs.

Cela se paramètre dans les fichiers /etc/xinetd.d/fichiers, en mettant
disable = yes

Prolongement: qui a foutu ces fichiers à cet endroit là?
Réponse avec copain yum: yum provides netbios-ns

Si yum ne trouve pas, c'est amha un résidu de Redhat qui hante le disque
dur...

mais c'est pas fini, parceque redhat-config-samba dans "paramettre
serveurs" ne veut pas se lancer, de temps en temps il demande le mot de
passe root puis glisse un sablier une vingtaine de secondes puis
s'éclipse sans même ouvrir la moinde fenêtre,HTTP, Booting, NFS, DNS,
Services, eux s'ouvrent très bien mais pas samba ???


Que dit yum install cups?

--
Jerome
"Moi, je trouve ça rigolo quand y a un truc qui marche pas avec Linux.
Chercher à le faire marcher m'amuse beaucoup. C'est mieux qu'un jeu vidéo."
M. in fr.comp.os.linux.debats


Avatar
MACLIN
Jerome Lambert wrote:
Si yum ne trouve pas, c'est amha un résidu de Redhat qui hante le disque
dur...
Qu'il faut effacer ? comment ?


mais c'est pas fini, parceque redhat-config-samba dans "paramettre
serveurs" ne veut pas se lancer, de temps en temps il demande le mot de
passe root puis glisse un sablier une vingtaine de secondes puis
s'éclipse sans même ouvrir la moinde fenêtre,HTTP, Booting, NFS, DNS,
Services, eux s'ouvrent très bien mais pas samba ???


Que dit yum install cups?

cups is installed and is the latest version.

No actions to take


1 2 3 4 5