SMB kontra NFS: Którą metodę udostępniania plików wybrać do użytku domowego?

Jeśli w twojej domowej sieci są komputery z Windows, Mac, telefony, tablety i odtwarzacze multimedialne, SMB jest zazwyczaj lepszym domyślnym wyborem. Naturalnie integruje się z przeglądarkami plików na pulpicie, obsługuje logowanie oparte na użytkownikach i jest szeroko dostępny w aplikacjach konsumenckich.

NFS staje się bardziej atrakcyjny, gdy klientami są głównie serwery Linux, hosty Proxmox lub inne systemy podobne do Unix, które montują pamięć masową jako część zarządzanego przepływu infrastruktury. Może być wydajny i przewidywalny, ale tylko wtedy, gdy wartości UID/GID, reguły eksportu, zachowanie montowania i własność plików są odpowiednio zaplanowane.

Wybierz protokół w zależności od klienta, a nie od wyników testów

SMB i NFS pozwalają urządzeniom otwierać pliki przechowywane na NAS lub domowym serwerze, ale zostały zaprojektowane dla różnych ekosystemów. SMB jest natywny dla Windows i szeroko wspierany przez macOS, Linux, menedżery plików na urządzeniach mobilnych, smart TV i aplikacje multimedialne. NFS lepiej wpisuje się w przepływy montowania Linux i Unix.

To rozróżnienie jest ważniejsze niż ogólne twierdzenie, że jeden protokół jest szybszy. Laptop z Windows może mieć płynniejsze i szybsze działanie przez SMB, ponieważ jego stos kliencki jest zbudowany wokół SMB. Serwer Linux przetwarzający tysiące plików może być łatwiejszy do zarządzania przez NFS, ponieważ zdalny katalog zachowuje się jak normalny montaż Unix.

Zacznij od spisania urządzeń, które będą miały dostęp do udziału i tego, co będą z nim robić. Przeglądanie plików przez ludzi, przechowywanie między maszynami, strumieniowanie mediów, kopie zapasowe, wirtualizacja i dane kontenerów nie zawsze wymagają tego samego protokołu.

SMB jest zazwyczaj łatwiejszym domyślnym wyborem dla mieszanych środowisk domowych

SMB jest zazwyczaj najprostszą opcją, gdy użytkownicy otwierają foldery ręcznie z Eksploratora plików Windows, Findera macOS, telefonu lub aplikacji odtwarzacza multimedialnego. Użytkownicy mogą łączyć się za pomocą nazwy użytkownika i hasła NAS bez konieczności zarządzania numerycznymi tożsamościami Linux na każdym kliencie.

Nowoczesne wersje SMB oferują również funkcje wykraczające poza podstawowy transfer plików, w tym ACL dla użytkowników i grup, podpisywanie, szyfrowanie, blokowanie plików, buforowanie oraz możliwości wielokanałowe. Te funkcje zwiększają złożoność, ale są przydatne, gdy kilku domowników potrzebuje różnych praw dostępu.

Dla mieszanych sieci Windows, macOS i Linux, nowoczesny SMB 3.x może zmniejszyć większość różnic wydajności, zachowując szerszą kompatybilność klientów. To czyni SMB praktycznym punktem startowym dla dokumentów, rodzinnych zdjęć, wspólnych pobrań i ogólnego przeglądania NAS.

NFS lepiej pasuje do zarządzanych przepływów pracy Linuxa

NFS jest często łatwiejszy do integracji, gdy klientem jest serwer Linux, a nie osoba przeglądająca foldery. Udział może być montowany w stałym katalogu podczas uruchamiania i używany przez oprogramowanie do kopii zapasowych, usługi multimedialne, hosty wirtualizacji lub inne procesy systemowe.

To działa dobrze, gdy jeden administrator kontroluje zarówno NAS, jak i klientów. Można zdefiniować dozwoloną podsieć, dopasować użytkowników i grupy, wybrać opcje montowania i upewnić się, że usługi uruchamiają się dopiero po udostępnieniu sieci.

NFS staje się mniej wygodny, gdy laptopy z Windows, aplikacje mobilne lub wielu użytkowników domowych potrzebują bezpośredniego dostępu. Chociaż istnieją wieloplatformowi klienci NFS, konfiguracja i mapowanie tożsamości zwykle są mniej proste niż używanie SMB na tych urządzeniach.

SMB i NFS używają różnych modeli dostępu

SMB zwykle prezentuje dostęp jako konto serwera. Użytkownik łączy się za pomocą poświadczeń, a NAS ocenia uprawnienia udziału, grupy i ACL systemu plików powiązane z tą tożsamością.

