Samba könyvtár kivétel

UNIX kezdő

Sziasztok!

Egy Samba-s kérdéssel fordulnék hozzátok. Elég bonyolult feladat lenne, nem tudom képes-e rá a Samba és ha igen hogyan?

Van egy könyvtárstruktúrám:

/opt/megosztas/almappa_alap
/opt/megosztas/almappa_1/win
/opt/megosztas/almappa_2/win

Ezek közül szeretném megosztani az 1-es és 2-es almappa win könyvtárát, de azt szeretném, hogy az almappa_alap ne látszódjon és a windows-os kliensekről az alábbi útvonalon lehessen elérni:

\\server\megosztas - ebben benne lenne az 1-es és 2-es almappa

Ha a Samba-ban megosztom a "megosztas" mappát az nem jó mert látszik az "almappa_alap" is.
Veto Files-el kivételnek hozzáadhatnám, hogy ne látszódjon az a mappa de abban az esetben az 1-es és 2-es almappa tartalma teljesen látható lesz, holott én csak a win könyvtárakat szeretném megosztani.

Próbáltam úgy is, hogy szimlinket hoztam létre a win könyvtárakról, beleraktam egy mappába és azt megosztani, de nem működött a dolog.

Ez a példa most nagyon le van egyszerűsítve, csakhogy meg tudjam kérdezni van-e ilyen lehetőség a Samba-ban, egyébként elég bonyolult történet.

Ebben szeretném a segítségeteket kérni, vagy ötletet, hogyan lehetne ezt megoldani.

Köszi!

  • 3287 megtekintés

( crt | 2010. 09. 15., sze – 19:23 )

Szia.

A symlinkes megoldásnak működnie kellene. A megosztáshoz megadtad a follow symlinks = yes opciót (elméletileg default) és a unix könyvtárjogosultságok is rendben voltak?

Üdv: Zoli

Lipi

mégsem jött össze normálisan

a free parancs válasza:

total used free shared buffers cached
mem 3623168 3241652 381516 0 487308 2331908
buffers/cache 422396 3200772
swap 1951739 696 1951040

elég jól kihasználtak a mmóriák és kevéssé a swap, dehát az nem baj
gondolom én..??..

igy pontosabb
üdv Lipi

Lipi

Ha van kedvetek átnézni,abból a célból mi hiányozhat belőle, hogy a belső hálóról nem lehet a szervert ftp-ezni nagyon megköszönném. Tudom sok a kikomentezett rész benne ezért kicsit átláthatatlan, de hátha rájöttök valamire. Amugy proftp-t használok és persze van proxi is.

Üdv
Lipi

#!/bin/bash
#ADSL tuzfal v1.2

ANYWHERE="0/0"

modprobe ip_tables
modprobe ip_conntrack
modprobe ip_conntrack_ftp

iptables -F
iptables -X
iptables -Z

iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP

IFACEKULSO="eth1"
IFACEBELSO="eth0"
KULSOIP=195.199.147.65

/bin/echo "1" > /proc/sys/net/ipv4/ip_forward
#/bin/echo "1" > /proc/sys/net/ipv4/ip_always_defrag
/bin/echo "1" > /proc/sys/net/ipv4/ip_dynaddr

#LO enable
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A INPUT -i $IFACEBELSO -j ACCEPT
iptables -A OUTPUT -o $IFACEBELSO -j ACCEPT

##ICMP a belso halon
iptables -A INPUT -i $IFACEBELSO -p icmp -j ACCEPT
iptables -A OUTPUT -o $IFACEBELSO -p icmp -j ACCEPT
#iptables -A INPUT -i eth1 -p icmp -j ACCEPT
#iptables -A OUTPUT -o eth1 -p icmp -j ACCEPT

##IDENT drop
iptables -A INPUT -i $IFACEKULSO -p tcp --dport 113 -j REJECT --reject-with tcp-reset

## SSH
# Allow ssh outbound and inbound.
iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --sport 22 -m state --state NEW,ESTABLISHED -j ACCEPT

## Belülröl az FTp- nem jott ossze ha alábbit életbe lépetetem

" #iptables -A INPUT -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
#iptables -A INPUT -p tcp --sport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
#iptables -A INPUT -p tcp --dport 20 -m state --state NEW,ESTABLISHED -j ACCEPT
#iptables -A INPUT -p tcp --sport 20 -m state --state NEW,ESTABLISHED -j ACCEPT "

