Samba szivatás

Debian GNU/Linux

Sziasztok!

A következő a problémám. Van egy szerver, amin fut egy samba, amit ugye windows-os kliensek érnek el. Rengeteg fájl van rajta és rengeteg fájlal dolgoznak, viszont van egy fájl, ami szívat. A fura, hogy csak ez az egy. Egy xls fájl, amivel először olyan gondjaim voltak, hogy ha valaki megnyitotta majd becsukta, akkor a következő user csak olvasásra tudta megnyitni. A fura, hogy nem mindig jelentkezik ez a probléma, hetente egyszer-kétszer. Még ennek a megoldására sem jöttem rá, bár annyira nem is törtem magam rajta, ha van valakinek ötlete, akkor szóljon.

A másik, ami viszont aggasztóbb számomra egy picit, hogy most azt csinálja, hogy megnyitja a user a fájlt, szerkeszti, majd ha közben még egy user megnyitja, akkor a másodiknak lesz írási joga, az elsőnek meg csak olvasási. Ugye a többi fájlnál ez úgy működik, hogy az elsőnek írási, a másodiknak meg csak olvasási, na itt pont fordítva. Ez mitől lehet? Miért csak egy fájlnál csinálja?

  • 15702 megtekintés

( vajtsz | 2012. 05. 17., cs – 18:20 )

szerintem egy smb.conf hasznos lenne...

Egyébként én a lock opciokat probalgatnam ide-oda kapcsolgatni.
Illetve boszen nezegetnem a debug logot, hasznos lehet esetleg az audit legreszletesebb logolasat bekapcsolni.

( Joke | 2012. 05. 17., cs – 19:09 )

Köszi, bekapcsolom akkor az audit logolást.

Ó mindenki jön ezzel az NT4-es baszással, de maga a file szerver része az modernnek mondható (sign&seal, smb2 is van), a login része a régi, de hát ez kit zavar? (A win7-eket by default, de szerencsére megoldható).
Amúgy a problémára, valami oplock dolog, vagy a hálókártya.

Ráadásul alkalmazástól függően tetű lassú bír lenni, 100-as hálón csücsülő szerver (100-as kártya benne) - kliens páros esetén 4-10-szer annyi ideig futott adott feladat, ha szamba volt alatta, mint amikor egy XP-ről megosztott könyvtárba voltak beleszórva az állományai. Ha kettő vagy több helyről próbálták használni, akkor szambáról gyakorlatilag használhatatlanul belassult az egész. Anno az adott helyen nem volt idő/lehetőség ötletelésre, szamba repült a ...csába, és mindenki boldog és elégedett lett.

hat ha igy lenne, akkor nem lenne az a helyzet, hogy kb. 5 eve nem hasznalok windows, a cegemnel sem, kizarolga ket gepen fut virtualizalva egy banki terminalprogram miatt.
te kulonben ilyen elvakult binugzfanboy vagy, vagy mi? igy nem tudunk erdemben beszelgetni, ha te az erzelmekkel viseltetsz egy szoftver irant...

Gigabites hálózati kártyákkal, 4 darab direktbe rákötött windowsos géppel a samba kenterbe verte az NT4 szervert sebességben, és nem (csak) fájlmásolásról volt szó. NT4 repült, és mindenki boldog és elégedett lett. És sok évvel ezelőtt, amikor még menő volt az NT4 (mielőtt valaki azzal jönne, hogy az milyen régi cucc)...

Jelen esetben 1.3-15MB-nyi(!) adatállomány kezelésébe rosált bele a szamba, és marhára nem érdekelt, hogy mitől - Az alkalmazás Windows-os kiszolgálót igényelt, aláraktam egy sima XP-s megosztást, és jó lett. A Linux meg szambástól ment a devnullba. Biztos, hogy valamit NEM tudott a szamba, amit a natív Windows-os megosztás igen, és nem az volt a feladat, hogy találjam ki, mit nem tud a szamba, és hogy lehet rávenni, hogy tudja, hanem az, hogy működő megoldás legyen a több munkaállomásos felállásra.

