Win SBS Server sieht den Linux Samba nicht

Hallo,
in unserem kleinen Firmennetz gibt es einen Windows SBS 2011 Essential (Hauptserver) und einen älteren Linux (Debian) Server, der hauptsächlich als Backup-Storage benutzt wird. Dazu läuft auf dem Linux ein Samba Server. Auf diesen komme ich mit meinem Win7 (64Bit) problemlos drauf. Ebenso sehe ich am Win7-Client alle Freigaben vom SBS und kann auch darauf zugreifen.

Der SBS kann aber nicht auf das Linux SAMBA zugreifen. Der Server erscheint in der Netzwerkumgebung, aber beim Versuch des Zugriffs dauert es eine Weile bis (vermutlich) ein Timeout greift und Windows eine entspr. Fehlermeldung ausgibt.
Diese lautet so:
"""
Auf \\BACKUPSERVER kann nicht zugegriffen werden. Sie haben eventuell keine Berechtigung, diese Netzwerkressource zu verwenden. ... Der Benutzername konnte nicht gefunden werden.
"""
Allerdings kommt kein Login-Dialog, weshalb ich nicht mal weiß, welchen Benutzernamen er nicht findet.

Ich benötige somit Hilfe, um den Verursacher der Störung zu finden. Welche weiteren Infos benötigt ihr um mir antworten zu können?

Gruß
Torsten

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 177968

Url: https://administrator.de/contentid/177968

Ausgedruckt am: 15.11.2024 um 16:11 Uhr

23 Kommentare

Neuester Kommentar

Hallo Torsten,

ich kenne den SBS nicht! Gibt es da so etwas wie AD oder wie regelst du deine Benutzerverwaltung? Der Samba kann über Lokale-, AD- sowie LDAP-Benutzer authentifizieren. Würde vermuten dein Benutzer auf dem SBS hat den gleichen Namen wie einer vom Samba...??

Was steht im samba log? Such ein Log das den Namen oder IP deines SBS trägt...

Der SBS 2k11 Essentials ist ein SBS 2011 Server mit einigen Vereinfachungen und auch fehlenden Features wie z.B. einer Gruppenverwaltung. Zielgruppe sind so kleine Firmen wie unsere, wo der Server hauptsächlich als zentraler Speicherort genutzt wird. Dafür reicht er auch völlig aus und ist leicht zu warten.

http://www.microsoft.com/germany/server/essential/sbs/editionen-ueberbl ...

Der Nutzer auf dem SBS existiert nicht als user auf dem Linux-Server. Ad gibt es wohl, aber ich nutze dies nicht.

Also im LOG steht sowas:
[2011/12/21 10:09:36.981517, 0] lib/util_sock.c:474(read_fd_with_timeout)
[2011/12/21 10:09:36.988842, 0] lib/util_sock.c:1441(get_peer_addr_internal)
getpeername failed. Error was Transport endpoint is not connected
read_fd_with_timeout: client 0.0.0.0 read error = Connection reset by peer.

Wie authentifizieren sich deine User am SAMBA?

mit Win7 erscheint bei beiden Freigaben jeweils ein Login-Dialog, bei dem ich mich mit meinem SAMBA-Account + Pwd anmelden kann. Der Samba-User existiert dann natürlich 1x im Linux-Smba und 1x auf dem SBS. Aber per Win7 oder auch Mac geht der Login ja problemlos. Nur der Win SBS schafft es nicht sich zum Linux zu verbinden bzw. erhält keinen Login-Dialog.

Pingen bzw. sehen können sich beide Server gegenseitig.

Ähm, wenn der SBS wie ein PDC arbeitet versucht er die verbindung über zwei ports (139 u. 445). Schau mal ob die frei sind oder test mal ohne fw und Poste mal deine smb.conf.

Hi,

Du hast mehrere Möglichkeiten - einmal kannst Du die AD des SBS nutzen und das Linuxteil via SMB (SAMBA) in die Windows-Domäne integrieren. Vorteil: theoretisch der eleganteste Weg. Nachteil: abängig vom release des SAMBA schwierig, zickig oder unmöglich (ich habe gerade ein LINUX-NAS in die Tonne getreten, weil es nur gezickt hat). Zum Anderen kanst Du einen Teil des Storage des Linux-Gerätes per iSCSI an den SBS binden, den Initiator dafür hat der SBS an Bord. Drittens kannst Du auf das Backup-Storage zugreifen lassen, in dem Du die Prozesse, die der SBS für den Zugriff ausführt, mit einem lokalen Benutzerkonto des Linux-Gerätes authentifizierst. Ist natürlich nicht halb so elegant wie die eine vernünftige Bindung an die Windows-Domäne.

LG, Thomas

PDC = Public Domain Controller ? Ich würde bitte dass ihr die Abkürzungen aus dem Netzwerker-Jargon bitte beim 1. Verwenden 1x ausschreibt.

Thx.

Linux: 192.168.0.2
open Ports:
139 "NETBIOS Session Service"
445 "Microsoft-DS Active Directory"

SBS: 192.168.0.3
open Ports:
139 "NETBIOS Session Service"
445 "Microsoft-DS Active Directory"

smb.conf:

# Samba config file created using SWAT
# from UNKNOWN (192.168.0.50)
# Date: 2011/11/09 15:41:40