## WEB,POP3,SMTP,FTP bejohet
# Allow incoming HTTP and HTTPS
iptables -A INPUT -i $IFACEKULSO -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $IFACEKULSO -p tcp --dport 110 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $IFACEKULSO -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $IFACEKULSO -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $IFACEKULSO -p tcp --dport 21 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $IFACEKULSO -p tcp --dport 20 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i $IFACEKULSO -p tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT

#proba a belső- ftp-hez ekkor sem jött össze ha azalábbit beirom (a megadott ip egy proba gép)

" #iptables -A INPUT -i eth0 -s 192.168.50.77 -p tcp --dport 21 -j ACCEPT
#iptables -A INPUT -i eth0 -s 192.168.50.77 -p tcp --dport 20 -j ACCEPT "

#iptables -A OUTPUT -p TCP --dport 80 -j LOG --log-prefix HTTP-OUT:
#iptables -A INPUT -p TCP -j LOG --log-prefix HTTP-IN:
#iptables -A OUTPUT -p TCP -j LOG --log-prefix HTTP-OUT:

##ADSL szabalyok
#iptables -A INPUT -p ICMP -icmp-type echo-reply -s $ANYWHERE -i $IFACEKULSO -j ACCEPT
#iptables -A INPUT -p ICMP -icmp-type destination-unreachable -s $ANYWHERE -i $IFACEKULSO -j ACCEPT
#iptables -A INPUT -p ICMP -icmp-type time-exceeded -s $ANYWHERE -i $IFACEKULSO -j ACCEPT
#iptables -A INPUT -p ICMP -s $ANYWHERE -i $IFACEKULSO -j ACCEPT

#Samba tiltasa kifele

#iptables -A INPUT -i $IFACEKULSO -p udp --dport 137 -j LOG --log-prefix SAMBA-IN:
iptables -A INPUT -i $IFACEKULSO -p udp --dport 137 -j DROP
#iptables -A INPUT -i $IFACEKULSO -p udp --dport 138 -j LOG --log-prefix SAMBA-IN:
iptables -A INPUT -i $IFACEKULSO -p udp --dport 138 -j DROP
#iptables -A INPUT -i $IFACEKULSO -p udp --dport 139 -j LOG --log-prefix SAMBA-IN:
iptables -A INPUT -i $IFACEKULSO -p udp --dport 139 -j DROP
#iptables -A INPUT -i $IFACEKULSO -p tcp --dport 137 -j LOG --log-prefix SAMBA-IN:
iptables -A INPUT -i $IFACEKULSO -p tcp --dport 137 -j DROP
#iptables -A INPUT -i $IFACEKULSO -p tcp --dport 138 -j LOG --log-prefix SAMBA-IN:
iptables -A INPUT -i $IFACEKULSO -p tcp --dport 138 -j DROP
#iptables -A INPUT -i $IFACEKULSO -p tcp --dport 139 -j LOG --log-prefix SAMBA-IN:
iptables -A INPUT -i $IFACEKULSO -p tcp --dport 139 -j DROP
#iptables -A OUTPUT -o $IFACEKULSO -p tcp --sport 137 -j LOG --log-prefix SAMBA-OUT:
iptables -A OUTPUT -o $IFACEKULSO -p tcp --sport 137 -j DROP
#iptables -A OUTPUT -o $IFACEKULSO -p tcp --sport 138 -j LOG --log-prefix SAMBA-OUT:
iptables -A OUTPUT -o $IFACEKULSO -p tcp --sport 138 -j DROP
#iptables -A OUTPUT -o $IFACEKULSO -p tcp --sport 139 -j LOG --log-prefix SAMBA-OUT:
iptables -A OUTPUT -o $IFACEKULSO -p tcp --sport 139 -j DROP
#iptables -A OUTPUT -o $IFACEKULSO -p udp --sport 137 -j LOG --log-prefix SAMBA-OUT:
iptables -A OUTPUT -o $IFACEKULSO -p udp --sport 137 -j DROP
#iptables -A OUTPUT -o $IFACEKULSO -p udp --sport 138 -j LOG --log-prefix SAMBA-OUT:
iptables -A OUTPUT -o $IFACEKULSO -p udp --sport 138 -j DROP
#iptables -A OUTPUT -o $IFACEKULSO -p udp --sport 139 -j LOG --log-prefix SAMBA-OUT:
iptables -A OUTPUT -o $IFACEKULSO -p udp --sport 139 -j DROP

