PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Lesen von Samba



MathiasRR
23.11.03, 11:49
Hallo zusammen,

Ich habe einen PDC mit Samba 2.2.28a aufgesetzt.
Die Clients (2 x XP, 1 x NT4) können sich auch klasse auf der Domäne anmelden.
Kopieren von Dateien AUF den Samba-Server geht super (ca.500mb <1 Minute).
Aber das LESEN von Dateien dauert seeehr lange (10kb ~ 2 Minuten).

Das mii-tool meldet "eth0: 100 Mbit, full duplex, link ok".

ifconfig zeigt keinerlei Kollisionen an.
Alle Rechner sind über einen Switch angeschlossen und die Netzwerkkarten aller Rechner laufen auf 100mbit/full.

Die smb.conf habe ich aus einem HowTo welches hier vorige Tage mal gepostet wurde. Mit den socket options habe ich auch schon nen bissel experimentiert, brachte aber nicht viel.
Ich hänge die smb.conf mal hier an, vielleicht ist jemand mal so freundlich und schaut mal rein ?

Ich bin leider noch recht neu was Linux angeht, aber ich hoffe doch, dass mir jemand einen Tip gegen kann.... :p

Viele Grüße und schonmal danke für eure Mühe !

Mathias

Thomas Mitzkat
23.11.03, 12:23
log level = 2

in der global sektion meldet dir alles mögliche von samba in /var/log/samba/log.smbd

tail -f /var/log/samba/log.smbd

MathiasRR
23.11.03, 14:00
Hi Thomas,

danke für deine Mühe!

Habe mal "log Level = 2" eingefügt und den Samba-Server neu gestartet.
Aber in der log.smbd finde ich danach nicht viele Informationen:


[2003/11/23 13:39:08, 0] smbd/server.c:main(791)
smbd version 2.2.8a-SuSE started.
Copyright Andrew Tridgell and the Samba Team 1992-2002
[2003/11/23 13:39:08, 1] lib/debug.c:debug_message(258)
INFO: Debug class all level = 2 (pid 5417 from pid 5417)
[2003/11/23 13:39:08, 1] lib/debug.c:debug_message(258)
INFO: Debug class all level = 1 (pid 5417 from pid 5417)


Interessanter ist da wohl schon die log.nmbd:


[2003/11/23 13:52:17, 1] nmbd/nmbd_processlogon.c:process_logon_packet(69)
process_logon_packet: Logon from 192.168.0.205: code = 0x12
[2003/11/23 13:53:08, 0] nmbd/nmbd_incomingrequests.c:process_name_refresh_reque st(183)
process_name_refresh_request: unicast name registration request received for name KALLENHARD<00> from IP 192.168.0.205 on subnet UNICAST_SUBNET.
[2003/11/23 13:53:08, 0] nmbd/nmbd_incomingrequests.c:process_name_refresh_reque st(184)
Error - should be sent to WINS server
[2003/11/23 13:53:08, 0] nmbd/nmbd_incomingrequests.c:process_name_refresh_reque st(183)
process_name_refresh_request: unicast name registration request received for name NUERBURGRING<00> from IP 192.168.0.205 on subnet UNICAST_SUBNET.
[2003/11/23 13:53:08, 0] nmbd/nmbd_incomingrequests.c:process_name_refresh_reque st(184)
Error - should be sent to WINS server
[2003/11/23 13:53:21, 1] nmbd/nmbd_processlogon.c:process_logon_packet(69)
process_logon_packet: Logon from 192.168.0.200: code = 0x12
[2003/11/23 13:53:21, 1] nmbd/nmbd_processlogon.c:process_logon_packet(69)
process_logon_packet: Logon from 192.168.0.200: code = 0x12
[2003/11/23 13:55:48, 0] nmbd/nmbd_incomingrequests.c:process_name_refresh_reque st(183)
process_name_refresh_request: unicast name registration request received for name BREIDSCHEID<00> from IP 192.168.0.204 on subnet UNICAST_SUBNET.
[2003/11/23 13:55:48, 0] nmbd/nmbd_incomingrequests.c:process_name_refresh_reque st(184)
Error - should be sent to WINS server
[2003/11/23 13:55:48, 0] nmbd/nmbd_incomingrequests.c:process_name_refresh_reque st(183)
process_name_refresh_request: unicast name registration request received for name DOM-OMEGA<00> from IP 192.168.0.204 on subnet UNICAST_SUBNET.
[2003/11/23 13:55:48, 0] nmbd/nmbd_incomingrequests.c:process_name_refresh_reque st(184)
Error - should be sent to WINS server


Aber die dort angegebenen Einträge sagen mit als Newbie leider nicht viel....

Gruß
Mathias

Thomas Mitzkat
23.11.03, 14:17
weniger ist mehr, darum habe ich mal deine smb.conf zusammengestrichen. die meisten voreinstellungen, die man mit "testparm" auch angezeigt bekommt, decken das größte spektrum ab:


# Samba config file created using SWAT
# from localhost (127.0.0.1)
# Date: 2003/11/21 21:07:48

