Zurück

How to setup SAMBA ?

Inhalt

Wichtig zu wissen

Installation
Password Security
Troubleshooting aus DIAGNOSIS.TXT
NetBios Alias Namen
WINS Support
Local Subnet Browsing
Browsing across Subnets
Router und Broadcasts

SAMBA ermöglicht es, UNIX-Directories und Printer der Windows Welt transparent zur Verfügung zu stellen. Der grosse Vorteil von SAMBA gegenüber NFS-Lösungen unter Windows ist, dass auf dem Client keine zusätzliche Software installiert werden muss. Der Client kann wie gewohnt Laufwerke und Printer im Netzwerk (Map Network Drive) einbinden. SAMBA implementiert das SMB Protokoll von Microsoft. Richtig konfiguriert, können lokale WIN-NT Workstations, WIN-NT Workstations in einem anderen Netzwerkzweig (LAN - LAN) und RAS-Clients (PPP-Verbindung über ISDN) Shares und Printer auf dem UNIX Server transparent ansprechen. Der folgende Artikel zeigt, wie SAMBA installiert und konfiguriert werden muss. Im folgenden werden folgende Hostnamen verwendet:

SAMBA Server unter RedHat Linux 6.2: rabbit
SAMBA Client unter WIN-NT4 ServicePack 5: arkum
WORKGROUP: AKADIA

Wichtig zu wissen

  • SAMBA benutzt die TCP/IP Ports 137, 138 und 139. Dies ist wichtig zu wissen wenn über ein WAN keine Verbindung zu Stande kommt, da diese Ports möglicherweise im Firewall oder Router gesperrt sind.
  • SAMBA benutzt die UNIX File- und Directory Rechte.
  • Auf dem NT-Client muss keine zusätzliche Software installiert werden. Man muss aber die DOMAIN oder WORKGROUP richtig einstellen.
  • SAMBA unterstützt "Plain-Passwords" und "Encrypted Passwords".
  • Ein SAMBA Share ist Read-Only per Default.
  • Symbolic Links werden auch ausserhalb des Filesystems verfolgt wenn die Parameter  wide links = Yes und follow symlinks = Yes gesetzt werden.

Installation

Souren installieren:

Source von http://www.samba.org herunterladen (latest.tar.gz)

gzip < samba-2.0.7.tar.gz | tar xvf -
cd source
./configure
make
make install

Aktivierung der SMB Serverdienste in /etc/services

netbios-ns 137/tcp nbns
netbios-ns 137/udp nbns
netbios-dgm 138/tcp nbdgm
netbios-dgm 138/udp nbdgm
netbios-ssn 139/tcp nbssn

Testen der Installation auf SAMBA Server

- Die Installation erfolgt per default in /usr/local/samba.
- Startup Scripts in /etc/rc.d/init.d (Linux), /etc/rc.d /Solaris)
- Test der Installation mit:

smbstatus
smbclient -L rabbit -N
smbclient -N -L rabbit -U%
smbclient //rabbit/zahn

Passwort eingeben, im SMB Prompt: DIR eingeben

NetBios Status kontrollieren

nmblookup AKADIA -S

Starten der SMB Daemons

/usr/local/samba/bin/smbd -D
/usr/local/samba/bin/nmbd -D

SWAT installieren zur Konfiguration von smb.conf

- Eintrag in /etc/services: swat 901/tcp
- Eintrag in /etc/inetd.conf:

swat stream tcp nowait.400 root /usr/local/samba/bin/swat swat

Swat starten: (vorher inetd neu starten)

http://rabbit:901

Beachte:

bind interfaces only = no (smbpasswd benutzen)
short preserve case = yes
preserve case = yes

Never use "case sensitive = yes".

Bei Problemen Log-Level höher setzen: debug level = 3.
Name Resolution: name resolve order entspricht /etc/nsswitch.conf von Solaris und Linux.

Password Security

SAMBA unterstützt Plain-Text Passwords und Windows-NT Passwort Encryption.

Plain-Passwords

Plain-Passwords erfordern SAMA seitig keine Anpassungen, es wird direkt das /etc/passwd file von UNIX verwendet. Man muss jedoch auf dem NT4 Client den Registry Eintrag für Plain-Passwords ändern.