#Ifacekulson csak kifele
iptables -A INPUT -m state --state ESTABLISHED,RELATED -s $ANYWHERE -i $IFACEKULSO -j ACCEPT
iptables -A OUTPUT -d $ANYWHERE -o $IFACEKULSO -j ACCEPT

##NAT
#iptables -A FORWARD -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
#iptables -A FORWARD -p UDP -j DROP
#iptables -A INPUT -i $IFACEBELSO -j ACCEPT

iptables -A FORWARD -j ACCEPT

#iptables -A OUTPUT -j ACCEPT
#iptables -t nat -A POSTROUTING -o $IFACE -j SNAT --to 195.199.6.100
#iptables -t nat -A POSTROUTING -o $IFACE -j MASQUERADE
#iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -t nat -A POSTROUTING -o $IFACEKULSO -j SNAT --to $KULSOIP

##Squid Proxy

#iptables -t nat -A PREROUTING -i $IFACEBELSO -p tcp --dport 80 -j LOG --log-prefix PROXY!:
#iptables -t nat -A PREROUTING -i $IFACEBELSO -p tcp --dport 80 -j REDIRECT --to-port 3128
#iptables -t nat -A PREROUTING -i $IFACEBELSO -p tcp --dport 21 -j REDIRECT --to-port 2121
#iptables -t nat -A PREROUTING -i $IFACEBELSO -p tcp --dport 21 -j ACCEPT
#iptables -t nat -A PREROUTING -i $IFACEBELSO -p tcp --dport 21 -j REDIRECT --to-port 2121

## >1024 portok engedelyezese
#iptables -A INPUT -m state --state NEW,RELATED,ESTABLISHED -p tcp --dport 1025:65535 -j LOG --log-prefix "IPTABLES >1024"
iptables -A INPUT -m state --state NEW,RELATED,ESTABLISHED -p tcp --dport 1025:65535 -j ACCEPT
#iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -p tcp --dport 1025:65535 -j LOG --log-prefix "IPTABLES >1024"
iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -p tcp --dport 1025:65535 -j ACCEPT

#proba2 ftphez abelso haloval az alábbiakkal, és nem..

" #iptables -A INPUT -i eth0 -j ACCEPT
#iptables -A OUTPUT -o eth0 -j ACCEPT "

##LOG
iptables -A INPUT -p TCP -j LOG --log-prefix IPTABLES-TCP-IN:
iptables -A INPUT -p TCP -j DROP
iptables -A OUTPUT -p TCP -j LOG --log-prefix IPTABLES-TCP-OUT:
iptables -A OUTPUT -p TCP -j DROP
#iptables -A INPUT -p udp -j LOG --log-prefix UDP-IN:
#iptables -A INPUT -p udp -j DROP
#iptables -A OUTPUT -p udp -j LOG --log-prefix UDP-OUT:
#iptables -A OUTPUT -p udp -j DROP

"megörököltem egy tüzfalat"
Tűzfalnak ez elég nehezen nevezhető (iptables -A FORWARD -j ACCEPT, iptables -A INPUT -i $IFACEBELSO -j ACCEPT, iptables -A OUTPUT -o $IFACEBELSO -j ACCEPT).
Szűrés hiánya, elvi hibák és redundancia. Teljes revízióra szorulna, beleértve az általad most beleírtakat is.

Nem tisztázott, de feltételezhető, hogy a tűzfalon futó FTP szerver elérésével van problémád. A fent idézett szabályok miatt a kérdés az, hogy az FTP szerver hallgat-e azon az IP-n, amelyet a kliensben megadtál.

+1:

a koncepciót végig kell rendesen gondolni; az

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

jellegű általános mondások nélkül (elsőre nem szúrtam ki őket a listában, lehet, hogy megvoltak) esélyed nincs működő FTP szerverre; az FTP forgalmat nem tudod fix portokhoz kötni, mivel random allokál portot.

Lipi

Szeretném kérdezni, amennyiben a tüzfalat kiüritem és az alap policy ACCEPT, a tüzfal már semminek nem akadálya, gondolom a squid nem tud beleszolni hiszen nem a 3128 as portot érinti az ftp vajh mi lehet a baj, gondolom az ftp config -de annak a beáálitásai zérusak ilyen szempontból...

Üdv
Lipi

"a tüzfalat kiüritem ..., a tüzfal már semminek nem akadálya"
Az FTP szempontjából eddig sem volt akadálya, mivel eddig sem volt erre semmiféle szűrés.