# Global parameters
[global]
workgroup = NUERBURGRING
netbios name = NORDSCHLEIFE
server string = SambaPDC
interfaces = eth0
bind interfaces only = yes

os level = 65
log level = 2
security = user
encrypt passwords = yes
update encrypted = yes
wins support = yes

socket options = SO_KEEPALIVE IPTOS_LOWDELAY TCP_NODELAY
# socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
character set = ISO8859-15

printing = cups
load printers = yes
printer admin = @users

time server = yes
add user script = /usr/sbin/useradd -c Machine -d /dev/null -s /bin/false %m$
veto files = /*.eml/*.nws/riched20.dll/*.{*}/

domain master = yes
domain logons = yes
logon drive = H:
logon script = %U.bat

[printers]
comment = All Printers
path = /var/tmp
create mask = 0600
printable = Yes
browseable = No
print command = lpr-cups -P %p -o raw %s -r # using client side printer drivers.

[print$]
comment = Printer Drivers
path = /var/lib/samba/drivers
write list = @ntadmin root
force group = ntadmin
create mask = 0664
directory mask = 0775

[homes]
comment = Benutzer-Verzeichnis
browseable = no
writeable = yes
create mask = 0640
directory mask = 0750

[netlogon]
path = /daten/pdc
comment = Login-Scripte
browseable = no
writeable = yes

[alle]
path = /daten/alle
comment = Daten fuer alle User
browseable = no
writeable = yes

[install]
path = /daten/install
comment = Installationsverzeichnis Software
browseable = no
writeable = yes


außerdem würde ich prüfen, ob alle netzwerkangaben bei den klienten stimmen, vor allem der domainname:
KALLENHARD<00> from IP 192.168.0.205 on subnet UNICAST_SUBNET.

MathiasRR
23.11.03, 14:50
Hallo Thomas,

nochmals Danke für deine Mühe und die Überarbeitung der smb.conf.
Habe lediglich den Pfad zu den Home-Laufwerken angepasst, da die Homes der Samba-User nicht gleich der Homes des Linux-Systems sein sollen.

Leider hat sich nach einem Neustart des Samba-Servers mittels rcsmb stop und rcsmb start auch nichts in Sachen Geschwindigkeit des Lesezugriffs geändert.
Ist immernoch gähnend langsam und die Windows-Clients brechen zum Teil nach einer Weile beim Kopieren einfach ab.....:(


Original geschrieben von Thomas Mitzkat
außerdem würde ich prüfen, ob alle netzwerkangaben bei den klienten stimmen, vor allem der domainname:
KALLENHARD<00> from IP 192.168.0.205 on subnet UNICAST_SUBNET.

"Kallenhard" ist der Name es Clients mit dem ich derzeit das Kopieren, also die Netzwerkzugriffe, teste. Die IP-Adresse des Rechners ist OK. Was "UNICAST_SUBNET" bedeutet, weiss ich leider auch nicht.
Normal hängen die Clients in einer NT4.0-Domäne, die ich gerne durch den Samba-Server nach und nach ablösen möchte. In der reinen NT-Domäne funktionieren die Clients 1A und machen dort keine Probleme....

Um in die Samba-Domäne zu wechseln, habe ich die Clients nur umgemeldet und die Sache mit der Verschlüsselung der Kenntwörter geändert. Weiterhin habe ich hier irgendwo was davon gelesen, dass man den Dienst des WebBrowsers unter XP abschalten solle. Habe ich dann auch gemacht. Aber an der Netzwerkkonfig habe ich bei den Clients nichts geändert...

Hast du, oder sonst jemand, noch eine Idee, was ich falsch gemach habe, dass die Lesezugriffe so langsam sind ?

Gruß
Mathias

steve-bracket
23.11.03, 15:20
Nur so nebenbei, du betonst, dass alle NIC's auf Fullduplex laufen.
Hast du das händisch geändert???

Gruß

MathiasRR
23.11.03, 15:32
Hi Steve,

hatte es Probeweise mal geändert, aber ansonsten zeigt mir auch mein Switch an ob die NIC's auf Full oder Halfe-Duplex laufen...

Gruß
Mathias

steve-bracket
23.11.03, 15:37
Also läuft Autosensing oder nicht??????
Würde an diesen Einstellungen nichts ändern, die Devices wissen schon ob Full bzw. Half-Duplex.
(Da gibt's oft Überraschungen)

Gruß

MathiasRR
23.11.03, 15:58
Hi Steve,


Original geschrieben von steve-bracket
Also läuft Autosensing oder nicht??????

Nachdem ich den Fehler zuerst hier gesucht hatte, habe ich die Karte(n) wieder auf Autosensing gestellt.
Daran wird es also wohl leider nicht liegen.
Wie aber auch schon geschrieben, wenn die Clients sich mit einem NT4.0 PDC verbinden, dann läuft alles 1a schnell.....
Daher würde ich erstmal das Netzwerk selbst ausschliessen.
Als mögliche Fehlerquellen sehe ich eigendlich nur die Konfiguration der Netzwerkumgebung auf den Clients (aber eher unwahrscheinlich da es unter NT läuft, also nur falls MS mir da einen Fehler verzeihen würde), oder aber die Konfiguration des Linux-PDC's mit Samba.
Wobei hier die Hardware wohl ausreicht (AthlonXP2200 mit 512MB Ram), und ansonsten halt SuSE 9.0 mit Samba 2.2.28a.

Gruß
Mathias

MathiasRR
25.11.03, 17:27
Hallo zusammen,

ich wollte mich nochmal bei allen die sich mein Problem angeschaut haben bedanken und denen die vielleicht ein ähnliches Phänomen ereilt die Lösung präsentieren, denn ich habe den Fehler nun doch gefunden:

Durch googlen bin ich auf einen Beitrag in einem anderen Forum gestossen, wo jemand ein ähnliches Problem hatte. Auch er hatte ein Systemboard von ASRock verwendet wie ich.
Laut seiner Auskunft lag der Fehler am OnBoard-LAN.
Ein Anruf bei meinem Hardwarehändler bestätigte das ebenfalls (soll wohl schon öfters vorgekommen sein).
Somit habe ich das Board umgetauscht (jetzt Asus), aber da dort ein nVIDIA-Chip verbaut ist, eine zusätzliche RelTec Netzwerkkarte eingebaut (kostet ja nur ca. 8 ?).

Jetzt rennt das System super und sowohl Schreiben als auch Lesen vom Samba-Server funktioniert einwandfrei! :D

Gruß
Mathias

mamue
25.11.03, 17:59
Super, der nächste, bei dem es die Hardware war.
Ich glaube, das waren bisher fünf Fälle. In 100% der Fälle war es nicht samba.
Leider ist so etwas von aussen immer extrem schwer zu erkennen. Das klappt nur, wenn man mit einem Schraubenzieher bewaffnet direkt vor der betroffenen Kiste sitzt.

Erfreulich, dass Du Rückmeldung gegeben hast,
mamue

MathiasRR
25.11.03, 19:19
Hi,


Original geschrieben von mamue
Super, der nächste, bei dem es die Hardware war.
Ich glaube, das waren bisher fünf Fälle. In 100% der Fälle war es nicht samba.
Leider ist so etwas von aussen immer extrem schwer zu erkennen. Das klappt nur, wenn man mit einem Schraubenzieher bewaffnet direkt vor der betroffenen Kiste sitzt.

Tjo, zumal mit das mii-tool keine Fehler, ifconfig keine Kollisionen und mein Switch auch keine Probleme angezeigt hat.
Sollte man sich also besser im Extremfall nicht drauf verlassen. ;)


Erfreulich, dass Du Rückmeldung gegeben hast,
mamue

Kein Problem, vielleicht hilft es dem einen oder anderen User der mal ähliche Probleme hat.

Gruß
Mathias

Sebastian Henrich
29.11.03, 01:44
Ich kann dieses Hardware-Probleme nur bestätigen. Ich hatte schon mit diversen Netwerkkarten (TULIP Chip, alte Revisionen des Realtek 8139, auch eine 3com) die diese Fehler hatten. Ein einfacher Test ist, mal ein ISO Image mit NFS oder FTP zu kopieren. Ist dies auch gähnend langsam, dann liegt es an der Netzwerkkarte bzw. an dem Zusammenspiel Netzwerkkarte und Treibermodul. Eine andere möglichkeit ist, wenn sich zum Beispiel der RAID-Controller und die Netzwerkkarte den IRQ teilen.

Gruß

Sebastian

MathiasRR
29.11.03, 06:20
Hallo Sebastian,


Original geschrieben von Sebastian Henrich
Eine andere möglichkeit ist, wenn sich zum Beispiel der RAID-Controller und die Netzwerkkarte den IRQ teilen.

Das hatte ich in der Tat damals nicht mehr ausprobiert.
Nun ja, jetzt ist ja nen anderes Board drinne und es löppt.
Aber vielleicht trotzdem mal interessant für die User denen mal ein Ähnliches Problem begegnet....;)

Gruß
Mathias

kane32
29.11.03, 10:14
Durch googlen bin ich auf einen Beitrag in einem anderen Forum gestossen, wo jemand ein ähnliches Problem hatte. Auch er hatte ein Systemboard von ASRock verwendet wie ich.
Laut seiner Auskunft lag der Fehler am OnBoard-LAN.
Ein Anruf bei meinem Hardwarehändler bestätigte das ebenfalls (soll wohl schon öfters vorgekommen sein).
Somit habe ich das Board umgetauscht (jetzt Asus), aber da dort ein nVIDIA-Chip verbaut ist, eine zusätzliche RelTec Netzwerkkarte eingebaut (kostet ja nur ca. 8 ?).

Dasselbe Problem hatte ich vor einiger Zeit auch :)
Schreiben superschnell, lesen derbe langsam.
Ich habe ebenfalls ein AsRock mainboard. Nachdem ich mir dann aber für 3€ bei ebay eine andere karte gekauft habe, hat wieder alles wie am schnürchen funktioniert.
Die Onboard-NICs von Asrock sind wohl nicht so das wahre...