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]
- A hozzászóláshoz be kell jelentkezni
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 ...
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
a kettő valószínüleg nem függ össze, ha nem tévedek. a timeoutod az a win "szokása" az elérhetetlen erőforrás esetén. vár, hátha elérhető lesz (tudod, mint azok, akik 25 csengés után várnak még, hátha felveszik 26.-ra...)
--
xterm
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni
ha jol emlekszem akkor nekem is ilyenek voltak ugyanilyen rendszeren es a [global]-ba kellett berakni egy "smb ports = 139" -et, azota megy minden rendben
- A hozzászóláshoz be kell jelentkezni
Ezt sajnos már beírtam. És semmi változás!
- A hozzászóláshoz be kell jelentkezni
Szia
Nekem ezek oldottak meg:
socket options = TCP_NODELAY SO_KEEPALIVE
oplocks = no
QTGame
- A hozzászóláshoz be kell jelentkezni
Megpróbálom, remélem nálam is bejönnek ezek az opciók!
- A hozzászóláshoz be kell jelentkezni
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!
- A hozzászóláshoz be kell jelentkezni