http://support.microsoft.com/kb/314882/hu

Megjegyzés: A Windows XP Professional rendszer egyidejűleg maximum tíz számítógép kapcsolódását engedélyezi hálózaton keresztül. A korlát az átvitelek és az erőforrásokat megosztó protokollok együttes számára vonatkozik. A Windows XP Home Edition rendszer egyidejűleg maximum öt számítógép kapcsolódását engedélyezi hálózaton keresztül. A korlát a többi számítógép azon egyidejű folyamatainak száma, amelyek fogadása a rendszer számára engedélyezve van.

Nem lehetett az olyan nagyon sok munkaállomás, a fentiek szerint... De valóban igazad van, biztosan lehet olyan alkalmazást találni, amely nem működik sambával. Viszont azt nem árt tudomásul venni, hogy a sambának rengeteg konfigurációs lehetősége van, amelyek - a véleményeddel ellentétben - meglehetősen jól dokumentáltak, és ritkán lehet megúszni egy komolyabb feladatnál az állítgatást. Persze aki ismeri a lehetőségeket, az könnyebben megtalálja a jó beállításokat, és a tapasztalat is segít. Aki pedig azt várja, hogy telepítés után azonnal úgy működjön egy szoftver, hogy maximális teljesítményt nyújtson mindenféle hangolás nélkül, az nem tudom, hogy hol él.

Három kliensről párhuzamosan futtatott alkalmazás esetén egy olyan művelet, ami Windows XP-ről megosztott adatok esetén gyakorlatilag azonnal végrehajtásra került, a szamba esetén akár percekig(!) is ott állt, aztán az alkalmazás a legtöbb esetben el is borult.

Nem azt vártam, hogy maxot nyújtson (egyszerű fájlmásolásnál azt nyújtott egyébként), hanem azt, hogy működjön, és ne 1% vagy az alatti teljesítményt mutasson, mint helyettesítő termék. Ha hangolni kell ahhoz, hogy 1% körüli szintről elmozduljon, akkor ott valami nem kerek - de nagyon nem.

ez esetben ugy tunik, a samba a szar.
erdekes, afp-vel, windows serverrel soha nem szokott nagyobb, misztikus gond lenni a filemegosztassal ill. annak sebessegevel (+hozza kapcsolodo dolgokkal, mint pl. login, directory, acl, stb.), csakis mindig a sambaval van szopas, allandoan, s melytorkosan.
a samba szar, es nem csak en mondom ezt, a szemelyeskedest meg tartsd meg a hulye haverjaidnak.

vegyél vissza, nem szeretek személyeskedni, de azért ez már felháborító. Méghogy a windowsnál nincsenek misztikus gondok? Egy sima xp/win7 közötti megosztáshoz is regedit megoldás kell, órás googlezás, stb. És ez még nem is hiba. Ha hiba van, egy értelmes log filet nem találsz, amiből kiindulj, aztán kattintgatsz a vezőrlőpultban meg a regedit {23123-2n2323-1231231231} kulcsokat szerkesztheted, amíg megőszülsz. Én nekem ez tökmindegy, mert ez a te problémád. Viszont én mindenhol sambat használok (ahol windows is van), a cégnél is van vagy 20-25 gép (Linux, Mac, Winfos) kapcsolódva, és nincs semmi különös problémánk a sambaval.

erdekes ez, de vegulis nekem mindegy.
meg ne sertodj azon hogy leszaroztam a szar samba-t.
ha az nem szamit kulonos problemanak, hogy tetulassu is raadasul, akkor nekem tok mindegy, hogy mi a helyzet nalatok.
amugy meg olvasd el a szalat a kezo kommenteel, azt irtam, hogy a samba szar - a kerdezonek valaszolva, mert milyen erdekes, szar nala a samba.

Nos lehet, hogy nála szar a samba, de korántsem biztos, hogy a samba miatt szar...

Tények:

