samba + kliensek, mapelt meghajto magatol "eltunik&quot

Fórumok

samba + kliensek, mapelt meghajto magatol "eltunik&quot

Hozzászólások

Hali!
Azert irom ide, mert ubuntu van a gepen, bar szerintem nem disztro specifikus a hiba.
A helyzet: Csinaltam egy szervert kubuntuval telepitve(ez volt keznel), nincs grafikus felulet, csak konzol. Feltettem ra a samba csomagjait (3.0.14a-ubuntu) es bekonfigoltam. Eddig minden ok, mukodik is. A konfig file:
[code:1:1fdea89e04]
root@tlk-server:~# cat /etc/samba/smb.conf
#======================= Global Settings =======================
[global]
workgroup = TLK
server string = Fileserver
;
bind interfaces only = true
interfaces = eth0 10.5.29.250
hosts deny = ALL
hosts allow = 10.5.29.0/24 127.0.0.1
;
guest account = guest
map to guest = bad user
invalid users = root
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
security = user
encrypt passwords = true
socket options = TCP_NODELAY
wins support = yes
local master = yes
;
preferred master = yes
domain master = yes
;
dns proxy = no
preserve case = no
; short preserve case = yes
unix password sync = true
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
; obey pam restrictions = yes
; dos charset = CP852
; unix charset = iso8859-2
; display charset = iso8859-2
dos charset = CP1250
unix charset = CP1250
display charset = CP1250

#======================= Share Definitions =======================
[homes]
comment = Home
browseable = no
writable = yes
create mask = 0644
directory mask = 0755
[kozos]
comment = Ezt mindenki latja
path = /storage/kozos
browseable = yes
writable = yes
public = yes
create mask = 0666
directory mask = 0777
[tlk]
comment = Sajat konyvtarak
path = /storage/tlk
browseable = yes
writable = yes
public = no
create mask = 0666
directory mask = 0777
[/code:1:1fdea89e04]

A halozatban w98 es XP kliensek vannak. Vannak felhasznalok akik csak a kozos megosztast latjak, vannak akiknek van sajat useruk is. Mindket esetben jelentkezik a problema.
A gond:
Win-el csatlakoztatok egy halozati meghajtot a szerverrol, bepipalom h. csatlakoztassa ujra rebootnal stb stb. Letrejon a meghajto, monnyuk U:\ neven. Elkezdek dolgozni az U-n, monnyuk masolok. Atmegy a masolando anyag, eltelik 1-2 perc, es amikor ujra belepnek az U meghajtora, kozli a win, hogy nincs ilyen drive. Varok fel percet, ujra belepek, es siman beenged. A halozatban csak a szerver, par PC es 2 cisco switch van.
A kerdes:
Mi okozhatja, hogy a kliensek eldobjak a megosztast, aztan nemsokkal kesobb ujra tudjak hasznalni? Mit tudok tenni, hogy ne bontsa a kapcsolatot a win (mar ha win gond egyaltalan)?

Log reszletek:

[code:1:1fdea89e04]
[2006/01/18 08:43:20, 1] smbd/service.c:make_connection_snum(642)
kistotica (10.5.29.103) connect to service kozos initially as user guest (uid=1001, gid=1001) (pid 12040)
[2006/01/18 08:43:53, 0] lib/util_sock.c:read_socket_data(384)
read_socket_data: recv failure for 4. Error = Connection reset by peer
[2006/01/18 08:50:40, 1] smbd/service.c:close_cnum(830)
kistotica (10.5.29.103) closed connection to service kozos
[2006/01/18 08:57:03, 0] lib/util_sock.c:read_socket_data(384)
read_socket_data: recv failure for 4. Error = Connection reset by peer
[2006/01/18 09:14:35, 1] smbd/service.c:make_connection_snum(642)
kistotica (10.5.29.103) connect to service kozos initially as user guest (uid=1001, gid=1001) (pid 12058)
[2006/01/18 14:04:27, 0] lib/util_sock.c:read_socket_data(384)
read_socket_data: recv failure for 4. Error = Connection reset by peer
[2006/01/18 14:04:27, 1] smbd/service.c:close_cnum(830)
kistotica (10.5.29.103) closed connection to service kozos

[2006/01/17 17:41:22, 0] lib/util_sock.c:read_socket_data(384)
read_socket_data: recv failure for 4. Error = Connection reset by peer
[2006/01/17 17:55:31, 1] smbd/service.c:make_connection_snum(642)
zoli (10.5.29.15) connect to service kozos initially as user zoli (uid=1002, gid=100) (pid 11518)
[2006/01/17 17:56:41, 1] smbd/service.c:close_cnum(830)
zoli (10.5.29.15) closed connection to service kozos
[2006/01/18 07:43:02, 1] smbd/service.c:make_connection_snum(642)
zoli (10.5.29.15) connect to service kozos initially as user zoli (uid=1002, gid=100) (pid 12003)
[2006/01/18 07:57:35, 0] lib/util_sock.c:read_socket_data(384)
read_socket_data: recv failure for 4. Error = Connection reset by peer
[2006/01/18 07:57:35, 1] smbd/service.c:close_cnum(830)
zoli (10.5.29.15) closed connection to service kozos
[2006/01/18 12:02:54, 0] lib/util_sock.c:read_socket_data(384)
read_socket_data: recv failure for 4. Error = Connection reset by peer
[2006/01/18 14:42:03, 1] smbd/service.c:make_connection_snum(642)
zoli (10.5.29.15) connect to service kozos initially as user zoli (uid=1002, gid=100) (pid 12336)
[2006/01/18 14:53:10, 0] lib/util_sock.c:read_socket_data(384)
read_socket_data: recv failure for 4. Error = Connection reset by peer
[2006/01/18 14:53:10, 1] smbd/service.c:close_cnum(830)
zoli (10.5.29.15) closed connection to service kozos