[global]
        workgroup = POSITIV
        server string = %h server
        obey pam restrictions = Yes
        pam password change = Yes
        passwd program = /usr/bin/passwd %u
        passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
        unix password sync = Yes
        syslog = 0
        log file = /var/log/samba/log.%m
        max log size = 1000
        unix extensions = No
        dns proxy = No
        panic action = /usr/share/samba/panic-action %d
        wide links = Yes

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

[print$]
        comment = Printer Drivers
        path = /var/lib/samba/printers

[Backup]
        path = /daten/backup
        valid users = @user1
        read list = @user1
        write list = @user1
        read only = No
        acl group control = Yes
        create mask = 0740
        directory mask = 0740

Gebe ich Dir voll recht, Samba mit einer Zentralen Verwaltung zu verwenden! Glaube aber sein Grundproblem liegt in der smb.conf entweder "smbport" oder "socket options" oder „?“da die Kommunikation zwischen den beiden hängt.

"lib/util_sock.c:474(read_fd_with_timeout) / getpeername failed" : Zu denn Fehlern, ergänze deine smb.conf mit „smb port = 445“. Start den Samba neu und mach ein Verbindungsversuch, das log noch mal einsehen und nach dem anderen Fehler suchen „lib/util_sock.c:1441“. Wenn keiner mehr erscheint gut sonst dies „socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192“ in der smb.conf ergänzen. Im SWAT gibt es dafür Standartwerte die dem entsprechen sollten gemäß deiner Samba Version.

die smb.conf habe ich oben gepostet. Sieht dort denn etwas ungewöhnlich aus?

Ich hab die unter der smb.conf geantwortet.

Ah! Bisschen unübersichtlich die hier gewählte Darstellung, aber vielleicht auch eine gewöhnungssache ...
Mal schauen was du schreibst ...

Ja, Sorry. Hab direkt auf den smb.conf eintrag geantwortet.

Also ein Portscann zeigte mir, dass der Linux Samba bereits den 445 verwendet. Beißt der sich dann nicht mit dem 192.168.0.3 der ja auch diesen Port benutzt?

Dann steht in dem LOG
read_fd_with_timeout: client 0.0.0.0 read error = Connection reset by peer.
Warum ist den die IP hier 0.0.0.0 ?

Dann sagtet ihr ja dass die Ports 135 + 445 für SAMBA verwendet werden. Ist dann die Tatsache, dass der 192.168.0.2 den Port 135 als "NETBIOS" verwendet nicht falsch?

EDIT:
Ich muss mich korrigieren. Beide Server verwenden den Port 139 als "NETBIOS Sessions Service".
Scheint also zu stimmen.

Nachtrag:
der Log besagt nun:
[2011/12/21 12:40:02.711070, 0] lib/util_sock.c:474(read_fd_with_timeout)
[2011/12/21 12:40:02.711461, 0] lib/util_sock.c:1441(get_peer_addr_internal)
getpeername failed. Error was Der Socket ist nicht verbunden
read_fd_with_timeout: client 0.0.0.0 read error = Die Verbindung wurde vom Kommunikationspartner zurückgesetzt.

Okay, dann jetzt schritt für schritt alles ausschließen. Funktioniert deine Namensauflösung zwischen beiden(nmblookup und nslookup)? Leg mal dein SBS Nutzer im Samba an. Ich google jetzt mal nen bissel um weitere Ursachen für die meldungen zu finden.

EDIT:
Du schreibst älterer Debian Server! Wie alt und welche Samba Version?

Linux version 2.6.32-3-686 (Debian 2.6.32-9) (maks@debian.org) (gcc version 4.3.4 (Debian 4.3.4-8) ) #1 SMP Thu Feb 25 06:14:20 UTC 2010
samba 2:3.5.6~df

Die weiteren Schritte muss ich morgen früh angehen, denn ich habe gleich noch andere Termine. An der Stelle schonmal vielen lieben Dank für deine Unterstützung. Ich melde mich falls nicht anders möglich dann morgen früh hier wieder.

I Probiere das mal aus, den SBS gibt es als Testversion. Das interessiert mich jetzt

Jepp 60 Tage testen und man hat die Möglichkeit diesen Zeitraum 2x zu reseten (Microsoft hat eine entspr. Anleitung auf seiner Seite). Also 180 Tage testen

Hiweis: die externe IP ist mit * anonymisiert

backupserver:~# nmblookup HAL9000
querying HAL9000 on 192.168.0.255
192.168.0.3 HAL9000<00>
169.254.135.80 HAL9000<00>

backupserver:~# nslookup HAL9000
Server: 192.168.0.1
Address: 192.168.0.1#53

Non-authoritative answer:
Name: HAL9000.positiv
Address: 62.157.140.133
Name: HAL9000.positiv
Address: 80.156.*.*

Beim nslookup bin ich mir unsicher wie ich es anwenden muss.

entweder so:
backupserver:~# nslookup 192.168.0.3
Server: 192.168.0.1
Address: 192.168.0.1#53

** server can't find 3.0.168.192.in-addr.arpa.: NXDOMAIN

oder doch so:
backupserver:~# nslookup HAL9000
Server: 192.168.0.1
Address: 192.168.0.1#53

Non-authoritative answer:
Name: HAL9000.positiv
Address: 62.157.140.133
Name: HAL9000.positiv
Address: 80.156.*.*

BTW: Der SBS kann auf alle anderen Freigaben im Netz zugreifen, also auf Win und Macs.