Windows SMB alternatíva

Microsoft Windows

Mivel úgy látszik a Microsoft porig kívánja rombolni a Windows rendszerét de nekem jelenleg még szükséges használnom sajnos, alternatívát keresek SMB szolgáltatásra.

A fájlmegosztást mostanra teljesen használhatatlanná tették. Windows 10-en már régóta nem működik, most már Windows 7-en sem megy. A Linuxos Samba szervereket is eddig el lehetett érni, de már azok sem működnek Windows kliens alól.
Nincs időm az izgalmas windows frissítések rejtvényeire, főleg nem rendszeresen.

Milyen lehetőleg Microsoft-független szolgáltatást lehet használni alternatívaként?
FTP szerverrel az a problémám, hogy ott a fájlok átvitelekor elvesznek az eredeti időbélyegek és a letöltés pillanatának ideje lesz a másik oldalon az átvitt fájloknál. Nekem viszont szükségem van a fájlok eredeti időbélyegeinek megtartására.

( n.balazs v | 2019. 01. 25., p – 17:26 )

Sftp Winscp-vel esetleg megfelelő lehet.

Egyelőre ezt találtam megfelelő megoldásnak.

Akit érdekel OpenSSH server telepítése Windowsra innen lehet letölteni:
https://github.com/PowerShell/Win32-OpenSSH/releases

Ki kell csomagolni C:\Program Files\OpenSSH -ba
majd abban a könyvtárban rendszergazda cmd-ben a következő parancsot kell kiadni:
powershell.exe -ExecutionPolicy Bypass -File install-sshd.ps1

Ki kell nyitni a windows tűzfalon a 22-es portot vagy kattintgatással vagy powershellben így:
New-NetFirewallRule -Name sshd -DisplayName 'OpenSSH SSH Server' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

Majd el kell indítani a szolgáltatást. Erre csak kattintós megoldást ismerek: Control Panel -> System and Security -> Administrative Tools -> Services.
Ki kell keresni az OpenSSH SSH Server szolgáltatást és el kell indítani. Továbbá érdemes manual-ról automatic-ra állítani az indítást. Az OpenSSH Autentikációval nem kell foglalkozni és el sem kell indítani.

Friss Windows 10-en Apps & features -ből közvetlenül bekapcsolható az OpenSSH szolgáltatás Windowson. A fenti módszer viszont a többi Windowson is működik.

( lcsaszar v | 2019. 01. 25., p – 17:30 )

Nekem még működik. Mi a gond nálad?

Az egyik faragás ami segített, hogy kijelöltem egy mindig online master browsert (Linux alapú NAS).

Először Windows 10 smb vált elérhetetlenné kívülről, de lan-on belül. Ezzel nagyjából egy időben Windows 8.1-en is, legalábbis amikor ránéztem az ottani smb-re már ott sem ment.
Most már a Windows 7 is.

Azt olvastam, hogy cryptomalware elleni tűzoltás a Microsoft részéről, mert egy fertőzött gép smb segítségével végigmegy minden hálózati meghajtón. Ha így van elég hülyén csinálják mert akkor egy semmitmondó hibakód helyett az okokat kellene leírni a hibaüzenetben egy linkkel további infókkal.
Korábban még valami registry mókolással helyre lehetett hozni. Talán még most is lenne kerülőút, de ez így nem mehet tovább. Nekem nincs időm arra, hogy frissítéssel jött meglepetés smb problémák javításával szórakozzak.
Ezért kell inkább egy megfelelő alternatíva, ami stabilan működik még a Microsoft frissítések után is. Teljes értékű sem kell legyen. Például nem baj ha nem lehet távolról bármilyen állományt úgy használni mintha helyi lenne. Azaz elég ha a fájlátvitel működik megbízhatóan és az időbélyegek nem változnak.

NE tegyen ilyet. Az SMB2+ Windows7 és afölött, valamint Samba-val is remekül működik.

smb.conf-ba:
client min protocol = SMB2_02
client max protocol = SMB3_11

illetve:
client min protocol = SMB2_02
client max protocol = SMB3_11

Aztán mindenki happy. A Windows-ok is.

Hálózat tallózás nincs SMB1 nélkül, de az felejthető - tanuld meg a géped nevét. :)

-1.
Ha le kell mondani a tallózásról, akkor hadd menjen az SMBv1 a kukába. Teljesen sebezhető és inkább legyen +1 réteg biztonság a hálózat share-eken.
Ha valakinek kell egy share, fel tudja mappelni. Teljesen élhető mnegoldás home/small business sőt még "middle business" környezetben is.