Egyik hely: kb 100 kliens, ebből kb 15 windows már csak :)és a többi linux. Samba a közös pont, mind megosztásilag, mint hitelesítésre. Korábban inkább csak 10 linux volt és 90 win mint kliens, ezzel kb 10 éve megy hiba nélkül, átlagos felhasználás mellett, saját home-ok, meg vagy 6 különféle közös share

Másik hely, könyvvizsgáló iroda: 20 gép win, rengeteg office, excel, word, odf, stb fájl folyamatos nyűzésban. Plussz feldobva megosztásba mindenféle ős dos-os dbf temető program, cégenkét párszáz kis állománnyal (és cégből is párszáz van), roaming profil (mára gigás méretűek), stb. 10 éve gond nélkül, eddig 100-on, most már gigabiten. Ha gond lenne a sebességgel akkor a dos-os könyvelőprogram tengernyi fájlműveletén érezni lehetne szerintem...

Tehát láthatóan tud jól működni a samba. Az, hogy ott valami gond van, nem feltétlenül a sambát minősíti.
...mint ahogy az sem, hogy van akiknél szar a win kliens, nálam a legtöbb XP kliens azóta megy, mióta telepítve lett (sok éve), sosem kellett újra húzni. (igaz ennek ára van, csak user jog, frissítések, központi vírusvédelem, rendes tűzfal, stb)
Szóval ha odafigyelünk, akkor a windows is király! /itt most üzemeltetési szempontokból/

Persze szopacs mindennel van. -bőven. Sambával, windowssal és a linux desktoppal is. (hejj de még mennyi) ...ezért is mondom mostanában, hogy minden szar és szutyok, mentem volna inkább traktorosnak és zúznám a Zetorral.
...szóval vagy minden fos -ebben megállapodhatunk- vagy azért a samba ennél többet érdemel.

Rózsár Gábor (muszashi)
http://www.lok.hu

Tetűlassú. Nem tudom. Hétvégén beállítottam egy nast, Linux alapút, sima samba. Windowsos gépek 100mbyte átlag sebességgel másolnak rá, ami kb. a winyó olvasási sebességi, úgyhogy megkockáztatom, hogy a hálózat meg a szerver ennél többet is bírna. Párhuzamos használatnál kb. arányosan csökken a teljesítmény, tehát az össz teljesítmény megmarad. Lehet, hogy talán a hiba benned volt, nem a sambában... Gondolkozz el ezen, mielőtt értelmetlenül elkezded szarozni a sambat, ami még akkor sem konstruktív válasz a kérdező problémájára, ha igaz lenne.

Szimpla fájlmásolás ide-oda nem cucc. Fogj egy natív windows-os, a megosztásra támaszkodó, párhuzamosan több kliensről használható alkalmazást, és láss csodát. copy ide-oda süvített ugyanazon a megosztáson, akár mind az öt kliensről egyszerre, de ha az adott -egyébként gányláda- alkalmazást futtatták (volna) kettőnél több helyről, akkor döglés volt. Ha az adatfájlokat natív windows-os megosztásra raktam, akkor prímán lehetett használni, semmi gond nem volt. Sőt, egy klienssel is gyorsabb volt.

Igen, sajnos van, amikor a samba alapból nem jobb, mint egy XP. De sokszor jobbá lehet tenni, bár van, hogy alaposan meg kell dolgozni az eredményért. Esetleg egy sok évvel ezelőtti nyomozást érdemes lehet végigkövetni az alábbi linkről indulva:

https://groups.google.com/group/hun.lists.mlf.linux++/browse_frm/thread…

A felhasználó nem a tökörészést, az ötletelés szeretné látni, hanem használni szeretné a cuccot. Ha a csomag karbantartója minden hangolás nélkül lapátolta be a csomagba a default konfigot, és emellett a dokumentáltság is a bányászbéka alfelét távcsövön bámulja, akkor biza az a szoftver mehet a levesbe - és ment is.