Typowe domowe konfiguracje NFS działają inaczej. Eksport jest często ograniczony do wybranych hostów lub podsieci, podczas gdy dostęp do plików zależy od numerycznych wartości UID i GID Unix przesyłanych przez klienta. NFSv4 może korzystać z bardziej zaawansowanych konfiguracji tożsamości i Kerberosa, ale wiele domowych instalacji nadal opiera się na zaufanych sieciach klientów i numerycznej własności.

Praktyczna różnica polega na tym, że SMB zwykle używa ACL użytkowników i grup, podczas gdy dostęp NFS jest ściśle powiązany z regułami hosta i własnością UID/GID w Linuxie. Żaden model nie jest automatycznie lepszy, ale każdy stwarza inne problemy podczas rozwiązywania problemów.

Planowanie UID i GID to główna krzywa uczenia się NFS

Nazwa użytkownika w Linuksie to tylko czytelna etykieta. System plików ostatecznie zapisuje numeryczne identyfikatory użytkownika i grupy. Dwie maszyny mogą mieć użytkownika o nazwie media, ale to różne tożsamości, jeśli jeden używa UID 1000, a drugi UID 1001.

Dlatego udział NFS może zostać zamontowany pomyślnie, podczas gdy tworzenie plików nadal się nie powodzi. Ścieżka sieciowa i eksport działają, ale użytkownik przedstawiany przez klienta nie odpowiada właścicielowi, grupie ani ACL na NAS.

Przed użyciem NFS dla kilku systemów Linux porównaj wyniki id username na kliencie i serwerze. Rodzaj dopasowania numerycznych UID i GID wymaganego dla zapisywalnych udziałów NFS często jest brakującym krokiem, gdy użytkownik może wejść do katalogu, ale nie może tworzyć plików.

Root Squash nie jest przypadkową awarią uprawnień

Eksporty NFS zwykle używają root squashing, aby zapobiec automatycznemu uzyskaniu uprawnień root na NAS przez użytkownika root na maszynie klienckiej. Żądania z zdalnym UID 0 są mapowane na mniej uprzywilejowaną anonimową tożsamość.

To może zaskoczyć użytkowników uruchamiających skrypty kopii zapasowych, kontenery lub polecenia kopiowania administracyjnego jako root. Udział jest montowany, ale zapisy nie powiodą się lub pliki pojawiają się pod anonimowym użytkownikiem.

Nie wyłączaj root squashing tylko dlatego, że blokuje jeden proces pracy. Najpierw ustal, który użytkownik lub grupa nie-root powinna posiadać dane, a następnie daj tej tożsamości wymagany dostęp. Używanie no_root_squash rezygnuje z ważnej granicy bezpieczeństwa i nie powinien być traktowany jako zwykły skrót do serwera domowego.

NFS nie jest automatycznie szybszy niż SMB

Wydajność zależy od systemu operacyjnego klienta, wersji protokołu, rozmiaru pliku, obciążenia metadanymi, puli pamięci masowej, podpisywania lub szyfrowania, opcji montowania, łącza sieciowego i zachowania aplikacji.

Pojedyncze duże wideo głównie testuje przepustowość sekwencyjną. Jeśli oba protokoły mogą nasycić dysk lub łącze sieciowe, ich wyniki mogą wyglądać podobnie. Katalog zawierający tysiące miniatur, napisów, plików metadanych i zagnieżdżonych folderów wywiera większą presję na wyszukiwanie plików, buforowanie atrybutów i małe operacje.

Dlatego jeden test wydajności nie może rozstrzygnąć wyboru dla każdego domu. Przetestuj co najmniej cztery obciążenia: jedno duże odczytanie, jedno duże zapisanie, katalog z wieloma małymi plikami oraz normalne przeglądanie folderów z klienta, który faktycznie będzie korzystał z udziału.

Duże pliki multimedialne zazwyczaj nie potrzebują najszybszego protokołu

Typowy strumień filmowy zużywa znacznie mniej przepustowości niż może zapewnić zdrowe połączenie Gigabit Ethernet. Jeśli serwer multimedialny nie może odtwarzać jednego wideo niezawodnie w sieci lokalnej, wąskim gardłem może być Wi-Fi, transkodowanie, wydajność dysku lub kompatybilność klienta, a nie SMB kontra NFS.