Ha engedi az SMB1-et Samba-n, akkor lesz tallózása (mert a Network Browsing az SMB1 "csomag" része), de a Windows a tényleges megosztás elérést a szerver által biztosított legmagasabb számú protokollon teszi, nem SMB1-en. Windows 7 SMB2+-on, Windows 10 SMB3+-on kapcsolódik. smbstatus-al könnyű ezt ellenőrizni. Nekem megy itthon az SMB1 és a tallózás, de az összes gépem Win10-es, és mint SMB3.11-en kapcsolódik.

Az SMB1 a sebezhetősége miatt aggályos, amit bizonyos ransomware-ek használnak ki. De sajna kiderült azóta, hogy a terjedésüket az SMB1 kiiktatása nem igazán gátolta meg, tehát nettó szívás lett az SMB1 elleni hadjárat a browsing kiesése miatt, tényleges haszon nélkül.

Nagyon érdekes, hogy egy időben az MS azt mondta, hogy felejtse el mindenki a hálózati megosztások meghajtó betűjelre mappelését, mert a titkosító vírusok a betűjeles meghajtókat támadják, tessék kitallózni és/vagy UNC-t használni. Aztán most kitalálták tavaly a fordítottját, hogy mindenki felejtse el a hálózati tallózást mert azt támadják, inkább vagy jegyezzen meg gépneveket/UNC-ket, vagy a rendszergazda GPO-ból mappelje a meghajtókat.
Ja, persze az MS saját OS-ei egy egyenlőre zárt megoldással tudnak tallózni egymás között... (Nyilván ebben a nagy open source összeborulásban is szálka maradt a Samba).

Mindez persze az én személyes olvasatom a témáról.

Ja, persze az MS saját OS-ei egy egyenlőre zárt megoldással tudnak tallózni egymás között...

Itt melyik zárt megoldásra gondolsz? Az egyetlen, ami felmerül bennem az a HomeGroup, aminek a specifikációja a 0. naptól elérhető az Open Specifications megnyitása óta és csak azért nem támogatja semmi más, mert egy szintén nagyon elcseszett protokoll - amit szépen mutat, hogy a 1803-ból ki is vették.

Félre ne érts, nem védeni akarom az MS-t, de a NetBIOS/WINS tényleg nagyon legacy cucc (pl. 0 IPv6 támogatással, protokoll-csere kellene hozzá) és szvsz. nem kár érte.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( sigellef | 2019. 01. 25., p – 17:55 )

Biztos hogy az smb-vel van ott a gond?
Melóban tavaly is, most is sok gépet modernizáltunk, winxp->win10 win7->win10 átállás, és minden rendben van a fájlmegosztásokkal, a legutóbbi frissítés után is.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
Amióta megismerkedtem az Anroidos és IOS-es kacatokkal, azóta a Windows láttán már nem kapok gyomorgörcsöt.

( dj | 2019. 01. 26., szo – 09:32 )

windows 10 smb2-vel teljesen jól működik.

( Lifeforce | 2019. 01. 26., szo – 10:10 )

Windows 8 és felette:
Vezérlőpult -> Programok -> Windows-szolgáltatások be- és kikapcsolása -> SMB 1.0/CIFS rendszerű fájlmegosztási támogatáshoz tedd be a pipát, majd reboot.

( an-dee | 2019. 01. 26., szo – 20:23 )

Megfelelő AV termékkel azért az smb v1 hibáit is lehet védeni, nem mondom hogy ez a követkendő, de ha nincs más. Otthon Win7/Win10 (pro mindkettő) illetve Synology NAS csak az SMB v1 bekapcsolás után hajlandó látni egymást.

--
ESET és Synology hivatalos viszonteladó

Tallozashoz smb1.0 kell. A master browser mint olyan onmagaban nem eleg hozza, kliens is kell. Egyebkent minden smb halozatban van master browser, ha nincs kijelolve, akkor eldontik egymas kozott (asszem az azonos ertekuek kozott mindig a legutoljara bejelentkezett gep lesz, ha csak nincs magasabb erteku)

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

(asszem az azonos ertekuek kozott mindig a legutoljara bejelentkezett gep lesz, ha csak nincs magasabb erteku)