Zeller, megemelem előtted a kalapom, mert - ezek szerint - neked még soha nem kellett egy szoftver konfigurálásával időt töltened, pikk-pakk működik minden, amihez hozzányúlsz.

Már megbocsáss, de az eddigiek szerint még életedben nem tudtál egy működő sambát csinálni, szarozni azonban tudod... Én több, mint 10 éve üzemeltetek samba szervereket, így valamelyest tisztában vagyok a lehetőségeivel, a problémáival, és mégsem szarozom.

Ennél szerintem lényegesen több alázattal kell(ene) egy (szabad) szoftverhez hozzáállni. Én úgy tanultam, hogy először ne más munkájában (jelen esetben a sambában), hanem a sajátomban (például a konfigurálásban) keressem a hibát.

Nem ezt mondtam, de mindegy. Az adott körülmények között a szamba egy flopi sebességét is alulmúlta a megcélzott alkalmazás alatt. Ez nagyjából annyit tesz, hogy csak és kizárólag konfigurálással kellett volna (két) nagyságrendnyi teljesítménynövekedést elérni az adott speciális esetben úgy, hogy a sima másolgatásos tesztekre nem lehetett panasz.
Nekem ebből az jött le, hogy VAN amit a szamba NEM tud, és a mezei, natív Windows-os megosztás meg igen. Ennyi.

Rohadt nagy pofáraesés az, amikor a fájlok másolgatása során mért igen jó teljesítmény után szembesítik az embert azzal, hogy igen, az lehet, hogy gyors, de amire kéne, arra használhatatlanul lassú és megbízhatatlan. Itt ugyanis ez történt.

Csak neked elő fogom keresni az adott alkalmazást meg a tesztadatokat tartalmazó mentésemet (ha még megvan valahol), és eljátszadozhatsz vele - meg egy x évvel ezelőtti szambával. Akkor is feltettem itt a kérdést, hogy mit lehetne csinálni, de értelmes válasz/ötlet nem jött, vajákos/ötletelős/próbálgatós bohóckodásra meg nem volt idő. Ha valami 1%-át tudja annak, amit elvárnak tőle, akkor nem tételezem fel róla azt, hogy csak hangolással kihozható belőle a 100%.

Egyik - általam olvasott - linuxos listán sem láttam sambás problémával kapcsolatos leveledet. A hup ezen felületét használhatatlannak tartom a kommunikációra, vagy az új hozzászólások, vagy a ki-mire-válaszolt követése roppant körülményes. Emiatt sokáig nem is regisztráltam ide, és jelenleg sem jelentkezek be rendszeresen, és nagyon ritkán szólok hozzá bármihez is. A regisztrációt is nagy mértékben pont neked köszönhetem, mert az egyik hozzászólásodra szerettem volna reagálni. Fedje jótékony homály, hogy melyik volt az a hozzászólás, és mit akartam írni :)

Most is csak azért szóltam hozzá, mert bosszantónak találtam, hogy olyanok fikázzák a sambát, akik saját bevallásuk szerint sem tudtak egy működőt csinálni.

Hiába is keresed meg azt az akármit, nem fogok időt ölni abba, hogy megpróbáljak neked bebizonyítani bármit is. Azon én már egy ideje túl vagyok, hogy bizonyítgatnom kelljen... Mondjuk nem lepődnék meg, ha kiderülne, hogy valamileyn clipperes alkalmazás volt, azokkal akadt problémája a sambának, de talán mindegyiker lehetett megoldást találni. A "bohóckodásra nem volt idő"-ről pedig engedd meg, hogy meglegyen a véleményem, és meg is tartsam magamnak.

Linux listákat nem olvasok - rengeteg zaj, nagyon sok ismétlődő kérdés, sok fölösleges lom miatt lemondtam arról, hogy a postafiókomat ezzel terheljem.

Thread-ben olvasva a hup-ot, plusz hupper extension-t használva prímán követhető, ki, mire, mikor, mit válaszolt.

