Hirdetés
- iPhone topik
- OnePlus 15 - van plusz energia
- Xiaomi 15T Pro - a téma nincs lezárva
- Honor Magic6 Pro - kör közepén számok
- Youtube Android alkalmazás alternatívák reklámszűréssel / videók letöltése
- Megtartotta Európában a 7500 mAh-t az Oppo
- Kijavították az iPhone Air legfőbb hibáját
- Milyen okostelefont vegyek?
- Samsung Galaxy A54 - türelemjáték
- Mobil flották
-
Mobilarena
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
janos666
nagyúr
Próba-szerencse alapú hibakeresés céljából próbáltam letiltani az összes lehetséges file/folder locking mechanizmust Samba 4.3.4-ben azzal, hogy bepakoltam ezeket az smb.conf-ba (némelyiknél már ez volt az alapértelmezés a manual szerint, de kigyűjtöttem belőle mindent, ami szóba jöhet):
kernel share modes = no
#locking = no
strict locking = no
oplocks = no
kernel oplocks = no
fake oplocks = no
blocking locks = no
level2 oplocks = no
durable handles = no
posix locking = noA locking-ot azért tettem kommentbe, mert a manual alapján a no azt eredményezi, hogy bár semmit nem lock-ol a Samba szerver, de a klienseknek azt hazudja, hogy mindent lock-olt (ami látszólag ugyan az, mint a fake oplock, csak nem a lock-olás oppurtunistic változatával). De már próbáltam ezt yes-re is állítani, az eredmény akkor is hasonló.
A testparm szerint minden OK, de aztán:
F17a_NAS ~ # smbstatus
Samba version 4.3.4
PID Username Group Machine Protocol Version
------------------------------------------------------------------------------
12759 root root 192.168.1.111 (ipv4:192.168.1.111:55744) Unknown (0x0311)
Service pid machine Connected at
-------------------------------------------------------
data 12759 192.168.1.111 Thu Feb 11 20:00:24 2016
Locked files:
Pid Uid DenyMode Access R/W Oplock SharePath Name Time
--------------------------------------------------------------------------------------------------
12759 0 DENY_NONE 0x100081 RDONLY NONE /data . Thu Feb 11 20:01:24 2016
12759 0 DENY_NONE 0x100081 RDONLY NONE /data . Thu Feb 11 20:01:49 2016
12759 0 DENY_NONE 0x100081 RDONLY NONE /data surveillance/B1 Thu Feb 11 20:01:24 2016
12759 0 DENY_NONE 0x100081 RDONLY NONE /data surveillance Thu Feb 11 20:01:24 2016
12759 0 DENY_NONE 0x100081 RDONLY NONE /data movies Thu Feb 11 20:01:49 2016Vagy a fenti smbstatus ellenére lehetséges, hogy sikerült letiltanom a lock-olást, és itt csak azt látom, hogy mit kért a kliens, sem pedig azt, hogy valójában mit tett a szerver?
Vagyis lényében a "fake" mód van érvényben és nem tudom elérni, hogy nemet merjen mondani a Samba a Windows-nak egy lock request-re? Ezt nem hajlandó elfogadni a Windows, vagy mi...?
Abból a szempontból lenne érdekes a dolog, hogy vannak olyan file-ok ezen a tárhelyen, amiket gyakorlatilag 24/7 ír folyamatosan egy folyamat a Linux-os gépen, amin a Samba is fut (pontosabban nem mindig ugyan azt a file-t írja, hanem óránként újat kezd és egy cronjob törli időnként a régebbieket, de létrehozástól lezárásig apránként növekszik egy-egy file --- valós időben stream-el videótartalom megy bele), közben pedig egy Win10-es gép is használja ezt a tárhelyet és néha egész konkrétan ezeket, az épp gyarapodó file-okat is megnyitom vele.
Az a fura, hogy azt tapasztaltam hosszabb időn át, hogy akkor kezd problémázni a kérdéses file-okat kezelő program, amikor be van kapcsolva a Windows-os gép. Például este 17-től másnap 10-ig folyamatosan sorakoznak fel azonos méretű, pontosan 1 óra anyagot tartalmazó file-ok, de 10-től, amikor aznap felébredtem és rutinból bekapcsoltam a gépet, onnantól 20-30 percenként megszakad és újraindul, rövidebbek a file-ok és így ki is maradozik pár perc (de ilyenkor általában még semmit nem csinálok vele, a kijelzőt még be sem kapcsolom határozatlan ideig, nem hogy a hálózati meghajtót tallózgatnám, főleg nem ezeket a file-okat piszkálom...). Viszont ha szándékosan megnyitom a félkész file-okat és direkt nyitva hagyom a Windows-on a mappatallózót, hogy frissítgesse a fileméretet, attól még nem lesz feltétlenül zavaros a működés, van hogy ilyenkor is egész nap zavartalanul működik, hiába babrálom kézzel is szándékosan.
Szóval nem egyértelmű az összefüggés, de mégis gyanús, hogy talán a Windows lock-ol egyet, mikor felcsatolja a hálózati meghajtót és emiatt a Linux-os program néha (még ha nem is kiszámítható módon) félbehagyja a fileműveleteit. Szóval csak teória, de szerettem volna tesztelni azzal, hogy mindenféle lock-olást letiltok. Illetve ha kiderülne, hogy tényleg van köze a lock-okhoz, akkor is próbálnék később olyan beállítást keresni, ami jól működik, de nem tiltja teljesen a lock-ot...
Új hozzászólás Aktív témák
- Eredeti Lenovo 135W töltők (sárga téglalap)
- 198 - Lenovo Legion Pro 5 (16IAX10) - Intel Core U9 275HX, RTX 5070 (FOGLALVA)
- Hp ProDesk/ EliteDesk SFF/MT G4/ G5/ G6 / i5 8-9-10.gen /Win11- Számla, garancia
- Apple iPhone 15 128GB, Kártyafüggetlen, 1 Év Garanciával
- ASTRO A50 WIRELESS HEADSET + BASE STATION 4th gen. fejhallgató
Állásajánlatok
Cég: Central PC számítógép és laptop szerviz - Pécs
Város: Pécs
Cég: Laptopműhely Bt.
Város: Budapest