"vajh mi lehet a baj, gondolom az ftp config"
Idézet magamtól: "a kérdés az, hogy az FTP szerver hallgat-e azon az IP-n, amelyet a kliensben megadtál."

"gondolom az ftp config -de annak a beáálitásai zérusak ilyen szempontból..."
Ezt nem teljesen értem. Nézd meg az FTP szerver konfigját, hogy a milyen IP-n és interfészen él.

Megjegyzés: ez a szál az FTP szerveres és tűzfalas problémával semennyire sem kapcsolódik a "Samba könyvtár kivétel" topikcímhez, célszerűbb lenne más, a témának megfelelő kategóriában folytatni.

Lipi

Köszönöm a választ stra.
Proftpd -t használok és a konfigjából nem derül ki , hogy milyen ip-en hallgat.
Valahogy én úgy képzelem, hogy ez egy folyamat, egy process amit ha elérek kivülről a küső ipcim beirásával (márpedig elérek) akkor a belső hálózaton a belső hálókártya ip cimét adom meg, hogy elérjem.
Persze probáltam már belül megadni a külső ip cimet, de hiába.

Ez igy nem helytálló?

A topic-ot áttenni valóban nem ártana, de lassan már úgyse válaszol senki, mindenki értelmesebb kérdésekhez van szokva.....vagy emberekhez...

Üdv
Lipi

mégcsak annyi, hogy miért megy az ssh belülről és az ftp nem?
érdekes , hogy ez a belső hálózatról el nem érhető ftp nem nagyon szerepel , mint google téma, - nem tudok utánanézni...

"Proftpd -t használok és a konfigjából nem derül ki , hogy milyen ip-en hallgat."
Akkor nézzük meg: 


  netstat -nltp | egrep '(:21|proftpd)'
  egrep '(ServerType|Bind|DefaultAddress|Port|VirtualHost)' /etc/proftpd.conf

Aztán meg lehet nézni, hogy milyen forgalom jön és megy a csatlakozási kísérlet alatt: 

  tcpdump -i eth0 -nvvvs 0 port 21 or icmp

közben: 

  telnet 192.168.50.xxx 21

Lipi

Nagyon köszönöm stra !!