Fordítva, ha minden más egyezik, akkor a nagyobb uptime-al rendelkező lesz a master. (https://www.samba.org/samba/docs/using_samba/ch07.html)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ahh igaz, régen volt már...
Volt egyebkent egy erdekes esetem, egy a lan-ra wifin csatlakozó gép folyton elvette a sambatol a master browser szerepet, hiaba volt az smb-conf megfeleloen beallitva. Aztan azon a gepen a fajlszerver kikapcsolasa oldotta meg a dolgot, nem jottem ra a megfejtesre...

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

A titkosító-zsarolóvírusok ellen nem véd az ESET. Legalábbis 2017 novemberében volt ilyen incidens a munkahelyen, pedig minden gépen fenn voltak az ESET cuccai. Nem tudom, azóta változott-e ez a helyzet.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.
Amióta megismerkedtem az Anroidos és IOS-es kacatokkal, azóta a Windows láttán már nem kapok gyomorgörcsöt.

( kallaics | 2019. 01. 27., v – 08:13 )

Én arra gondoltam, hogy mi lenne ha az SMB helyett valamilyen más irányba nézelődnél, ahogy írtad is.

Owncloud, SeaFile, NextCloud. Bár a nevükben benne van a cloud, de fel tudod tenni egy gépre a saját hálózatodon és minden usernek fel lehet tenni egy kliens progit és akkor kezelhetőbb. Szerintem ebből próbáld meg megkeresni számodra megfelelőt és át lehet migrálni SMB-ről a választott megoldásra.

Az MS is ezt szeretné csak az ö saját (elöfizus) onedrive-jával,életszerü megoldás az 1 m-re lévö gépek a fél világon keresztül cseréljenek fájlokat.
Igy kell rávenni a usereket a Onedrive (O365 ) elöfizetésre
Vistától kezdve SMBv2,7 SMBv2.1,8 SMBv3 adott.
Linux (régi) 2000,XP,2003 vegyes környezetben marad az SMBv1 visszakapcsolása a 8,10 rendszereken már ha file sharing kell.
Amennyiben nincsenek az emlitett rendszerek már a hálón akkor SMBv2 vagy felette ugyanugy müködik a file sharing

Zolee001

Miért?
Gigabites lan számára nem probléma talán még 100mbps is elég erre.
Vagy arra gondoltál, hogy sok nagy méretű fájlt átköltöztetni túl sok probléma? Ebben van valami. De erre már találtam megoldást. FileZilla ftp szerverrel tökéletesen működik a hálózati videólejátszás ha Windowson van a video. Linuxon meg számtalan ftp server közül lehet válogatni. Egyetlen hátránya smb-hez képest, hogy nem lehet visszafele tekerni csak előre.

Úgy érted, hogy például Owncloud-on van egy smb-hez hasonló szolgáltatás ami nem smb és hozzá kliens?
Mert Zentyal szerverem most is van, de már az ott működő samba megosztáshoz sem lehet hozzáférni windowsok alól. Linuxból, macOS-ből probléma nélkül elérhető a samba.
Owncloud-ban van olyan szép webmail mint Zentyal-on a SOGo? Mert ha igen, lehet lecserélném erre.

Az Owncloud és az ahhoz hasonló megoldások kiválthatják az SMB szolgáltatást, mert alapvetően fájl megosztásra van kitalálva.
Zentyaltól függetlenül telepíthető, ugyanakkor a felhasználókat és csoportokat össze lehet lőni, hogy a Zentyal féle AD-ból authentikaljon.
A gépekre telepített kliens nem kötelező, csak ajánlott. Ha nincs kliens telepítve, akkor böngészőn keresztül érhetőek el a fájlok, könyvtárak.

Itt olvashatsz utána például az Owncloudnak: https://owncloud.org/

Mint ahogy fentebb írtam, az SMB kiváltható egy ilyen fájlkezelő szolgáltatással (Owncloud, nextcloud, seafile etc.)

A Zentyal egy komplett webes felület, ami próbálja visszaadni a Windows-os szerverek grafikus felületén történő konfigurációját. Vagyis a Zentyalban többféle szolgáltatást tudsz konfigurálni.

Tehát lesarkítva: Zentyal nem egyezik meg az Owncloud, NextCloud, Seafile alternatívákkal. Maga a Samba szolgáltatása váltható ki az általam javasolt megoldások egyikével. Ha nem akarsz két szervert, akkor ezen megoldások többsége fut Docker alól is.

( N0v3mb3r v | 2019. 01. 27., v – 23:38 )

FTP szerverrel az a problémám, hogy ott a fájlok átvitelekor elvesznek az eredeti időbélyegek és a letöltés pillanatának ideje lesz a másik oldalon az átvitt fájloknál

A legtöbb ftp-kliensben beállítható, hogy megőrizze az eredeti dátumot akár fel- akár letöltésről legyen szó. Nagyobb problémának érzem, hogyha párhuzamosan dolgozik több ember a fájlokkal és sorban töltik őket vissza, akkor csak a legutolsó módosításai lesznek meg.

---
A kürtőskalács egy nagy lyuk, tésztával faszán körbetekerve.