Nem Clipperes alkalmazás volt - az épp prímán hasított, nem volt vele gond, sőt, a helyi (Windowsos) gépen usb-re lógatott, windows-only nyomtató is pikk-pakk működött. Mint írtam, fájlmegosztásra teljes megelégedéssel lehetett használni a szambát, viszont arra, amire használni szerették volna (alkalmazásgenerátorral összelapátolt szoftver, a fejlesztő széttárta a kezét egy worksforme-vel elintézve a dolgot) nem. Ja, és ahogy kiderült, más ügyfeleknél, más Linuxos emberkéknek sem.

Jó neked, hogy sohasem volt olyan, hogy nincs lehetőség a dolgozókat tesztelésre bent tartani munkaidő után 2-3-sok órán keresztül... Mert itt ez volt az ábra, zárás után két alkalommal volt lehetőség egy-egy órára igénybe venni két embert teszteléshez.

Szimpla file másolás (bár nem nagy cucc) hibátlanul működik. Ez a samba használatának 99%-a. (mivel szimpla file másolgatás bármi, amikor hálózati meghajtóra dolgozol). Te beleszaladtál egy speciális hibába, amilyet hálistennek még sose láttam, és nem tudtad megoldani sambával (meg sem próbáltad), hanem helyette örültél, (hogy az egyébként sok más szempontból, pl. biztonság hátrányosabb) windowsal egyből ment. Ez OK, én is használtam már microsoft wordot, ha valamit hirtelen ki kellett nyomtatni, és régi openofficeban nem jól nyílt meg. De egész hasábokon keresztül bizonygatni, hogy emiatt az egy tapasztalat miatt szar a samba, ráadásul egy olyan pimasz beszólás oldalára állni ebben a vitában, mint amit psc írt, az szerintem gáz. Főleg, mivel nem tudod alátámasztani se, fogalmad sincs mi volt a hiba, a progi nevét se írod le, akkor mi ebből a tanulság? Semmi.

Biztonság... Azért az akkori szamba és az akkori hozzáférési jogok,amiket használni lehetett, kontra egy megosztott NTFS-terület... Maradjunk annyiban, hogy ég és föld a kettő, és nem a szamba előnyére.
Igen, belefutottam valamibe, egy időkorlátos feladatba, ahol vagy tudja, vagy nem tudja az adott eszköz azt, amit elvártak tőle. Nem tudta. Elvileg az adott alkalmazás sem csinált mást, csak nyitogatta/zárogatta, olvasta meg írta a fájlokat, a szamba mégis berosált, nulla közeli I/O-val, illetve CPU-terheléssel húzva a vasat.
A program neve egyébként "air", egyedi fejlesztés, valami francia cég gusztustalan alkalmazásgányolójával lett összelapátolva.

Minthogy egy klienssel nem jött elő a lassúság (pontosabban nem volt annyira szembetűnő), és n klienssel tesztelni nem volt sok idő/lehetőség, ezért valóban nem tudom, mi volt a hiba, csak azt, hogy bizony oltárian leszerepelt a szamba, amit akkoriban egy-az-egyben alkalmasnak kiáltott ki minden szamba-hívő arra, hogy a windows-os kiszolgálókat kiváltsa. Tévedtek. Teljes kiváltásra alkalmatlan volt, és most sem bíznék rá komplett céges hálózatot.

Évek óta olvasom a postjaidat, meg egy időben az ircs beszólásaidat (nem hozzászólásaidat), talán ha 1 vagy 2 alkalommal láttalak értelmesen, érdemben megnyilvánulni, és nem pitiáner problémák miatt fikázódni. Számomra felfoghatatlan, hogy lehet ezt folyamatosan, egész életen át csinálni...

( bubor | 2012. 05. 19., szo – 11:03 )

nekem ms officeval volt valami hasonlo problemam, file jogokat varialta az office, de mar nem tudom mi volt a megoldas. Esetleg mas gyartamu officeval is problemas?

( Joke | 2012. 05. 21., h – 10:56 )

Megpróbáltatom openoffice-al is, hátha.