Probáltam , de itton vagyok szóval csak a külsőt érem el, ami megy , de a köv eredmények jöttek:
a netstat -nltp | egrep '(:21 | proftpd) -re a válasz
tcp6 0 0 :::21 :::* LISTEN
3896/proftpd : (acce

netstat -nltp | egrep '(ServerType|Bind|DefaultAddress|Port|VirtualHost)' /etc/proftpd/proftpd.conf
-ra pedig a válasz
Port 21 is a standard Ftp port.

Miközben a total commanderrel létrejött az ftp kapcsolat a tcpdumppal az eth1 -et kérdezve láttam saját ipcimem és persze az eth1 -ét is.

De belülrőlcsak az eth0 lehet a nyerő, nem?
szóval nem sokat tudtam meg igaz?

Üdv
Lipi

Ebből annyit tudunk meg, a ProFTPD önállóan fut, és hogy minden IP-n elérhetőnek kellene lennie. (Az IPv6 valószínűleg az ismert netstat bug miatti fals jelzés.)

"De belülrőlcsak az eth0 lehet a nyerő, nem?"
Belülről (az eth0 felől) mind a belső, mind a külső IP-t támadva is működnie kellene, ha a tűzfalszabályok átengedik. Márpedig az előzőleg bemásolt szabályok engednék. De áttekinthetjük még egyszer:

iptables -vnL INPUT
iptables -vnL OUTPUT
iptables -t nat -vnL
iptables -t mangle -vnL

Az eth0-n lógó kliensen nincs tűzfallal tiltva az FTP?
Amikor belülről próbálod, ugye nem a proxyn keresztül? Ha mégis, akkor nézd meg anélkül, illetve a proxy beállításait és logjait is.

"csak a külsőt érem el, ami megy"
Rendben, a belső kliensről való próba lesz az érdekes.

Lipi
Végtelenül hálás vagyok, hogy foglalkozol a kérdéssel.

nem proxi keresztül probálom hanem total commanderrel, amugy a proxi configjában elvileg van acl szabály az ftp-re de az is kissé bonyolult nekem ...még a logokat megnézem...multkor leállitottam ezért a proxit is.

én is gondoltam az xp-s gépen a tüzfalra, szóval azt kikapcsoltam,

lefutattam az általad irt iptables parancsokat és én nem láttam semmi izgalmast, az eth0 minden kienged és az eth1 nél ott van a 21port ACCEPT-re állitva. (jó lett volna kimásolni, de már elfelejtettem , hogyan kell (átirányitom egy fájlba a kimenetet??)), de azt hiszem tényleg a belső próba lesz a hatásos, vagy ki tudja...

Még lehet ma irok a logokról, holnap meg a főproba..

Mégegyszer köszi stra

Lipi

Lipi

Lehet, hogy privátban kéne folytatni, de mindegy...

Szóval megnéztem a squid logot, meg az ftpd logot.
De kezdem mással.

mgprobáltam itthonról más nevében ua group-bol beftpézni, és nem mindenkivel sikerült, megnéztem a passwd-jüket -nincs különbség, hacsak a rövid 4-5 karakteres jelszavuk nem az. Ez baj, de az eddigi bajokkal nem hozható összefüggésbe. Viszont kérdezném, hogy a passwd és az ftp login hogyan feleltethetőek meg?????

Ugyanakkor a squid log ban nem láttam semmi érdekeset , persze van egy csomó TCP/MISS bejegyzés, de állitólag ez lehet csak azért mert nem szerepelt a cache-ben

Viszont ami érdekes lehet, hogy az ftpd logban találtam valamit.
Volt egy session nyitás belső ipcimről általam. De utána azt irta, hogy idézem "using sendfile capability for transmitting data" majd egy sorral lejjebb válaszként :"aborting transfer, operation not permitted" hoppá ez nem jogosultság kérdése?? Nem mert akkor kivülről sem menne...Szóval nem tom.

Üdv
Lipi

Lipi

megprobáltam belülről, a köv eredménnyel(?).

a tcpdump -i eth0 -nvvs 0 port 21 et beállitva a totalcommanderrel probálva belépni a a belső ipén (eth0=1912.168.254.254) keresztül a válasz
527072 IP (tos 0x0, ttl 128 id 6656 offset 0, flags [DF], proto TCP (6) ,length 48) 192.168.50.77.1359 > 192.168.254.254.21: S,cksum 0x9191 (correct), 4204478193:4204478193 (0) win 65535
a következő sornál változott a ttl a cksum 0xbe41 (coorect), 0:0 ack 4204478194 win 0

nem nagyon értem, de mintha az ftp a külsőn figyelne csak, mert a tcdump -eth1-et figyelve és persze átirva az ip-et a total commanderben nem történt semmi.

Lehet , hogy csak a külsőn ül az ftp és egy forward szerüség kéne a tüzfalba?

Üdv
Lipi

Lipi

megprobáltam belülről, a köv eredménnyel(?).

a tcpdump -i eth0 -nvvs 0 port 21 et beállitva a totalcommanderrel probálva belépni a a belső ipén (eth0=192.168.254.254) keresztül a válasz
527072 IP (tos 0x0, ttl 128 id 6656 offset 0, flags [DF], proto TCP (6) ,length 48) 192.168.50.77.1359 > 192.168.254.254.21: S,cksum 0x9191 (correct), 4204478193:4204478193 (0) win 65535
a következő sornál változott a ttl a cksum 0xbe41 (coorect), 0:0 ack 4204478194 win 0

nem nagyon értem, de mintha az ftp a külsőn figyelne csak, mert a tcdump -eth1-et figyelve és persze átirva az ip-et a total commanderben nem történt semmi.

Lehet , hogy csak a külsőn ül az ftp és egy forward szerüség kéne a tüzfalba?

Üdv
Lipi

Lipi

nem jelent meg minden a válaszban ezért ismétlem

megprobáltam belülről, a köv eredménnyel(?).

a tcpdump -i eth0 -nvvs 0 port 21 et beállitva a totalcommanderrel probálva belépni a a belső ipén (eth0=192.168.254.254) keresztül a válasz
527072 IP (tos 0x0, ttl 128 id 6656 offset 0, flags [DF], proto TCP (6) ,length 48) 192.168.50.77.1359 > 192.168.254.254.21: S,cksum 0x9191 (correct), 4204478193:4204478193 (0) win 65535
a következő sornál változott a ttl a cksum 0xbe41 (coorect), 0:0 ack 4204478194 win 0
nem nagyon értem, de mintha az ftp a külsőn figyelne csak, mert a tcdump -eth1-et figyelve és persze átirva az ip-et a total commanderben nem történt semmi.
Lehet , hogy csak a külsőn ül az ftp és egy forward szerüség kéne a tüzfalba?

Üdv
Lipi

Lipi
most akkor csak a kimaradó részt másolva be
nem nagyon értem, de mintha az ftp a külsőn figyelne csak, mert a tcdump -eth1-et figyelve és persze átirva az ip-et a total commanderben nem történt semmi.

Lehet , hogy csak a külsőn ül az ftp és egy forward szerüség kéne a tüzfalba?

Üdv
Lipi

Tehát tudjuk, hogy a tűzfalig elér a csomag (Syn), de visszafelé nem jön semmi (Syn-Ack). A routing rendben van? 

ip route get 192.168.50.77

illetve: 

route -n

A 192.168.50.x-es és a 192.168.254.x-es hálózat között mi van? Az a gateway mit csinál? Feltételezésem: az SSH forgalmát natolja, az FTP-t nem.

"mintha az ftp a külsőn figyelne csak, mert a tcdump -eth1-et figyelve és persze átirva az ip-et a total commanderben nem történt semmi"
Belülről indítva a kapcsolatot a gép akármelyik címére nem fog a külső interfészen megjelenni semmi, ugyanis nem megy át azon.

"hogy csak a külsőn ül az ftp és egy forward szerüség kéne a tüzfalba"
Mivel nem halad keresztül a tűzfalgépen, így a FORWARD lánc nem játszik ebben szerepet.

Lipi

Megnéztem amit kiirtam ,de még most is hiányos...holnap ujra

A dhcpd.conf részleges tartalma:
subnet 192.168.0.0
range 192.168.50.1 ....192.168.60.100

option routers 192.168.254.254

Amire tippelsz könnyen lehet igaz, hogy deritsem ki?

Nem bánnád ha inkább privátban folytatnánk?

Üdv
Lipi

Lipi

ez volt a tegnapi sor

527072 IP (tos 0x0, ttl 128 id 6656 offset 0, flags [DF], proto TCP (6) ,length 48) 192.168.50.77.1359 > 192.168.254.254.21: S,cksum 0x9191 (correct), 4204478193:4204478193 (0) win

,de ami lemaradt tegnap a fennti sor folytatásaként:

65535 < mss 1461, nop,nop,sack OK
IP (tos 0x0, ttl64, id o, offset 0, flags [DF], proto TCP(6), length 40, 192.168.254.254.21>192.168.50.77.1359:R cksum 0x666f correct, 0:0 (0) ack 1976900663 win 0

nem irtam le csak az első oda-vissza küldést a másik nagyjábol ua, esetleg az ack 1 ami változik

3 oda-vissza csomag küldés után a végeredmény:

6 packets captured
6 packets received by filter
0 packets dropped by kernel

Üdv
Lipi

Tehát resettel utasítja el, ami akár lehet amiatt is, hogy a 192.168.254.254-en nem hallgat semmi, lehet tűzfalszabály is az oka (--reject-with tcp-reset).

Fussunk neki megint: 

netstat -nlp4 | grep :21
lsof -ni TCP:21
iptables -vnL
iptables -t nat -vnL
iptables -t mangle -vnL

A logban lévő hibaüzenetnek lehet, hogy ehhez van köze.

( bterv | 2010. 09. 15., sze – 20:11 )

Igen, tényleg működik.

A follow symlinks = yes opció hiányzott az smb.conf-ból.

Nagyon szépen köszönöm a segítséget és a gyorsaságot!

( Lipiot | 2010. 09. 18., szo – 10:28 )

Lipi
Valószinüleg nem a megfelelő helyre teszem a kérdést, de nagyan belassultak a sambába beloggoló profilok. Miután már jó ideje nem találom az okát ,közzétenném a configot, hátha találtok valamit ami, nem odavaló és gyorsíthat. Hozzáteszem már nincs win2000-es gép a belső hálon csak xp.Az osztott könytárakat kihagytam..
Előre is köszönöm...

Üdv
Lipi

;
[global]
dos charset = CP852
unix charset = ISO8859-2
display charset = ISO8859-2

printing = bsd
printcap name = /etc/printcap
load printers = no
guest account = nobody
security = user

interfaces = eth0 lo
bind interfaces only = yes
netbios name = xxxxszerver
workgroup = XXXXX
domain logons = yes
logon drive = h:
logon home = \\%N\%U\.Win95Profile
logon path = \\%N\%U\.WinNTProfile
logon script = %G.bat
time server = yes

admin users = yyyy
server string = %h server (Samba %v)

syslog only = no

syslog = 0;
log level = 3

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=4096 SO_RCVBUF=4096

deadtime = 15

encrypt passwords = true

wins support = yes

os level = 255
domain master = yes
local master = yes
preferred master = yes
;WIN2000 kedveert
; use spnego = no
domain admin group = yyyy @admin @tanar
; add user script = /usr/sbin/adduser -n -g gepek -c Win2000 -d /dev/null -s /bin/false%m$
; add user script = /usr/sbin/useradd -n -g 100 -c Win2000 -d /dev/null -s /bin/false -M %u
add user script = /usr/sbin/useradd -g 1003 -c Win2000 -d /dev/null -s /bin/false -M %u

; What naming service and in what order should we use to resolve host names
; to IP addresses
name resolve order = lmhosts host wins bcast

; This will prevent nmbd to search for NetBIOS names through DNS.
dns proxy = no

; Name mangling options

# preserve case = no
# default case = lower
# short preserve case = no
preserve case = yes
default case = lower
short preserve case = yes
case sensitive = no
# veto files = /*.eml/*.nws/*.ca*/*.cd*/*.CA*/*CD.*

# Some additional character encoding related stuff
character set = ISO8859-2
client code page = 852

; This boolean parameter controlls whether Samba attempts to sync. the Unix
; password with the SMB password when the encrypted SMB password in the
; /etc/samba/smbpasswd file is changed.
unix password sync = yes

; For Unix password sync. to work on a Debian GNU/Linux system, the following
; parameters must be set (thanks to Augustin Luton
; for sending the correct chat script for
; the passwd program in Debian Potato).
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .

; The following parameter is useful only if you have the linpopup package
; installed. The samba maintainer and the linpopup maintainer are
; working to ease installation and configuration of linpopup and samba.
message command = /bin/sh -c '/usr/bin/linpopup "%f" "%m" %s; rm %s' &

; The default maximum log file size is 5 MBytes. That's too big so this
; next parameter sets it to 1 MByte. Currently, Samba rotates log
; files (/var/log/{smb,nmb} in Debian) when these files reach 1000 KBytes.
; A better solution would be to have Samba rotate the log file upon
; reception of a signal, but for now on, we have to live with this.
max log size = 1000

obey pam restrictions = yes

# Behave like DOS
dos filemode = yes
dos filetime resolution = yes
dos filetimes = yes
; mangled map = (*.html *.htm)
; username map = /etc/samba/users.map

# Cheat users to avoid hackers doing something nasty
max disk size = 3000

[homes]
comment = Home Directories
browseable = no

; By default, the home directories are exported read only. Change next
; parameter to "no" if you want to be able to write to them.
read only = no

; File creation mask is set to 0700 for security reasons. If you want to
; create files with group=rw permissions, set next parameter to 0775.
create mask = 0700

; Directory creation mask is set to 0700 for security reasons. If you want to
; create dirs. with group=rw permissions, set next parameter to 0775.
directory mask = 0700

[netlogon]
comment = Network Logon Service
path = /home/samba/netlogon
guest ok = yes
; writeable = yes
; locking = no
read only = yes
; writable = no
; share modes = no
write list = yyyy,@admin

Lipi

köszi a gyors választ.

A testparm smb.conf::

unknown parameter encountered "domain admin group"
ignoring unknown parameter " - " - "
unknown parameter encountered " character set"
ignoring unknown parameter " - " - "
unknown parameter encountered "client code page"
ignoring unknown parameter " - " - "

a többi rendben.., de ezek mért nem???

viszont találtam egy osztott könyvtárat kétszer egymás után szerepelni,

mondjuk kb igy:

kozoskonyvtar

valid users= orvosok
public=no
writeable=no
write list=@orvosok

kozoskonyvtar

public=yes
writeable=yes
#valid users= orvosok
#write list=@orvosok

a többi ismérv azonos , de most melyiket fogadja el a samba, a másodikat??
Vajon igy az orvosok, hogy látják a "kozoskonyvtar" tartalmát, mert utána csatolni kell, de lehet..

üdv
L

A character set és a client code page opciók helyett van a dos charset és unix charset, ezért azokat kommentezd ki. A domain admin group-ba szerintem csak csoport tartozhat.
Egyébként nem írtad a Samba verzióját, de a kézikönyvben ez áll:

"The domain admin group parameter has been removed in Samba-3 and should no longer be specified in smb.conf."

Ha két ugyanolyan bejegyzés van, tapasztalatom szerint az utolsót fogja használni a Samba.

De mindezektől függetlenül legelőször a rendszer (főleg io) terheltségét vizsgálnám meg, mert elképzelhető, hogy amiatt lassult be a Samba is.

Üdv: Zoli

Lipi

Köszönom Zoli,

Ha nem veszed zokon lenne még pár dolog...

A terheltségét hogy gondolod leellenőrizni??A bejelentkezőket látom ...

Más. Ékezetes neveknél gyakran ákonbákom jön a profil logon nevénél a windowsba, néha nem...Esetleg az utf-8 nem jobb választás, de akkor az unix charset és dost is át kell egyformára irni?

Ennél a "kozoskonyvtárnál" azt szeretném elérni, hogy az orvosok ide tudják betenni a más orvosoknak szánt doksikat, különböző mappákba, tehát az orvos csoportnak lenne csak publikus, és a gazdasági csopornak, Te ezt hogy bíztositanád?

Samba 3 kézikönyv merre leledzik?

Bocs a sok kérdésért,

Üdv
Lipi

samba.zip
valami miatt nem tudok vágólapra kopizni konzolból (be akartam illeszteni az én global beállításaimat), de pl. ha a testparm kimenetét fájlba irányítod és azt használod smb.conf-nak, akkor gyorsabb a hibák kigyomlálása (persze az eredetit tartsd meg, mert ha valami nem megy, össze kell majd nézni.)

[global]
<------>dos charset = CP852
<------>netbiosname = *********
<------>workgroup = *****
<------>server string = Samba %v
<------>interfaces = 192.168.***.***, 127.0.0.1
<------>client schannel = No
<------>server schannel = No
<------>log level = 1
<------>log file = /var/log/samba/%U.log
<------>max log size = 1000
<------>acl compatibility = winnt
<------>name resolve order = bcast wins lmhost hosts
<------>server signing = auto
<------>socket options = TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF=65536 SO_RCVBUF=65536
<------>hostname lookups = Yes
<------>load printers = No
<------>os level = 254
<------>domain master = No
<------>ldap replication sleep = 1
<------>ldap ssl = no
<------>panic action = /usr/share/samba/panic-action %d
<------>comment = "gépnév"
<------>allocation roundup size = 0
<------>strict locking = No

Terheltség alatt a rendszer terheltségét értettem. Nézd top-pal, iotop-pal, muninnal vagy ehhez hasonló grafikonos eszközzel.
A lassulást számos dolog okozhatja, haldokló disk, bizonyos fájlrendszerek esetén kevés lemezterület, kevés memória miatti swappelés, egyéb területen (pl. ha a levelezést is az adott szerver szolgálja ki) megnövekedett terhelés, stb.

A teljes rendszer ismerete nélkül nehéz találgatni, minden esetre a Sambán ha nincs szükség részletesebb naplózásra, akkor a log level értékét érdemes kisebbre (akár 0-ra) venni. Ha nem nagyon kicsi fájlokkal dolgoztok, akkor a SO_SNDBUF és a SO_RCVBUF értékeit lehet növelni, nálam mindkettő 32768.

Ezen kívül ha a wins már úgyis be van kapcsolva, akkor legyen inkább ez a sorrend: name resolve order = wins lmhosts hosts bcast

A közös könyvtár bejegyzése, valahogy így kellene kinézzen:

[kozoskonyvtar]
comment = Kozos konyvtar
path = /mnt/kozoskonyvtar

valid users = @orvosok, @gazdasagi
public = no
writeable = no
write list = @orvosok

Ezesetben az orvosok tudják írni, olvasni, míg a gazdasági csoport tagjai csak olvasni a megosztás tartalmát. Arra figyelj, hogy ha csoportot adsz meg a listáknál, akkor a csoport neve @-al kerződik, ezt nem tudtam eldönteni, hogy elírás volt, vagy egy felhasználód van az orvosok részére.

Samba3 dokumentációk: http://samba.org/samba/docs/

Üdv: Zoli

( vl v | 2010. 09. 19., v – 16:30 )

mount --bind
lesz a haverod.
man mount, ott le van írva, hogyan kell használni.