Różnica staje się bardziej widoczna, gdy Plex, Jellyfin, Sonarr lub inna aplikacja skanuje dużą bibliotekę. Serwer może otwierać tysiące plakatów, napisów, plików NFO i odwołań do bazy danych, mimo że faktyczne odtwarzanie czyta jeden duży plik multimedialny sekwencyjnie.

Z tego powodu streaming dużych plików może działać dobrze na obu protokołach, podczas gdy skanowanie małych plików ujawnia większe różnice. Serwery multimedialne oparte na Linuksie mogą korzystać z NFS, ale klienci Windows i macOS zwykle łatwiej obsługują SMB.

SMB jest zwykle lepszy do bezpośredniego dostępu odtwarzaczy multimedialnych

Jeśli Apple TV, urządzenie Android TV, telefon, tablet lub laptop łączy się bezpośrednio z NAS, SMB jest zazwyczaj łatwiejszym wyborem. Wiele aplikacji multimedialnych potrafi przeglądać udziały SMB za pomocą adresu serwera, nazwy użytkownika i hasła.

Wsparcie dla NFS różni się między aplikacjami i urządzeniami. Nawet jeśli jest dostępne, konfiguracja eksportu i uprawnień może być mniej oczywista dla użytkowników domowych niż wpisanie zwykłych danych SMB.

To jest niezależne od sposobu, w jaki sam serwer multimediów montuje magazyn. Serwer Jellyfin na Linuksie może odczytywać swoją bibliotekę przez NFS, podczas gdy urządzenia rodzinne łączą się tylko z interfejsem webowym lub streamingowym Jellyfin. Urządzenia końcowe nie potrzebują bezpośredniego dostępu do protokołu plików.

NFS często jest naturalnym wyborem dla magazynu Proxmox

Proxmox działa na bazie Linuksa, więc NFS naturalnie pasuje do procesów tworzenia kopii zapasowych, ISO, szablonów i współdzielonego magazynu. Eksport NAS może być montowany przez hosta i zarządzany jako infrastrukturalne miejsce przechowywania, a nie jako udział plików na pulpicie.

To nie oznacza, że każdy dysk maszyny wirtualnej powinien być automatycznie umieszczany na domowym serwerze NFS. Przechowywanie VM zależy od opóźnień, zachowania zapisu synchronicznego, dostępności sieci, projektu kopii zapasowych oraz sposobu działania systemu po restarcie lub rozłączeniu NAS.

Dla kontenerów może być też czyściej zamontować NFS na hoście Proxmox i przekazać ścieżkę magazynu do nieuprzywilejowanego kontenera, zamiast konfigurować montowanie sieciowe dla każdego kontenera osobno lub nadawać mu uprawnienia tylko do montowania udziału.

Przechowywanie w Dockerze powinno być wybierane według typu danych

Używanie ścieżki NAS w Dockerze nie oznacza automatycznie, że NFS jest właściwym wyborem dla każdego kontenera. Znaczenie ma bardziej obciążenie niż platforma kontenera.

Biblioteki multimediów, pobrane pliki, importy, eksporty, kopie zapasowe i inne duże pliki współdzielone dobrze działają przez SMB lub NFS. Host Linux Docker może preferować NFS, ponieważ własność plików wyrażana jest przez znane wartości UID/GID.

Bazy danych, pliki SQLite, indeksy wyszukiwania, stan aplikacji i zadania z częstym blokowaniem lub synchronicznymi zapisami wymagają większej ostrożności. Trzymaj te pliki na lokalnej pamięci, chyba że aplikacja wyraźnie obsługuje wybrany system plików sieciowych i przetestowałeś zachowanie przy restarcie, blokowaniu i awariach.

Zamontuj udział na hoście przed przekazaniem go do kontenerów

W wielu wdrożeniach serwerów domowych najczystszy model to zamontowanie udziału NAS raz na hoście Docker, a następnie podmontowanie lokalnej ścieżki do kontenerów, które jej potrzebują.

To utrzymuje poświadczenia, ustawienia eksportu NFS, zachowanie ponownego łączenia i kolejność uruchamiania w jednym miejscu. Kontenery widzą tylko normalny katalog, podczas gdy host zarządza systemem plików sieciowych.

Model działa zarówno z NFS, jak i SMB. Ważne jest, aby montowanie na hoście było dostępne przed uruchomieniem kontenera, UID/GID kontenera miały dostęp do zamontowanych plików, a usługa nie zapisywała cicho do pustego lokalnego katalogu, gdy NAS jest offline.

Nie pozwól, aby oba protokoły zapisywały te same dane bez planu