[2006/01/18 12:34:15, 0] lib/util_sock.c:get_peer_addr(1150)
getpeername failed. Error was Transport endpoint is not connected
[2006/01/18 12:34:15, 0] lib/access.c:check_access(328)
[2006/01/18 12:34:15, 0] lib/util_sock.c:get_peer_addr(1150)
getpeername failed. Error was Transport endpoint is not connected
Denied connection from (0.0.0.0)
[2006/01/18 12:34:15, 1] smbd/process.c:process_smb(1084)
[2006/01/18 12:34:15, 0] lib/util_sock.c:get_peer_addr(1150)
getpeername failed. Error was Transport endpoint is not connected
Connection denied from 0.0.0.0
[2006/01/18 12:34:15, 0] lib/util_sock.c:write_socket_data(430)
write_socket_data: write failure. Error = Connection reset by peer
[2006/01/18 12:34:15, 0] lib/util_sock.c:write_socket(455)
write_socket: Error writing 5 bytes to socket 8: ERRNO = Connection reset by peer
[2006/01/18 12:34:15, 0] lib/util_sock.c:send_smb(647)
Error writing 5 bytes to client. -1. (Connection reset by peer)
[2006/01/18 12:35:06, 0] lib/util_sock.c:read_socket_data(384)
read_socket_data: recv failure for 4. Error = Connection reset by peer
[/code:1:1fdea89e04]

Nyomoztam meg egy kicsit, lehet, hogy se nem win, se nem samba gond...
Ugy nez ki, hogy lehet hogy a halokartya drivere jatszik vicceset velem:
dmesg reszlet:

[code:1:e7e162915d]
[4489005.584000] tg3: eth0: Link is down.
[4489007.475000] tg3: eth0: Link is up at 100 Mbps, full duplex.
[4489007.475000] tg3: eth0: Flow control is off for TX and off for RX.
[4489060.178000] tg3: eth0: Link is down.
[4489062.069000] tg3: eth0: Link is up at 100 Mbps, full duplex.
[4489062.069000] tg3: eth0: Flow control is off for TX and off for RX.
[/code:1:e7e162915d]

Mintha nem talalnak meg a kozos hangot a cisco swith-el...
Kiprobaltam a kovetkezo parancsokat, most varom az eredmenyt, holnapra talan lesz valami pozitivum :)

[code:1:e7e162915d]
ethtool -s eth0 autoneg off
ethtool -s eth0 speed 100 duplex full
[/code:1:e7e162915d]
Tudja valaki veletlenul, hogy modules.conf-ban hogy lehet ezeket beallitani a tg3-as driverhez? :) Full/Half duplex, 10/100/1000 Mbit ...

Kicsit felhoznám a topicot, ugyanis teljesen ugyanezzel a problémával küzdök én is!

A különbség az, hogy a javasolt megoldással nem lett semmivel sem jobb a helyzet. Egyszerűen nem bírok rájönni mi a gond.

Egyébként ez is egy Ubuntu szerver, Samba 3.2.3 verzióval. A fura az, hogy amikor nem elérhető a szerver, akkor egyszerűen az egész kliensgépet (WindowsXP) is megfogja egy pillanatra, mert nem találja a meghajtókat. A program amiben dolgozok éppen, átmenetileg lefagy! Aztán egy idő után

Ha esetleg volt valakinek hasonló tapasztalata ill. arra megoldása, akkor kérem ossza meg velem!

Előre is köszönöm!

Ez világos, csak nincsen semmi tippem, hogy mi a gond. Az érdekes, hogy a Samba kapcsolatokkal van csak ez. Pl. amikor csinálja ezt a timeout-os jelenséget a szerver, akkor ssh-val gyönyörűen tudok dolgozni, mindenféle akadozás (timeout) nélkül!!! Szóval minden jel arra mutat, hogy a Sambával van a gond még mindig. Nincs valami tipped, hogy mit lenne érdemes ezen belül vizsgálni?

Segítséged előre is köszönöm!

Szia

Nekem ezek oldottak meg:

socket options = TCP_NODELAY SO_KEEPALIVE
oplocks = no

QTGame

Sajnos negatív az eredmény. Nálam ugyanúgy csinálja ezeket a várakozásokat. És nagyon idegesítő, mert igazából addig amíg ez van, a hálózati meghajtók egyike sem érthető el! Még mindig várok esetleg valami ötletet vagy javaslatot, hogy mit kellene még megnézni. Köszi előre is!