Artikel aus der SAMBA News Group

One of the most annoying problems with WinNT is that NT refuses to connect to a server that is in user level security mode and that doesn't support password encryption unless it first prompts the user for a password. This means even if you have the same password on the NT box and the Samba server you will get prompted for a password. Entering the correct password will get you connected only if Windows NT can communicate with Samba using a compatible mode of password security. All versions of Windows NT prior to 4.0 Service Pack 3 could negotiate plain text (clear text) passwords. Windows NT 4.0 Service Pack 3 changed this default behaviour so it now will only handle encrypted passwords. The following registry entry change will re-enable clear text password handling:

Run regedt32.exe and locate the hive key entry:

HKEY_LOCAL_MACHINE\system\CurrentControlSet\Services\Rdr\Parameters\

Add the following value:

EnablePlainTextPassword:REG_DWORD=1

Encrypted passwords

Encrypted passwords sind aufwendiger zu administrieren, da ein eigenes Passwortfile für SAMBA generiert werden muss:

cat /etc/passwd | mksmbpasswd.sh >/usr/local/samba/private/smbpasswd
encrypt passwords = Yes
update encrypted = No

Troubleshooting SMB Daemons smbd and nmbd

TEST 1:
-------
Run the command netstat -a on the server, and look for lines mentioning netbios, 137 or 139. Among many similar lines, there should be at least one UDP line for *.netbios- or *.137. This indicates that the nmbd server is registered and is waiting to answer requests. There should also be at least one TCP line mentioning *netbios- or *139, and it will probably be in the LISTENING state. This means that smbd is up an listening for connections.

netstat -a | grep netbios

tcp 0 0 rabbit:netbios-ssn venus:1033 ESTABLISHED
tcp 0 0 rabbit:netbios-ssn arkum:1363 ESTABLISHED
tcp 0 0 *:netbios-ssn *:* LISTEN
udp 0 0 rabbit:netbios-dgm *:*
udp 0 0 rabbit:netbios-ns *:*
udp 0 0 *:netbios-dgm *:*
udp 0 0 *:netbios-ns *:*

TEST 2:
-------
Testing the smbd server with telnet

echo "hello" | telnet rabbit 139
Trying 193.72.194.131...
Connected to rabbit.
Escape character is '^]'.
Connection closed by foreign host.

You must get the message "Connected ..."

Troubleshooting aus DIAGNOSIS.TXT

TEST 1:
-------
In the directory in which you store your smb.conf file, run the command: "testparm smb.conf". If it reports any errors then your smb.conf configuration file is faulty.

TEST 2:
-------
run the command "ping rabbit" from the PC and "ping arkum" from the unix box. If you don't get a valid response then your TCP/IP software is not correctly installed.

TEST 3:
-------
Run the command "smbclient -P -L rabbit" on the unix box. You should get a list of available shares back.
 
TEST 4:
-------
Run the command "nmblookup -B rabbit __SAMBA__". You should get the IP address of your Samba server back.
 
TEST 5:
-------
run the command "nmblookup -B arkum '*'"

You should get the PCs IP address back.

TEST 6:
-------
Run the command "nmblookup -d 2 '*'"

This time we are trying the same as the previous test but are trying it via a broadcast to the default broadcast address. A number of Netbios/TCPIP hosts on the network should respond, although Samba may not catch all of the responses in the short time it listens.

TEST 7:
-------
Run the command "smbclient '\\rabbit\TMP'". You should then be prompted for a password. You should use the password of the account you are logged into the unix box with.

TEST 8:
-------
On the PC type the command "net view \\rabbit". You will need to do this from within a "dos prompt" window. You should get back a list of available shares on the server.

Shared resources at \\rabbit
Samba on RABBIT
Share name Type Used as Comment
----------------------------------------------------------
archive Disk G: Akadia's archive
ps Print
zahn Disk Home Directory of zahn

TEST 9:
--------
Run the command "net use x: \\rabbit\TMP". You should be prompted for a password then you should get a "command completed successfully" message.

TEST 10:
--------
Check that NetBios is working correctly on the NT4 Client, run:
nbtstat -a RABBIT
NetBIOS Remote Machine Name Table