Większość platform NAS może udostępniać ten sam zestaw danych przez SMB i NFS. Technicznie umożliwia to użytkownikom Windows i aplikacjom Linux pracę z tymi samymi plikami.

Problem polega na tym, że dwie ścieżki mogą tworzyć pliki pod różnymi tożsamościami i modelami ACL. Przesłanie przez SMB może należeć do konta NAS z szczegółowym ACL, podczas gdy aplikacja NFS zapisuje jako UID 1000 z bitami trybu POSIX i inną maską umask.

Jeśli oba protokoły potrzebują dostępu, zdefiniuj jeden główny zapisujący. Drugi protokół może być tylko do odczytu lub oba mogą korzystać z starannie dopasowanej wspólnej grupy i modelu dziedziczenia. Bez takiego planu stopniowo pojawiają się rozbieżności w uprawnieniach.

Używanie obu protokołów jest rozsądne, gdy ich role pozostają oddzielne

Mieszany domowy lab nie musi wybierać jednego protokołu dla wszystkiego. Uruchamianie obu może być czyściejsze niż wymuszanie tego samego modelu dostępu dla każdego urządzenia.

Praktyczny podział to:

• SMB do rodzinnych folderów Windows i Mac
• SMB do bezpośredniego dostępu z telefonu, tabletu i telewizora
• NFS do kopii zapasowych Proxmox i hostów Linux
• NFS do montowania biblioteki tylko do odczytu w serwerze multimedialnym Linux
• Lokalna pamięć dla baz danych aplikacji i wrażliwego stanu działania

Protokoły powinny być podzielone według odpowiedzialności, a nie domyślnie włączane wszędzie. Oddzielne zestawy danych lub wyraźne granice odczytu/zapisu zmniejszają konflikty uprawnień i ułatwiają rozwiązywanie problemów.

Żaden z protokołów nie powinien być bezpośrednio wystawiony do internetu

SMB i NFS są przeznaczone do zaufanych sieci lokalnych lub prywatnych ścieżek sieciowych. Nie przekierowuj portów TCP 445 dla SMB ani portów usług NFS z routera domowego do publicznego internetu.

Do zdalnego dostępu do plików najpierw połącz się z siecią domową przez VPN lub inną warstwę prywatnego dostępu z uwierzytelnianiem. Gdy urządzenie zdalne znajdzie się w tej zaufanej ścieżce, może korzystać z tego samego serwisu SMB lub NFS dostępnego w LAN.

Zmiana z SMB na NFS nie czyni ekspozycji publicznej bezpieczniejszą. Bezpieczeństwo zależy od ograniczenia dostępnych klientów, aktualizacji oprogramowania, stosowania odpowiedniej autoryzacji i unikania niepotrzebnych usług publicznych.

Testuj więcej niż prędkość transferu

Rzetelny test domowy powinien używać tego samego zestawu danych NAS, klienta, łącza sieciowego i plików dla obu protokołów. W przeciwnym razie wynik może mierzyć różne ścieżki przechowywania lub urządzenia klienckie, a nie SMB i NFS.

Zapisuj więcej niż megabajty na sekundę. Testuj, czy montaż łączy się ponownie po uśpieniu lub restarcie, czy nazwy plików i metadane zachowują się poprawnie, czy aplikacje mogą tworzyć i usuwać pliki oraz czy uprawnienia pozostają spójne.

Protokół, który jest o pięć procent szybszy, ale regularnie zawodzi po restarcie, może być gorszym wyborem. Niezawodność, kompatybilność klienta i czas potrzebny na utrzymanie uprawnień to elementy rzeczywistej wydajności.

Użyj tego porządku decyzyjnego

Zacznij od klientów, a nie od preferencji protokołu. Wypisz każdy komputer, urządzenie mobilne, odtwarzacz multimedialny, serwer, hipernadzorcę i aplikację, które potrzebują danych.

Następnie oddziel przeglądanie przez ludzi od dostępu maszyna-maszyna. Użytkownicy domowi zazwyczaj korzystają z kont SMB i znanych przeglądarek plików. Zarządzane usługi Linux mogą korzystać z montowań NFS i kontroli tożsamości numerycznej.

Przed włączeniem ostatecznego udziału odpowiedz na te pytania:

1. Czy użytkownicy Windows lub macOS przeglądają pliki?
2. Czy telefony lub aplikacje telewizyjne potrzebują bezpośredniego dostępu?
3. Czy większość klientów to zarządzane systemy Linux?
4. Czy wartości UID i GID mogą pozostać spójne?
5. Czy obciążenie obejmuje bazy danych lub pliki wrażliwe na blokowanie?
6. Czy SMB i NFS będą zapisywać do tego samego zestawu danych?
7. Jak powinien zachowywać się montaż, gdy NAS jest niedostępny?
8. Czy wybrany protokół może być całkowicie wyłączony z publicznego internetu?