Hi,

Tiby esküszöm te vagy a HUP Grétsy Lászlója :). Szép magyar nyelvünket amúgy is kevesen írják (beszélik) jól, a fórumokra meg különösen jellemző a magyartalanság meg az irdatlan helyesírás. Nagy és őszinte respect, hogy udvariasan javítani próbálsz a statisztikán :)!

s

( pischta | 2012. 05. 23., sze – 10:38 )

Az első felvetésre egyszerűbb a válasz (ha ugyanaz a konkrét ok, tényleg jó lenne smb.conf hozzá).
Idézek egy részletet a SaMBa doksiból. Word-re vonatkozik, de szerintem az Excelre is igaz:
15.6.3 MS Word with Samba Changes Owner of File
Question: “When user B saves a word document that is owned by user A, the updated file is now owned by user B. Why is Samba doing this? How do I fix this?”
Answer: Word does the following when you modify/change a Word document: MS Word creates a new document with a temporary name. Word then closes the old document and deletes it, then renames the new document to the original document name. There is no mechanism by which Samba can in any way know that the new document really should be owned by the owners of the original file. Samba has no way of knowing that the file will be renamed by MS Word. As far as Samba is able to tell, the file that gets created is a new file, not one that the application (Word) is updating.
There is a workaround to solve the permissions problem. It involves understanding how you can manage file system behavior from within the smb.conf file, as well as understanding how UNIX file systems work. Set on the directory in which you are changing Word documents:
chmod g+s ‘directory name’. This ensures that all files will be created with the group that owns the directory. In smb.conf share declaration section set:

force create mode = 0660
forcedirectory mode = 0770

These two settings will ensure that all directories and files that get created in the share will be readable/writable by the owner and group set on the directory itself.

Azért merem ezt beidézni, mert nálunk is volt hasonló gond Excel fájlokkal, és Én ez alapján oldottam meg. Annyi van nálam pluszban, hogy beállítottam az inherit owner = yes-t a megosztásra. Létrehoztam egy csoportot, beállítottam könyvtáraknak ezt, és a fenti alapján a g+s-t.

[global]
workgroup = THERMPRODUCTS
server string = Samba2
log file = /var/log/samba/%m.log
max log size = 50
os level = 0
dns proxy = No
ldap ssl = no
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
create mask = 0777
directory mask = 0777
cups options = raw

inherit owner = yes
force create mode = 0660
forcedirectory mode = 0770

vfs object = recycle
recycle:repository = /mnt/sda1/lomtar/%U
recycle:keeptree = 1
recycle:touch_mtime =true
recycle:versions = 1
recycle:maxsize = 2000000000
recycle:exclude = *.tmp *.temp *.o *.obj ~$* *.mp3 *.wav
recycle:exclude_dir=*/mnt/sda1/lomtar/%U* *xx *ab

Igazából örököltem a konfigot, annyira nem is értek hozzá, csak valahogy helyre kéne pofozni.

Ez a konfigom, a te beállításaiddal kiegészítve. Most van teszt alatt, remélem működni fog. Amit még mindig nem értek, hogy miért csak egy xls fájlnál van az a probléma, hogy ha két ember megnyitja, a második kapja meg az írási jogot. A többi xls-nél jól működik, legalábbis azt mondják. Valamint az a probléma is fenn áll, hogy ha egy user megnyitja, hiába zárja be, attól még a második usernek azt írja, hogy használatban van és csak olvasásra nyithatja meg. Az igaz, hogy 25 megás a fájl, de ettől azért még nem lehetnének ilyen hibái, vagy mégis?

Az xls-t tartalmazó könyvtárat is beállítottad a leírásnak megfelelően? Ugye a server stringben lévő kettes nem a Samba verziójára utal? Elég kicsi esélyét látom, de azért gondoltam rákérdezek. A 25 megás fájlméret nem lehetne gond, nálunk 30 mega körüli fájlokat szerkesztgettek ilyen beállítás mellett.