Name Type Status
---------------------------------------------
RABBIT <00> UNIQUE Registered
RABBIT <03> UNIQUE Registered
RABBIT <20> UNIQUE Registered
AKADIA <00> GROUP Registered
AKADIA <1E> GROUP Registered

TEST 11:
--------
Check, that WORKGROUP is correctly setup in Network Control Panel. We use the name: WORKGROUP = AKADIA

TEST 12:
--------
From file manager try to browse the server. Your samba server should appear in the browse list of your local workgroup (or the one you specified in smb.conf). You should be able to double click on the name of the server and get a list of shares.

NetBios Alias Namen

The NT SMB Redirector (Workstation Service) has one small deficiency: You cannot connect to the same SMB Server using multiple usernames. If you try to connect to the second share using net use p: \\samba-server\share /user:user-name, you get the error message: The credentials supplied conflict with an existing set of credentials. The workaround is to use the IP-Adress for the second connection or use NetBios Alias Names:

netbios aliases = RABBIT1 RABBIT2 RABBIT3

WINS Support

NetBios Clients lösen (resolves) NetBios Namen namen via Broadcast (Sent to every machine on the subnet) auf. Auf die gleiche Art lassen sie sich selbst im Subnet registrieren. Dies hat einen grossen Network Traffic zur Folge. Ein weiteres Problem ist, dass diese Broadcasts innerhalb des Subnets isoliert sind. Maschinen in verschiedenen Subnetzen können so nicht kommunizieren. Um diese Probleme zu umgehen muss der WINS Service eingesetzt werden und eine WINS Server muss definiert werden, pro Subnet 1 WINS Server.

Merkmale WINS Support

  • WINS löst IP-Adressen / NetBios Namen innerhalb eines Subnetztes auf .
  • Pro Subnetz nur 1 einziger WINS-Server definieren.
  • WINS-Server können als WINS Proxy Server definiert werden um mit anderen WINS Server in anderen Subnetzen zu kommunizieren.

Relevante WINS Parameter in smb.conf