Dla większości domów z różnymi urządzeniami zacznij od SMB. Dodaj NFS tylko dla konkretnego obciążenia Linux, Proxmox, kopii zapasowej lub kontenera, które na tym korzystają i które możesz konsekwentnie zarządzać.

Ostateczne wnioski

SMB jest zwykle lepszym domyślnym wyborem dla Windows, macOS, telefonów, tabletów, smart TV i współdzielonych folderów rodzinnych. Oferuje szeroką kompatybilność i model dostępu oparty na kontach, który jest łatwiejszy do wyjaśnienia użytkownikom domowym.

NFS często lepiej pasuje do serwerów Linux, pamięci Proxmox, automatycznych kopii zapasowych i innych przepływów pracy maszyna-maszyna. Jego zalety zależą od poprawnego zarządzania wartościami UID/GID, eksportami, opcjami montowania i własnością.

Możesz używać obu protokołów w domu, ale ich role powinny być jasne. Używaj SMB dla ludzi i mieszanych urządzeń klienckich, NFS dla zarządzanej infrastruktury Linux i unikaj dawania obu protokołom niekontrolowanego dostępu do zapisu do tego samego zestawu danych.

FAQ

Czy NFS jest zawsze szybszy niż SMB?

Nie. NFS może działać lepiej w niektórych zastosowaniach Linux-to-Linux i przy małych plikach, podczas gdy nowoczesny SMB może działać bardzo dobrze na Windows i w sieciach z różnymi klientami. Przetestuj faktyczne pliki, klientów, pamięć i sieć, które planujesz używać.

Czy powinienem używać SMB czy NFS dla Plex i Jellyfin?

Oba mogą działać. Serwer multimedialny Linux może skorzystać z NFS podczas dużych skanów biblioteki, podczas gdy SMB może być łatwiejszy, gdy systemy Windows, macOS lub aplikacje odtwarzaczy multimedialnych bezpośrednio uzyskują dostęp do NAS. Duże strumieniowanie wideo zwykle działa dobrze na obu.

Czy NFS jest lepszy dla Proxmox?

NFS jest popularnym i naturalnym wyborem dla kopii zapasowych Proxmox, przechowywania ISO, szablonów i współdzielonej pamięci masowej. Dyski maszyn wirtualnych i obciążenia o dużej liczbie zapisów wymagają jednak testów pod kątem opóźnień, zachowania synchronizacji i dostępności NAS.

Czy kontenery Docker mogą korzystać z udziałów SMB?

Tak. Zamontuj udział SMB na hoście Dockera i podłącz wynikową ścieżkę do kontenera. Upewnij się, że użytkownik kontenera ma uprawnienia do dostępu do zamontowanych plików oraz że montowanie na hoście jest dostępne przed uruchomieniem kontenera.

Dlaczego NFS pokazuje odmowę dostępu, mimo że udział jest zamontowany?

Ścieżka eksportu i sieci może być poprawna, ale UID/GID klienta nie pasuje do właściciela lub dozwolonej grupy na NAS. Root squashing lub mapowanie eksportu może również zmienić efektywnego użytkownika.

Czy mogę włączyć SMB i NFS na tym samym folderze?

Możesz, ale jednoczesny dostęp do zapisu może powodować konflikty własności, ACL i atrybutów rozszerzonych. Lepiej używać oddzielnych zestawów danych, ustawić jeden protokół jako tylko do odczytu lub stworzyć starannie dopasowany model uprawnień współdzielonych.

Który protokół jest bezpieczniejszy w domu?

Oba można zabezpieczyć w zaufanej sieci LAN. SMB oferuje prostą autoryzację użytkownika oraz nowoczesne podpisywanie lub szyfrowanie. NFS powinien być ograniczony do zaufanych klientów, z poprawnymi regułami eksportu i root squashingiem. Żaden z nich nie powinien być bezpośrednio wystawiony do internetu.

Który protokół powinien wybrać początkujący?

Wybierz SMB, gdy w domu są systemy Windows, macOS, telefony lub aplikacje na telewizor. Wybierz NFS, gdy klientami są głównie systemy Linux i czujesz się komfortowo zarządzając montowaniami, wartościami UID/GID oraz uprawnieniami eksportu.