Könyörgöm valaki, segítsen már, mert rövidesen elmegyek kertésznek... :(
Gondolom, minden létező beállítást megtettem az elérés megteremtéséhez. (a korábbi Win verzióknál így működött.) A szükséges támogató szervizek futnak, Homegroup - jelszó, magánhálózati beállítás, NETBIOS beállítva, SMB1-2-3 beállítva. "Workgroup" a hálózatazonosítás módszereként szintén. Speciális megosztásoknál a "Hálózatfelderítés" minden szinten engedélyezve, 40-bit szintén. (Kell néhény korábbi hálós eszköz (RAID) eléréséhez.) A tűzfalon külön a TCP-re UDP-re a szokásos 137,138 - 139,445 engedélyezve az szubháló IP tartományában. De kikapcsolva a tűzfalat ugyanúgy nem megy. Hálózati eszköz-"reset" egy boot-ra megoldja, azután eltűnik a tallózhatók közül és kezdődik minden előről.
(Hozzáteszem, nem lekesedem cortana-kért, és más store-os appok internetelérését is tiltani szoktam a tűzfalon.)
A gépek egy része még mindig tallózható és tallózni is lehet róluk. Mindegyik 1709-es Windows-t futtat,
és nem tudok beállítási különbözőségekről. A probléma az 1703-as után jelentkezett a gépek kisebb részénél, a 1709-es frissítés után meg már nagyobb részénél is. Beállítom, működik szépen, majd következő napon v. bekapcsolás után már sehogyan sem. Abból már lehet látni a "bajt", hogy a hálózaton eltűnik a saját "gép-megosztás" ikonja is.
A baj az, hogy a fórumok ilyen jellegű panaszaira, "regiment" különféle megoldást adnak. De nálam bár sokat kipróbáltam a logikusak közül, de egy sem működött hosszabb ideig. Olvasni is olvastam már "rendesen" a témában, végleges megoldást azonban nem tudtam "szülni" eddig.
(Kínomban az jutott eszembe: Egy oprendszer hogyan "küzdhet" ennyire a hálózati megosztások elérése ellen? - Felcsatolva persze elérhető lenne minden gép, - természetesen pingelhetők is, - de kívánalom a tallózhatóság...
Miért nem lehet ezt az MS-nek, majd 20 év fejlesztőmunka után korrekten, pár kattintásra stabilan megoldani, ahogyan ez korábban leginkább W7-nél,- még működött, de még az 1511 1607 esetén sem volt vele különösebb problémám?)
(Tudom én nem veszek figyelembe valamilyen változást, a policy-s restrikciók függőségei bezavarhatnak, amiről lehet, jelenleg fogalmam sincs.., egy végre működő ötlet kellene, mi az ami rövid működés után következetesen magától letílthatja az elérést -- Persze nem látva a "panelokat" nem könnyű, tudom..)
Hozzászólások
Netbios over tcpip engedélyezve, keeresés lmhosts segítségével letiltva? Jelölj ki egy always-on master browsert, a többi gépen tiltsd le a registryben, hogy master browserré választhatók lehessenek. Ellenőrzés a nbtstat -a paranccsal.
"lmhosts segítségével letiltva" - és a megelőző Win verzióknál ez miért nem "játszott"? - Meg fogom nézni mi a helyzet, - de ez alapértelmezetten van hagyva, nem piszkáltam soha. (Ha rendesen vírusos egy gép, csak akkor szoktam megnézni, esetleg mit műveltek vele..)
A Win 10-nél, miközben a "homegroup" protokoll rendelkezésre áll, és korábban tette is a dolgát..? "Masterbrowser" registry-vel utoljára az XP-nél foglalkoztam.. De hétvégén ezt is beállítom a Win 10-nél ha lehet, egye fene. Egyébként meg mindig adott sorrendben indulnak a gépek, mindig ugyanaz az első W10 is a hálózaton. - Nincsen keverve soha. (Baj csak az ebben, hogy a Win verziófrissítésnél a fele gépen eltűnik a beállítás, a másik felénél megmarad, csak azt nem lehet tudni melyik másiknál.)
(Szinte tiszta W10-1709-es a hálózat, pár W7-es van, azokkal nincs is semmi gond, mindig tallózhatók is. Pár NAS van a rendszerben, amelyek persze nem..., - az is a W10 bűne egyébként, 1511-esnél még megvoltak azok is.)
Tehát a lényege a véleményednek, hogy hiába a magasabb generációs hálózati protokol, használjuk a Worgroup-ét?
Homegroup nem világos, hogy mire jó. Én csak workgroup-ot állítottam be, úgy tűnik, hogy udp 137 és 138 és tcp 445 egyaránt kell. Én úgy tudtam rendberakni, hogy minden gépen beállítottam, hogy ne lehessen Master Browser, kivéve a NAS-on.
Köszönöm a tippet, meg fogom próbálni alkalmazni, majd megírom itt mire jutottam. (Már valamelyik angolnyelvű fórumban korábban olvastam egy hozzászólásként, de egyszerűen nem hittem el, hogy az MS ennyi fejlesztés után "visszakanyarodik" az 1709-es! esetében a WinXP hálózat-kezeléséhez. :) Ráadásul úgy, hogy még azt sem tartja belőle tiszteletben, hogy amelyik elsőként indul egy adott verzióhierarchiában, biztosan az az MB. - Furcsa dolgok ezek.
A Master Browser cserének csak időszakos tallózási gondot szabadna egyébként okoznia - várni kell kicsit a Hálózat megnyitása után, hogy minden gép megjelenjen. Szóval szerintem nem ott kell kutatni, hogy a MB ne változzon.
De ha akár egy NAS is van a hálózatban, amin valami kurrens Samba fut, akkor azon a WINS bekapcsolása (webről vagy CLI-ből) és a NAS ilyen célú használata akár meg is oldhatja ezt a problémát.
Viszont a Homegroup bekapcsolása nekem még soha sehol nem segített, sőt. Csak a baj volt utána mindenféle hálózati eléréssel, megosztással (elsősorban nem Windows-Windows, hanem Windows-Samba hozzáféréssel kapcsolatban futottam bele, hogy "ja, Homegroup van, akkor ki kell kapcsolni"). Bevallom, sohasem néztem utána, hogy mit nyújtana vagy mit egyszerűsítene a Homegroup az addig jól bevált Workgroup-hoz képest. De nem is érzek motivációt, mert a Workgroup mindent tud, ami kell egy kis hálózatban - legalábbis szerintem.
Miért nem lehet ezt az MS-nek, majd 20 év fejlesztőmunka után korrekten, pár kattintásra stabilan megoldani
https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/
Mert nem AKARJA, hogy ezt használd!
Fogd már fel, hogy a feature-t, amit szeretnél, a Microsoft irtja kifele a picsába.
Ez csak az SMB 1-es verziójára vonatkozik. A fájl- és nyomtatómegosztás ettől függetlenül továbbra is támogatott, NetBIOS (és NetBT), SMB2/3, CIFS ezek továbbra is léteznek. Én némelyik gépemen letiltottam az SMB1-et, másokon nem, vegyes környezet (WinXP/7/10, Android, Linux) és minden megosztás böngészhető. Sokat szívtam vele, és végül a master browser dolog segített (kijelöltem a NAS-t illetve kizártam minden mást).
PERSZE MEGÉRTEM! Az SMB1-es ransomware-os támadás miatt hirtelen felébredt valaki az MS-nél, hogy a hálózatok biztonsági kockázata az "égbe" ment, most javítani kéne a protokolt. Végül is ki használja leginkább? - Kedves, szegényebb keleteurópai, ázsiai országokban. Á, dehogy, javítjuk, minek? A szőnyeget sokkal egyszerűbb kihúzni a hálózatok alól, majd mindenki lecseréli az eszközeit.
Csinálunk egy kis forgalmat. (Nehogy má valaki Win10-es hálózatban WinXP-t futtasson...) Bár vannak komoly drága digitális nyomdagépek igaz lehet 15 évesek is, de minek azoknak hálózati kapcsolat.
Erre én azt mondom, kompatibilitás a véksőkig. - Milliók kívánják használni a protokolt. (Emlékezzünk Linusra, amikor a kernelből el kellett volna távolítani egy elavult eszközmeghajktót, körbekérdezett használja e valaki, és mivel volt valaki, aki használta, ezért benne hagyta...)
(Ez a hozzáállás nekem sokkal szimpatikusabb. Mint az, hogy emberek sokan napokat kíséleteznek, szétguglizzák a fejüket, hogy egy tegnap még működő szolgáltatást valahogyan visszavarázsoljanak. Mert vannak munkatársaik akik emiatt nem tudnak dolgozni normálisan. Egy cég egy projekt véghajrájában elveszíti a hálózatának felét. - Ja nagyon vicces dolog. - (Egy hivatalos frissítés után, mert javítás, patch-elés címén gyakorlatilag megszüntettek egy winnes szerviz korrekt működésének lehetőségét.)
Na, ha valami aljas dolog akkor ez az. (Tovább megyek, a protokoll kikapcsolását úgy oldották meg, hogy ha egy rendszergazda rájönne és visszaállítaná, az ütemezőben ott figyel két "uninstall processz" és 15 napon belül ismét kiüti az SMB1-et.)
Gratula MS! Biztosra veszem, jó út ez a Windows 10 felhasználóinak csökkentésére. (...Ezt nem egy könnyen felejtem el nekik én sem...)
Tegyem hozzá. - Ez megnyitja a precedenst, hogy javítás címén bármilyen eszköz használatát tollvonással megszüntessék. A Win 10 és a fejlesztői lassan hitleri szinten döntenek élet és eszközhalál kérdéséről, diktatórikusan. Ahelyett, hogy a felhasználókért alázatosan dolgoznának, ahogyan teszi ezt mindenki a világon akinek ügyfelei vannak. (Nem lehetnek kétségeink, az MB működését továbbra is, újabb "javítások" fogják korlátozni.., biztosra veszem.)
A válasz egy lehet, kiüti az ember a WU szervizet. Biztosan javulni fog ezáltal majd a hálózatok biztonsága...
Sub, én is szenvedek ugyanezzel a problémával, egyelőre nem találtam megoldást. Egyértelműen a frissített Win10 törte el a hálózati tallózást, ráadásul egyéb furcsaság is keletkezett, pl ip-cím-formában nem lehet hálózati meghajtót csatolni, csak gépnévvel.
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Követem, nálam is van egy ilyen gép.
Odáig már eljutottam, hogy kiderült, átállt publikus hálózatra a hálózati beállítás.
Ha visszaállítom Privátra, látszik a gép tallózáskor, de a megosztás még most se.
Orwell az 1984-et regénynek írta és nem használati utasításnak!
Sajnos egyes gépeken megszünt a stabil tallózó szerviz (Browser) Ha futtatod a "tasklist /svc"-t akkor pl. nálam nincs "svchost.exe"-n keresztül futó "xxxx Browser" szolgáltatás. Ezt vissza tudom hozni, de csak időlegesen, mert pár "boot" után ismét eltűnik. A W10 hálózati reset kapcsolója is megoldja, de az is a NETBIOS viszzakapcsolása után ismét elszáll.
"net stop browser" "net start browser" is segíthet, valamint ez is..
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\Browser /v SvcHostSplitDisable /t REG_DWORD /d 1 /f
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer /v SvcHostSplitDisable /t REG_DWORD /d 1 /f
valahogyan így kéne kinéznie a "tasklist" paranccsal korrekt esetben..
"svchost.exe xxxx Browser, LanmanServer"
(Nem tudom egyes gépeken stabillá tenni, még másoknál ez adott, működnek... Nem tudom, az MS patch tulajdonképpen hogyan működhet ilyen esetlegesen különböző gépeken...)
Sajnos ez nekem semmit nem segített. A helyzet változatlanul rossz.
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
A homegroup meg fog szunni.
A véleményem az, hogy akkor lehet valamit megszüntetni, ha helyette van más működő megoldás, és ezt egyszerűen, ahogyan Winnes körökben szokás, be is lehet állítani. A tallózás olyan igény a felhasználóknál, mint a "Startmenű". Pont.
Tiszteletben tartom a velemenyedet, de a homegroup akkor is meg fog szunni. Deal with it.
http://news.thewindowsclub.com/microsoft-retires-homegroup-feature-perm…
https://blogs.windows.com/windowsexperience/2017/12/19/announcing-windo…
https://www.microsoft.com/en-us/windows/Windows-10-specifications#featu…
"Homegroup requires IPv6 to work" - valami XML meg SOAP kell hozzá, brrr.
Homegroup megszűnik (engem nem érdekel), workgroup marad. Samba a workgroup-pal tud együttműködni.
Egyébként a W7-esek és a korábbi, (1607) verziójú 10-esek jól működtek együtt nálunk az alap "Homegroup" beállításokkal is. (Nem kellett "keresni" az smb1-et, MB-t a hálózat tallózható működéséhez.)
Olvastam róla korábban, ez is csak a tervszerűtlen, előre nem tekintő fejlesztés bizonyítéka az MS-nél.
+ elpocsékolt fejlesztői erőforrások.
És mi köze a tallózásnak a homegrouphoz?
A homegroup mindig is szar volt. Helyette évtizedek óta működik a workgroup/domain üzemmód. Attól még, hogy a homegroup (végre) megszűnik, attól még tallózás és workgroup/domain ugyanúgy megmarad.
Az smb1-et meg aztán végképp hülyeség idekeverni, semmi köze a browsinghoz.
Az smb1-nek annyiban van köze, hogy legtöbb céges hálózatban lehetnek még szintén tallózandó ilyen protokolt tudó eszközök is. Persze, ha smb3.2-vel és 128-bit-en tallózhatók a konkrét hálózatba kötött eszközök, természetesen az is megfelelne. :)
A baj csak az, hogy akkor minden eszköznek a legfejlettebbnek kell lennie. Mai magyar kkv-s, kft-s céges környezetben, szerintem ez életszerűtlen. (Ez az MS fejlesztőinek sara, mindenki azért kapcsolt "lejjebb-vissza" a titkosítás szintjéből, mert nem érte el ezeket, - magyarán a "kompatibilitás mint fejlesztői szempont" hiánya miatt.)
Utoljára a hálózat és a Windows 10-es akkor volt a legjobb, amikor egy év javítgatás után az 1511-es verziót lecserélték. Akkor a gépek-oprendszerek még gyorsak is voltak. (Ma meg ugyanazon a gépen az 1709-es csak vánszorog SSD-ről, - szerintem oprendszerfejlesztői szégyen egy 3,6 GHz-s Xeon proci és 16GB RAM mellett.)
"ugyanazon a gépen az 1709-es csak vánszorog SSD-ről"
Szerintem meg valamit rosszul csinálsz. 1709-en dolgozok, pattognak az ablakok, gyors az IO, semmi baja nincs. Usereimtől se hallottam panaszt, hogy bármi lelassult volna, pedig ők is 1511-től használják és végigment rajtuk az összes upgrade.
És meglepő módon a hálózatnak sincs semmi baja. Egyetlen dolgot említettek amikor w7-ről w10-re álltunk át, hogy felgyorsult a hálózat. Ugye smb v2 -> v3 váltás...
Lehet valamit rosszul csinálni, amikor a rendszer a frissítésekkel önálló életet él? - Egyébként meg nyilván nem ugyanaz a felhasználás módja, mint a Tiéd, a gépek sem azonosak..
Ha "gugliba" beírod a eltűnő megosztásokkal kapcsolatos szófordulatokat, akkor az a helyzet, hogy nagyon sokan rosszul csinálnak valamit ezen a bolygón..
"Disappearing share Windows 10 1709" keresésre csak: About 109,000 results - 0.46 seconds) pedig ez csak egy kifejezetten rossz általános rákeresés)
"PC Slow After Windows 10 Fall Creators Update" valamivel jobban meghatározott keresésre csak: About 846,000 results (0.48 seconds)
"Cannot Access Network Shares after Update 1709" keresésre csak: About 482,000 results (0.51 seconds)
Vajon én is csinálhatok valamit rosszul? Hát persze,.. 15 éve rosszul csinálok "valamit" és a mellete van pár munkatársam akiket sajnálnom kell a Windows-ok általam okozott hibái miatt. - Vicces vagy.
Nálunk egyébként a hálózat sebességével soha nem volt baj, most egyes gépek eltűnnek a megosztásból ennyi a problémánk. De másoknak is van hasonló, jeleztek itt még páran.
Jaj hagyjuk már ezt a gugli találatok számát. Szarul vagy egyáltalán nem működő linuxokról rakjak ide milliós guglitalálatokat? Akkor biztos szar a linux.
Az eltűnő gépekre már tegnap is irtam, hogy egy depreciated protokoll-t használsz, felejtsd el a homegroup-ot, sokéve nem ajánlott a használata, évtizedek óta van jól működő megoldás a problémádra. (na jó az évtizedek talán túlzás, ha valami igazán bugos volt, akkor az a 2000-xp -s browsing és vista óta lett normális alapokra helyezve)
Félre ne értsd. Nincs nagy arcom a témában, - nem is lehet szerintem egyikünknek sem, - mert olyan nagyon gyorsan változik a rendszer, amelyet kontroll alatt akarunk tartani, hogy ha az egész napot dokumentációk, fórumok olvasásával tölthetném akkor is lenne fontos info ami kimaradna, és máris "rés a pajzson" azaz a rendszergazda tudásán. Ami természetesen tovább gyűrűzik az általa fenntartott rendszer felé is. A Win 10 óta tízszer annyi időt töltök netes olvasásokkal, mégsem lehetek mindig tökéletesen biztos a tudásomban. (Na ez a mosakodás része.., :)
A különböző protokollok a Windows verziók fügvényében vesznek rész a hálózati kommunikációban, elvileg ha magasabb rendűek találkoznak, akkor azok magasabb titkosítási szinten elérhetik egymást. Ezt ugye semmilyen módon nem korlátozzuk. A rendszerben mehet a 2-es 3-as SMB is. A lényeg a gépek tallózhatóan elérhetőek legyenek. Ez a cél. Hiába érhetők el felcsatolva, az a munkatársaimnak kevés. Tehát próbálom őket kiszolgálni.
Tehát, az SMB1 elvesztése nem érdekelne túlzottan, ha a dolog többi rész korrekten működne. De sajnos valamilyen ok miatt, a rendszer pár gépén nem megy. Nincs beállítási különbség, - ezerszer átnéztem sőt az év első részében nap-mint nap ezzel foglakozom. - Mindannyiszor bekonfigurálom, visszahozom a rendszerbe ezeket a gépeket, - elérhetők, látják egymást, működnek a megosztott könyvtárak - de pár "boot" után ezek a gépek eltünnek a hálózatból. (Mivel Win 10-esek, nem hiszem hogy én kényszeríthetném ezeket az SMB1 használatára, hiszen ott van az oprendszeren működőképesen a SMB2 SMB3 protokoll is. Tehát azt mondom sérült a 10-es hálózati alrendszere. A sfc, a DISM viszont nem talál semmilyen hibát. A hálókártya sem hibás.A gépek ezt leszámítva kifogástalanul működnek, nem fagynak, nem omlanak össze, stb. (A függő szervizeket is átnéztem, engedélyeztem, ahol úgy találtam hogy túlzott restrikciót állítottam be, de ezek, úgy tűnik, nem lényegi részei a problémának.)
Hozzá teszem, hogy a Workgroup használatának gyakorlata egyáltalán nem igényelné, hogy az MS hozzákapcsolja a működési feltételekhez a "távoli eljáráshívást". Mivel erre például nekünk egyáltalán nem lenne szükségünk, és egy hálózati kommunikáció ilyen "függőségi kapcsolását" inkább biztonsági kockázatnak tartom, mint előnyös tulajdonságnak. (A gépek távoli elérhetőségét, akinek erre szüksége van külön szoftver protokoll telepítésével képzelném el legszívesebben, de nem alapértelmezett featuraként. (Igaz a fejlesztők erről nem engem kérdeztek.., :) Ez az én személyes, "hozzánemértő" magánvéleményem.)
A "Homegroup" jelszavas beállítása, a discovery engedélyezése sem kellene hogy negatívan hasson a "Worgroup" keretében kommunikáló gépekre, Windows-on számtalan hálózati protokoll "együttélve" működhet egymás mellett. Feltéve ha a fejlesztők hibátlanul "javítanak", és avatkoznak be a 20 éve fejlesztett hálózatkezelésbe. Sajnos úgy látom, ahogyan én, - és esetleg mások is, - úgy ők sincsennek teljesen tisztában a W10-en kialakult függőségek rendszerével. (Mert ugye ha igen , akkor ez a topic nem is létezne.)
Ami nem teljesen világos számomra, a "Browser"-szerviz miért nem fut-kapcsolódik össze a rendszerben a "Lanman"-szervizzel, amikor hálózaton tallózást kezdeményeznek, és a többi működő gépen-esetben meg miért jó? - Erre keresem a választ...? - Ha van ötleted, mi kerüli el a figyelmemet, szívesen meghallgatnám.
Persze ehhez hozzá tartozik egy hálózati eszköz és szoftvereinek alapállapotba történő hozása és a NETBIOS újra engedélyezése. Innentől kezdve tallózhatóan működőképes a rendszer. Sajnos csak néhány újraindulásig.
Szerintem meg baromi nagy szerencséd van ezzel! Én is csak a szívást érzem a folyamatosan lassuló win10-ek, és hirtelen instabillá váló windowsos alhálózatok mellett.
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Wireshark esetleg tud segíteni. De ismétlem, legyen egy Master Browser ami mindig elérhető (akár egy Linux gép, domain controller, NAS), a többi géptől pedig meg kell vonni ezt a jogot némi turkálással a registry-ben. Computer Browser service gondolom el van indítva.
Igen ezt beállítottam az első javaslatodra, (IsDomainMaster = True, - az eddig is elsőként induló gépen, - a többin "False" (MaintainServerList = Yes v. No). És a fő probléma a problémás gépeken a Browser szerviz "nem futása" (Csak arra nem jövök rá miért fut a többin, ezen a páron meg miért nem.)
A problémás gépeken akár a szolgáltatások közül, akár a parancssorból el tudom indítani. Csak fixálni nem tudom, hogy így a gép következő újraindításánál ha kell, elinduljon ismét. (Persze az "este folyamán még ment" eset inkább közelít a valósághoz.) Egész pontosan, nem ismerem a Tallózó-szolgáltatásnál, hogy a "Kézi indítás" opció, milyen indítás-feltételt tartalmazhat. (Mert a "default" minden gépen ennél a szolgáltatásnál.)
A Wireshark-os problémakeresés azért gond, mert nagy a hálózati forgalom, múltkor néztem, másfél perc alatt összejött a pcap-fájl másfél gigára... :( Szerinted lehet olyan konkrét h.-forgalom, ami kiüti egy gépen a szerviz működését, és ez a pár "kiválasztott" gép lett 2 hónapja már?
Nem egyforma típusok. (Van köztük HP, Dell, Fujitsu is.)
Le tudnád írni, hogy pontosan mi a teendő?
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
https://technet.microsoft.com/en-us/library/cc959923.aspx
Megnézem "tasklist /svc" paranccsal, hogy a szervizek között látszik-e a "Browser" ill. a "LanmanServer" szerviz. Ha a "Browser" nincs közöttük, akkor nagy valószínűséggel az "én problémám a Tiéd" is.
Ezután jön:
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\Browser /v SvcHostSplitDisable /t REG_DWORD /d 1 /f
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer /v SvcHostSplitDisable /t REG_DWORD /d 1 /f
sima parancssorban és rendszergazdaként futatva, a "net stop browser" majd (ha "panasz" van, hogy nem fut, akkor is) "reboot",
és "net start browser" parancsal elindítani a szolgáltatást, (megszoktam nézni a GUI felől is, fut-e, a "számítógép tallózó", ha nem rásegítek egy indítás "katt"-al.)
Ezután a "hálózat és internet" UWP-ről hálózati eszköz alapállapotba tételével újraindítom a gépet.
Az IPV4 protokol alatt engedélyezem a NETBIOS-t a TCP felett. És máris megjelenik nálam a gép/megosztás a hálón.. (Arra még nem jöttem rá, miért van az, hogy néhány gép már véglegesen gyógyult, de marad pár ami csak egy-két bootra tartja meg a visszaszerzett hálózati megosztást. - (Szenvedek még azokkal, mert nagyon "úúútálok" 0-ról újratelepíteni.)
(A SMB1-es nálam stabilan engedélyezve van, mert nagy Minolta + Kyocera hálózati ("100 éves") nyomtatókból jópár elérendő a hálózatban a 10-esek feköl is.)
Egyébként használtam a "sc config browser type= share && sc config lanmanserver type= share" parancsot is.
Mivel fórumokból "ollóztam" az alapötletet, - ezúton is köszönet érte. - Csak azért "bővítettem" a GUI felőli "operációval", mert ennyi önmagában még kevésnek bizonyult, és nem vagyok elég okos a full parancssoros megoldáshoz... :(
(Arra is gondolok, hogy a Win verziófrissítés a konfigok átemelésekor valamilyen registry-t érintő hiba miatt, csak a GUI "checkbox"-ok "átmásolásáig" jut el. A mögötte lévő registry bejegyzés elmarad v. csak részben sikerül átemelnie az új Windows könyvtárba?)
Idemásolom egy hozzászólásból egy az egyben az angolt is. - (Egyébként, biztosan nagyon sok oka lehet a megosztások eltűnésének, mert az általam ez előtt talált és kipróbált sok megoldás közül egy sem volt eredményes.)
lcsaszar által linkelt "MasterBrowser" beállítás is biztosan kell a probléma kezeléséhez.
1. Run "tasklist /svc"
In the output, you should see something like this:
Browser and LanmanServer running in their own svchost processes.
*Sample output below is abbreviated for illustration purposes.
You will see a longer list.
Image Name PID Services
========================= ======== ==============
svchost.exe 2772 LanmanServer
svchost.exe 2868 Browser
2. Run these two commands to add the SvcHostSplitDisable registry value set to 1.
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\Browser /v SvcHostSplitDisable /t REG_DWORD /d 1 /f
REG ADD HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer /v SvcHostSplitDisable /t REG_DWORD /d 1 /f
This will reconfigure the Browser service to run in a shared svchost
with LanmanServer like in previous versions of Windows.
3. Reboot the computer
4. Run "net start browser" and then "tasklist /svc"
In the output, you should see something like this:
Browser and LanmanServer running in a shared svchost process.
*Sample output below is abbreviated for illustration purposes.
You will see a longer list.
Image Name PID Services
========================= ======== ==============
svchost.exe 2772 Browser, LanmanServer
Köszönöm nektek, ez igen alapos volt, csekkolom én is...
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
sajnos egyik megoldás (illetve ezek kombinálása) sem változtatta meg a helyzetet, a teljes hálózat tallózásakor nem látszik a saját gép megosztása sem, ami egyébként egyedüliként látszik a hálózatoknál, továbbá kézzel hozzá tudok adni hálózati meghajtót, de tallózni továbbra sem tudom a szervert! :/
Az SMB1-et hogyan lehet visszakapcsolni?
--
Azt hiszem megvan a megoldás: a "Windows szolgáltatások be-és kikapcsolása"-menüben engedélyezni kell az "SMB1.0/CIFS rendszerű ügyfél"-szolgáltatást, és rögtön újra működik a tallózás...
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Ebben, csak az a számomra abszolut elfogadhatatlan megoldás, hogy mi, akik folyamatosan "találkozunk" a számítástechnikával. Rengeteget tanulunk nap mint nap, és ennek ellenére, - a világméretekben olvasható fórumok szerint is, - folyamatosan változó feltételek mellett, újabb és újabb megoldásokat találunk az MS által kikapcsolt szolgáltatás visszahackelésére, - mégis néhány nap múlva kezdhetjük előről.
Azaz szinte a "kibahás" szintjéig képesek eljutatni az áltataluk favorizált megoldást. Holott protokoll hiába elismerten szar, szükség van rá, ahol gépek, munkafolyamatok indokolják azt. Tehát nem nehezíthetnék a dolgunkat ilyenmódon. Miközben árnyékokra vetődünk és azt hisszük jó megoldást találtunk, az csak egy még le nem zárt módszer az MS-nél, mert a Defender utána megy ezeknek, és harmadnap már nem használható ugyanaz a parancs. Kb. 2 hónapja tapasztallom ezt.
Az már biztos (számomra is! :)), hogy SMB1 valóban eltávolításra kerül a következő időszakban. Már most van olyan gépem, ahol az ügyfél oldalát nem lehet a szerviznek visszakapcsolni. mert a "checkbox" üres a következő újraindításnál. A konzol alatti parancs sem működik a visszatételére. Eljátszottam a DISM - WinPE-es megoldással is, de az sem működik, mert olyan szinten változtatták meg az ADK Deployment Kit telepítés-könyvtárendszerét, Windows fejlesztőmérnöknek kéne lennem ahhoz, hogy ezt átlássam.
Végül is a "Browser"- (Tallózó)-szerviz függőségének átállításával, egyetlen paranccsal azonnal helyére tudom varázsolni a megosztásokat, és helyre állna a "hálózati rend", de a tallózandó gépek elérését nagymértékben nehezíti a Defender, amely védelmi metódusként lezárja a megjelenő gép elérését. (Kikapcsolása után persze azonnal, jönnek a használható megosztások.)
Kérdezem, ezek normálisan működő védelmi mehanizmusok? Hogyan gondolják a fejlesztők egyáltalán a gépek közötti folyamatos hálózati kommunikációt, ha egy vírusvédelmi program kockázati tényezőként lezárhatja azt?
Annak, aki közölte fentebb nekem, értsem végre meg, a "csába kiírtotta" az MS az SMB1-et. Vége!
Megértettem.., - ennek ellenére, a zűrzavart, amit az MS semmit érő kommunikációja ez ügyben folytatott, megismétlem, hogy nem tudom elfogadni. A probléma egyszerű megoldását teríteni kellett volna minden fórumon. Valamint ezt a fejlesztőknek és a WU-nak is meg lehetett volna oldani működőképesen. (Észre sem kellett volna vennünk az SMB1 eltűnését.)
Igazából, semmit nem értek el a protokol eltüntetésével, csak egy-két hónapra világméretű zűrzavart, és köpködést. valahol már készülnek az SMB2-re, 3-ra írt exploitok is. (Azért mert a hálózatok elérése, használata a kiberbűnözők számára is kihagyhatatlan processz, és amire ekkora szüksége van valakinek a pénzkereséshez, az nagy erőkkel mindenképpen lebontja az elé tett-fejlesztett akadályokat.)
Ha fejlesztők elhatározzák a sokunkat érintő, "világmegváltó cserét", akkor vagy automatikusan a tudtunk nélkül, a rendszerinti működést nem befolyásoló módon megoldják, - vagy ha nem lehet, - akkor világos útmutatást kell adniuk a helyettesítő megoldásra. - Ez nem tréfa és nem lehetne játszani ezzel, a hálózatok a világon sok ember egzisztenciáját érintő munkaeszközöként kezelendők.)
(Komolyan, az elmúlt 10-15 évben ennyi tévedésen alapuló, rövid távon talán még működő de alapvetően használhatatlan megoldásról nem olvastam, és nem is próbáltam ki még soha, amit "SMB1-ügyben" megtettem. - Valószínűleg mások is vannak ezzel így.)
Mi kell az MS-nek ahhoz, hogy megértsék, ezt a játékot újra és újra, nem űzhetik büntetlenül az egész világon a felhasználókkal, szakmabeliekkel, mert a harag és a düh, amelyet ilyenmódon generálnak, üzletileg vissza száll a fejükre a következő években...
A telnetet, rcp-t, rsh-t is használod még...? Meg a NIS-t, és a /etc/passwd-be rakott crypt()-tel "titkosított" jelszavakat? Nem? Érdekes... Pedig mostanra ezek is nagyjából ugyanannyira sz@r megoldások lettek, mint az SMB1...
Az smb lehet hogy szar, de nincs más helyette.
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
SMB1-et említettem, mint ócskaságot, amit illene kihajítani, mint pl. a NFS-ből a v2 meg akár a v3-at is. Az SMB 2.0 2006-ban, a 2.2 (később 3.0) meg valamikor 2011-12 táján - nem igazán védhető, hogy nem volt mód és lehetőség "utánahúzni" a környezetet.
Ahol egy gépen kikapcsoltam, eltávolítottam, onnan a többi W10-es megosztásai elérhetőek, működik. - tallózhatóan is. - (A W10 gépek egyébként úgy vannak konfigurálva, hogy SMB1, SMB2 is működhet. - Sajnos NAS nem elérhető. Pedig ott is be van állítva a magasabb (SMB2) protokoll kezelése. Az öreg hálózati nyomtatók meg egyenlőre nem is cserélhetők le. Még firmware frissítés esetlegesen szóba jött, de erre még várok, kicsit nyugodtabb /pl. most 4 napos ünnep.../ időszakra.)
Hozzáteszem, kisvállalkozások sokan manapság "másodkézből" veszik a technikát. Nem költenek "extra" forintokat még a 2011 óta működő gépek cseréjére sem. - (Sőt azok az elérhető árú, mai számtech gépekhez képest "ideális korú", elnyűhetetlen gépeknek számítanak.)
A plottereket, digis-nyomtatókat nem lenne két fillér "szintre hozni". (Tudok olyan műhelyről, ahol az AGFA levilágító WinNT3.5-ösön futó vezérléssel mégi napi rendszerességgel használva van. - 1996 óta megy!)
(sub)
Nnna. Nálam az hozott megoldást, hogy a Szolgáltatásokból kivettem az SMB-t, restart, és visszatettem. A régi vezérlőpultnál még ott van.
"Szálljunk ki és száljunk vissza..."
Orwell az 1984-et regénynek írta és nem használati utasításnak!
Ezt is érdemes elolvasni:
https://answers.microsoft.com/en-us/windows/forum/windows_10-networking…
"A hálózaton egy gép hálózati adapterére vonatkozó, szinte minden hivatkozás törölve lett a rendszerleíró adatbázisból."
Nálam ilyen nincs, mert a hálózaton akkor az a többi gép felé is süket lenne.. (Az én bajom az, hogy látszólag azonos beállítások ellenére is a gépek különbözőképpen viselkednek. - Nyilván van eltérés valamiben, de miben..?)
Nem olvastam végig a hozzászólásokat, de nekem is hasonló problémám volt és itt volt a megoldás. Talán segít.
https://hup.hu/node/157423
ennek mi köze ahhoz, hogy a hálózat tallózó nem működik?
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Az a köze hozzá, hogy ugyanígy nem működött W10 frissítés után. Annyi kiegészítéssel, hogy nekem csak a jelszó nélküli megosztások nem mentek.
Arról itt nem volt szó, hogy van-e jelszó a megosztásokon.
ja, az én szálamban a teljes tallózhatatlanság problematikájára kerestem a megoldást, a topicnyitó pedig a részlegesre. Az ok a frissítésben az SMB1 kikapcsolása, az SMB1 kliens visszakapcsolása orvosolja a hibát.
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Sajnos, ez is csak ideig óráig, mert mindjárt beköszönt "a tavaszi szél vizet áraszt" frissítés, rövidesen... :)
Egyébként tényleg az a legzavaróbb, hogy jelenleg a legkülönfélébb viselkedést produkálnak egymástól persze eltérő hardvereken, hálózatkezelésben az 1709-esek. Főként a különböző verziójú samba-k elérhetőségeit illetően gáz az egész. (Az automatizált mentés problematikája, amelyet egy ma indult Windows topic felvet, ezzel is "színesedik".)
gyaníthatóan nem fog véglegesen eltűnni az SMB1, max eldugják és kikapcsolják, de aki rászorul, az visszakapcsolhatja.
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
Nálam a vendég fiók mindig, mindenhol tiltva volt. Mindig csak jelszavas kapcsolat létezett. Viszont itt nincs tartomány, (AD sem) Csak "Workgroup"-os hálózat, (spékelve némi "Homegroup"-megoldással) amely "vegyesfelvágott" a W10 1703-1709 előtt tökéletesen működött. Egyébként a "tallózhatóságra" beállított Synology NAS-ek a legékesebb bizonyítékai a hibás hálózatkezelésnek, mert van gép ahol bizonyos esetekben tallózhatóan is megjelenik, legtöbb helyen csak felcsatolva használható.
Azután van gép, ahonnan pl. pár napja elérni sem tudok egy másik Free-t. (De a többi W10 gépek megosztásait tallózhatóan "látja". - Egy-két hete egyébként még száz gigákat mentettem róla rá.)
Nekem igazán bajom, ezzel a megbízhatatlan, időről-időre változó hálózati szoftverelemekkel van. - Valamit a "Workgroup" működési feltételeit illetően szúrtak el.., nem kicsit. (A "browser"-szervíz futása, v. nemfutása, v., hogy nem kapcsolódik a Lanmanserver-szerviz futásához, már csak hab a tortán.)
Amit olvastam több helyen, hogy az 1709-es tiszta telepítéssel, már fel sem rakja a SMB1-et, nem igaz, mert egy mostani (tegnapi) telepítésemen is fut. (Természetesen első dolgom a feladatütemezőben a "SMB1 server-kliens "autoremove" featúrát törölni. Jelenleg régi nyomtatókat, NAS-eket illetően nem nélkülözhető, és a "Workgroup" is jelenleg azokon a gépeken működik normálisan, ahol az SMB1 hibátlanul fut.)
(Gondolok még arra a lehetőségre, hogy egyes random mdns, IPV6-os hálózati funkciók a Windows 10 működését illetően "romba döntik" a Workgroup-ot.) Na akkor, biztosan SMB2 (meg több!) lesz a vége mindennek.)
Ha már Synology NAS-od van az DSM 6.1 óta lehet AD tartományvezérlő (Samba4 alapú), bár azt hiszem külön kell telepíteni. Esetleg próbáld ki.
https://www.synology.com/hu-hu/dsm/feature/active_directory
http://www.giakonda.org.uk/wp-content/uploads/2017/06/synology-AD-serve…
--
Légy derűs, tégy mindent örömmel!