Im Konfigurationsfile smb.conf muss der WINS-Server definiert werden, dies ist in unserem Fall der NT-Server mit der IP-Adresse 193.72.194.134. Um den SAMBA Server bequem zu administrieren verwendet man am besten die WEB-Applikation SWAT (zB. http://rabbit:901). Die folgenden Einträge in smb.conf sind zwingend, wenn der SAMBA Server selbst nicht WINS-Server ist: wins support = No. Mit dem Parameter: wins proxy = Yes, wird NMBD dazu veranlasst NetBios Name Queries (Registration und Resolution) an den in smb.conf definierten WINS-Server weiterzuleiten.

wins support = No
wins server = 193.72.194.134
wins proxy = Yes
dns proxy = Yes

Konfiguration des WINS-Servers

WINS muss als Service auf dem NT-Server installiert werden. Der WINS-Server könnte jedoch auch als Bestandteil der SAMBA Konfiguration auf dem Linux Rechner installiert werden. Gemäss SAMBA Dokumentation darf nur ein einziger WINS-Server im Netzwerk laufen. Im Control-Panel / Network / Services wird der WINS-Server installiert. Die WINS-Adresse beim Konfigurieren des TCP/IP Protokolls muss auf 193.72.194.134 gesetzt werden.

WIN Server Konfiguration

Der Windows Internet Name Service muss installiert werden im Control Panel / Network.

Konfiguration der normalen SAMBA-Clients

Ein Vorteil von SAMBA besteht darin, dass keine Client Software installiert werden muss. Es wird nur der WINS-Server angegeben (siehe Screenshot unten) und der SAMBA Service wird beispielsweise mittels \\rabbit\share-name als virtuelles Laufwerk im lokalen Dateibaum "eingehängt". Die Browsing Liste erscheint oft über Router-Strecken nicht, auch wenn keine Subnetzte vorhanden sind. Dazu gibt man im Path bei "Map Network Drive" im Explorer nur den SAMBA-Server ein, beispielsweise \\rabbit.

Konfiguration des SAMBA Clients

Local Subnet Browsing

Browsing Listen werden von Windows an verschiedenen Orten (zB. Map Network Drive, Network Neighborhood, etc) angezeigt, um dem User Ressourcen (Shares, Printer) im Netzwerk anzuzeigen. Die Browsing Liste wird vom Master Browser zur Verfügung gestellt, ein SAMBA Server kann ein Master Browser werden oder auch nicht. Grundsätzlich können mehrere Master Browser definiert werden, diese "einigen" sich dann untereinander selbst wer nun wirklich der Master Browser wird. Man hat also keine 100% Gewähr dafür, wer der Master Browser wird.

Definieren eines SAMBA Servers als Master Browser im Subnet

os level = 20
preferred master = Yes
local master = Yes

Definieren eines SAMBA Servers als normaler Host

os level = 0
preferred master = No
local master = No

Der Parameter os level definiert eine Priorität (NT-Server = 32, NT-Workstation = 16, Win95 /WfW = 1). Wird ein Wert von 20 definiert, so "gewinnt" ein NT-Server. Mit preferred master = Yes wird definiert, dass der SAMBA Server der favorisierte Master Browser für die Workgroup (AKADIA) sein soll. Mit local master = Yes versucht der SAMBA Server beim Startup ein Master Browser für das Subnetz zu werden. Die Browsing Liste wird unter /usr/local/samba/var/locks im File browse.dat gespeichert.

Kontrollieren wer der Master Browser ist

nmblookup -T -M AKADIA
querying AKADIA on 193.72.194.255
rabbit, 193.72.194.131 AKADIA<1d>

Man gibt die Workgroup ein bei nmblookup (AKADIA), der Master Browser ist in diesem Fall der SAMBA Server rabbit.

Browsing across Subnets

Damit ein Browsing zwischen Subnetzen funktioniert müssen verschiedene Bedingungen erfüllt sein. Grundsätzlich beschränkt sich das WORKGROUP Konzept auf ein Subnetz, das heisst WORKGROUPS können nicht Subnetz übergreifend sein. Um dies zu ermöglichen stehen zwei Möglichkeiten offen:

  • Zwei SAMA Server als "Domain Master" definieren.
  • Windows NT PDC (Primary Domain Controller) installieren.

Zwei SAMBA Server als "Domain Master" definieren

In beiden Subnetzen (Eine WOKGROUP pro Subnetz) ein SAMBA Server als Domain Master definieren. Damit wird SAMBA dazu veranlasst, workgroup-wide Browsing Lists zu sammeln.

Beispiel (Router lässt Broadcasting zu)

Ein Netzwerk besteht aus drei Subnetzen 172.16.1.0, 172.16.2.0 und 172.30.3.0. Der Domain Master Browser ist im Subnetz 172.30.3.0. Es wird ein WORKGROUP Konzept verwendet, in allen Subnetzen heissen die Workgroups AKADIA.

SAMBA Server als Master Browser in 172.30.3.0

domain master = Yes
local master = Yes
remote browse sync = 172.16.1.255 172.16.2.255

SAMBA Server als Subnet Browser in 172.16.1.0

domain master = No
local master = Yes
remote browse sync = 172.30.3.255 172.16.2.255

SAMBA Server als Subnet Browser in 172.16.2.0

domain master = No
local master = Yes
remote browse sync = 172.30.3.255 172.16.1.255

Router und Broadcasts

Router, welche Subnetzte verbinden lassen meistens ein Broadcasting auf der Boadcast Adresse 255 (zB 176.16.1.255) nicht zu. In diesem Fall muss die IP-Adresse des lokalen Master Browser angegben werden.

Beispiel (Router lässt Broadcasting nicht zu)

Ein Netzwerk besteht aus drei Subnetzen 172.16.1.0, 172.16.2.0 und 172.30.3.0. Der Domain Master Browser ist im Subnetz 172.30.3.0. Es wird ein WORKGROUP Konzept verwendet, in allen Subnetzen heissen die Workgroups AKADIA.

SAMBA Server: 172.30.3.10 als Master Browser in 172.30.3.0

domain master = Yes
local master = Yes
remote browse sync = 172.16.1.25 172.16.2.15

SAMBA Server: 172.16.1.25 als Subnet Browser in 172.16.1.0

domain master = No
local master = Yes
remote browse sync = 172.30.3.10 172.16.2.15

SAMBA Server: 172.16.2.15 als Subnet Browser in 172.16.2.0

domain master = No
local master = Yes
remote browse sync = 172.30.3.10 172.16.1.25