TrueNAS #01 - Tworzymy własny serwer plików (NAS) z wykorzystaniem TrueNAS i Proxmox-a

TrueNAS #01 - Tworzymy własny serwer plików (NAS) z wykorzystaniem TrueNAS i Proxmox-a

Dariusz Luber
Dariusz Luber
📺

Wolisz wideo?

Przejdź do sekcji wideo

Video i ten wpis uzupełniają się nawzajem, dlatego dla najlepszego efektu skorzystaj z obu źródeł 😊

Macierz dyskowa (NAS - Network Attached Storage) chroni Wasze dane przed awarią pojedynczego dysku - jeśli jeden, dwa albo trzy dyski padną (zależnie od konfiguracji), danych nie stracicie. To jednak nie jest backup. Redundancja na NAS-ie nie uratuje Was przed przypadkowym skasowaniem plików czy ransomware - kopia zapasowa musi istnieć osobno, w innym miejscu.

TL;DR

  • TrueNAS instalujecie jako VM na Proxmoxie, ale dane trzymacie na dyskach przekazanych bezpośrednio (Disk Passthrough) - nie na wirtualnych .qcow2.
  • Trzy pułapki, które najczęściej psują pierwsze podejście: zaznaczone Pre-Enrolled keys (Secure Boot blokuje boot), domyślna karta graficzna (zamrożony/czarny ekran instalatora) i brak parametru serial przy przekazywaniu dysków (TrueNAS nie utworzy puli bez unikalnych numerów seryjnych).
  • Pamięć RAM ustawcie na sztywno i wyłączcie Ballooning - ZFS zakłada wyłączną kontrolę nad RAM-em (cache ARC), w przeciwnym razie grozi to kernel panic.
  • Dyski w jednej puli ZFS muszą mieć tę samą pojemność - mniejszy dysk obcina wszystkie pozostałe do swojego rozmiaru.
  • Po utworzeniu puli nie udostępniacie całego dysku - tworzycie DataSety, użytkowników tylko do SMB i nadajecie im uprawnienia (ACL).

1) TrueNAS SCALE czy CORE?

TrueNAS SCALE (bazujący na Debianie, podobnie jak Proxmox) to obecnie lepszy wybór niż starsza wersja CORE - pozwala łatwo skalować pulę, dokładając pojedyncze dyski, bez przebudowywania całej macierzy i przenoszenia danych. CORE bywa w tym względzie bardziej sztywny.

Sercem obu wersji jest ZFS - system plików, który natywnie dba o integralność danych, koryguje błędy w locie i obsługuje migawki (snapshots).

Złota zasada: ZFS został zaprojektowany, by rozmawiać bezpośrednio z fizycznym sprzętem. Nie twórzcie wirtualnych dysków (.qcow2) pod dane - użyjcie Disk Passthrough.

2) Wymagania i pobranie obrazu ISO

Minimalne wymagania dla VM z TrueNAS:

  • RAM: min. 8 GB - ZFS zużywa RAM jako pamięć podręczną ARC (Adaptive Replacement Cache), czyli trzyma w niej najczęściej używane dane i metadane, żeby czytać je błyskawicznie z pamięci zamiast za każdym razem sięgać na wolniejszy dysk; im więcej RAM-u, tym większy i skuteczniejszy cache.
  • CPU: min. 2 rdzenie, typ Host.
  • Dysk systemowy: ok. 32 GB, wyłącznie pod system operacyjny (dane trzymacie na osobnych dyskach).

Pobranie ISO najwygodniej zrobić bez pośredniego kroku „pobierz na dysk → wgraj do Proxmoxa”:

  1. Na stronie TrueNAS skopiujcie link do wybranego obrazu .iso (prawy klawisz → Copy link), zamiast go od razu pobierać.
  2. W Proxmoxie: Datacenter → wasz node → local → ISO Images → Download from URL, wklejcie link i zatwierdźcie.
  3. Proxmox pobierze plik bezpośrednio na storage - oszczędzacie sobie ręcznego uploadu.

Zwróćcie uwagę na wersję: na stronie pobierania TrueNAS widać, która wersja jest aktualnie stabilna (oznaczona jako General), a która to nowsza wersja dla early adopterów. Do domowego NAS-a, na którym ma leżeć realne dane, wybierajcie stabilną.

3) Tworzenie maszyny wirtualnej w Proxmoxie

  • Create VM → nadajcie ID i nazwę (np. TrueNAS), zaznaczcie Start at boot.

  • OS: wskażcie pobrane ISO TrueNAS, Type: Linux.

  • System: zmieńcie BIOS z SeaBIOS na OVMF (UEFI) - wymagane przez TrueNAS do poprawnego bootowania i obsługi nowych tablic partycji (Machine type automatycznie przełączy się na q35). Dodajcie dysk EFI.

    Krytyczne: przy dodawaniu dysku EFI odznaczcie Pre-Enrolled keys. Zaznaczenie tej opcji włącza Secure Boot i wgrywa certyfikaty zaufania (m.in. Microsoftu) - instalator TrueNAS ich nie rozpozna i odmówi bootowania (Failed to Load). Zostawcie puste - TrueNAS zaufa dyskowi i wgra tam własny bootloader GRUB.

  • Kontroler SCSI: VirtIO SCSI single.

  • Graphic card: zmieńcie na VirtIO-GPU - domyślna karta bywa niekompatybilna i potrafi zawiesić lub zaciemnić ekran instalatora/konsoli TrueNAS.

  • Disks: dysk systemowy ~32 GB.

    • Cache: No cache (unika podwójnego buforowania przez hosta i gościa; TrueNAS sam zarządza zapisem) lub opcjonalnie Write back (szybszy zapis kosztem bezpieczeństwa przy nagłym zaniku zasilania).
    • Zaznaczcie Discard, jeśli Proxmox stoi na SSD/NVMe - włącza TRIM, wydłuża żywotność nośnika.
  • CPU: min. 2 rdzenie, Type: Host - daje bezpośredni dostęp do instrukcji fizycznego CPU, co realnie przyspiesza operacje na macierzy i szyfrowanie dysków (emulowany typ byłby tu zauważalnie wolniejszy).

    Koszt wyboru Host: trudniejsza migracja na żywo (HA) między węzłami klastra. W tym scenariuszu to żaden problem - skoro i tak przekazujecie fizyczne dyski (Disk Passthrough), VM nie da się migrować na inny host bez tych samych dysków. Niezawodność (HA) dla NAS-a realizujecie inaczej: drugi fizyczny TrueNAS na innym hoście oraz natywna replikacja ZFS.

  • Memory: odznaczcie Ballooning, wpiszcie twardą wartość, np. 8192 MB (orientacyjnie ok. 1 GB RAM na 1 TB przestrzeni w puli - jeśli macie więcej RAM-u, przydzielcie więcej, poprawi to działanie cache'u).

    Dlaczego to ważne? Tę przydzieloną pamięć ZFS trzyma pod swoim wyłącznym zarządem jako ARC (Adaptive Replacement Cache) - opisany w sekcji 2 mechanizm cache'owania, dzięki któremu odczyt najczęściej używanych danych i metadanych dzieje się z RAM-u, a nie z wolniejszego dysku. Włączony Ballooning oznacza, że Proxmox dynamicznie zabiera/oddaje RAM w locie - dla ZFS to katastrofa: spadki wydajności, a w skrajnym przypadku kernel panic i uszkodzenie danych.

  • Network: zostawcie VirtIO (paravirtualized).

Po zamknięciu kreatora nie startujcie jeszcze VM - najpierw Disk Passthrough.

4) Disk Passthrough - przekazywanie fizycznych dysków

W konsoli (Shell) węzła Proxmox:

ls -l /dev/disk/by-id/ | grep -v "-part"

Dopisek | grep -v "-part" ukrywa partycje i zostawia czystą listę urządzeń. Szukajcie dysków przeznaczonych na dane (zwykle ata-... lub nvme-...) i skopiujcie ich pełne ścieżki - numer seryjny, który zaraz wpiszecie w komendzie qm set, to najczęściej po prostu ostatni człon tej samej nazwy, po myślniku (np. w ata-WDC_WD40EFRX-...-WD-XXXXXXXXX będzie to WD-XXXXXXXXX).

Podepnijcie je pod VM (zastąpcie 102 swoim ID maszyny):

qm set 102 -scsi1 /dev/disk/by-id/ata-nazwa-dysku-1,serial=NUMER_SERYJNY_1
qm set 102 -scsi2 /dev/disk/by-id/ata-nazwa-dysku-2,serial=NUMER_SERYJNY_2

Parametr serial jest obowiązkowy. Numer seryjny widać zwykle jako ostatni człon nazwy by-id (po myślniku) albo na naklejce dysku. Bez niego TrueNAS widzi tylko generyczne „dyski QEMU” - w nowszych wersjach systemu brak unikalnych numerów seryjnych całkowicie blokuje utworzenie puli, bo TrueNAS nie potrafi jednoznacznie odróżnić dysków od siebie. Przy awarii numer seryjny w interfejsie od razu wskaże, który dysk wymienić.

Podpięte dyski zobaczycie od razu w zakładce Hardware maszyny wirtualnej.

5) Częste błędy przy pierwszym uruchomieniu

Dwa problemy pojawiają się na tyle często, że warto je znać zanim wystąpią:

  • Failed to Load / instalator nie startuje - to efekt zaznaczonej opcji Pre-Enrolled keys przy dysku EFI (patrz sekcja 3). Aby naprawić zatrzymajcie VM (Stop, nie Restart), usuńcie dysk EFI, dodajcie go ponownie z odznaczoną opcją Pre-Enrolled keys, uruchomcie ponownie.
  • Zamrożony lub czarny ekran instalatora - to niekompatybilna karta graficzna. Zatrzymajcie VM, w Hardware zmieńcie Graphic card na VirtIO-GPU, uruchomcie ponownie.

Jeśli po podłączeniu dysków bez parametru serial TrueNAS odmawia utworzenia puli: zatrzymajcie VM, odepnijcie (Detach) i usuńcie dyski w Hardware, powtórzcie komendy qm set z dopisanym ,serial=..., uruchomcie VM ponownie.

6) Instalacja TrueNAS

  1. Start → Console.
  2. Wybierzcie Install/Upgrade.
  3. Jako dysk docelowy wskażcie mały wirtualny napęd systemowy (32 GB, zwykle sda/vda) - nie wybierajcie tu przekazanych dysków na dane.
  4. Ustawcie silne hasło dla konta truenas_admin.
  5. Potwierdźcie bootowanie w trybie EFI/UEFI i poczekajcie na koniec instalacji.
  6. System poprosi o restart - w Hardware → CD/DVD Drive wybierzcie Do not use any media, usuńcie zamontowane ISO i zrestartujcie VM.

Po restarcie na konsoli zobaczycie adres IP przydzielony przez DHCP (np. http://192.168.1.50) - wejdźcie na niego z przeglądarki i zalogujcie się jako truenas_admin.

Każdy z dostępem do konsoli VM w Proxmoxie ma też bezpośredni dostęp do konsoli TrueNAS bez dodatkowego logowania - pilnujcie, kto ma dostęp do samego Proxmoxa.

7) Tworzenie puli (Pool) i wybór topologii VDEV

Storage → Create Pool. Interfejs sam wykryje przekazane dyski wraz z numerami seryjnymi. Do wyboru macie m.in.:

  • Stripe - dyski po prostu sumują pojemność, brak redundancji. Awaria jednego dysku = utrata wszystkich danych w puli. Odradzane dla danych, które chcecie zachować.
  • Mirror (RAID 1) - pełna kopia na min. 2 dyskach. Awaria jednego dysku nie kosztuje Was danych.
  • RAID-Z1 (RAID 5) - pojemność jednego dysku idzie na dane kontrolne (tzw. parzystość), z których ZFS odtworzy zawartość w razie awarii. Min. 3 dyski, przetrwa awarię jednego napędu.
  • RAID-Z2 (RAID 6) - to samo, ale na danych kontrolnych "tracicie" pojemność dwóch dysków. Min. 4 dyski, przetrwa jednoczesną awarię dwóch napędów.

Pułapka rozmiaru dysków: wszystkie dyski w puli muszą mieć tę samą pojemność. Zmieszacie np. dwa dyski 4 TB z jednym 2 TB? ZFS obetnie wszystkie do 2 TB - nadwyżka przepada, dopóki nie wymienicie najmniejszego dysku na większy.

Deklarowane a rzeczywiste TB: producenci często liczą 1 TB jako 1000 GB (dziesiętnie), a ZFS raportuje w jednostkach binarnych (TiB) - dysk „4 TB” pokaże się w puli jako ok. 3,64 TiB. To normalne, nie błąd.

Opcjonalnie, przy większej liczbie dysków, dostępne są jeszcze: dysk Spare (stoi w gotowości i automatycznie zastępuje uszkodzony dysk w puli - przydatne, gdy nie macie fizycznego dostępu do serwera na bieżąco), oraz osobne dyski (najlepiej SSD/NVMe) pod Cache/L2ARC i metadane, przyspieszające odczyt/zapis.

Włączcie Encryption, jeśli w puli będą dane wrażliwe - bez klucza nikt nie odczyta danych nawet mając fizyczny dostęp do dysków. Zatwierdźcie Create Pool (dyski zostaną wyczyszczone do zera - upewnijcie się, że wybraliście właściwe).

8) DataSety, użytkownicy SMB i uprawnienia (ACL)

Sama pula to fundament - całego dysku się nie udostępnia. Zamiast tego tworzycie DataSety: coś jak udostępnione katalogi, z których każdy może mieć własne limity miejsca, migawki, kompresję i uprawnienia. (Opcja Add Zvol obok DataSetu to co innego - wirtualny wolumen blokowy pod np. iSCSI, na razie ją pomijacie.)

Krok 1 - użytkownik tylko do SMB. Nie logujcie się do udziałów kontem truenas_admin. W Credentials → Users → Add utwórzcie konto (np. darek), ustawcie hasło i zaznaczcie Samba Authentication - bez tej flagi użytkownik nie zaloguje się do udziału sieciowego. Jeśli konto ma służyć wyłącznie do SMB, możecie pominąć tworzenie katalogu domowego i nie nadawać dostępu przez shell/SSH.

Krok 2 - DataSet. Storage → wasza pula → Add Dataset. Nadajcie nazwę (np. Home) i w Share Type wybierzcie SMB - TrueNAS dobierze wtedy parametry optymalne pod Windows (m.in. wyłącza wrażliwość na wielkość znaków). W Advanced Options warto też wyłączyć Enable Atime, jeśli używacie dysków talerzowych (HDD) - inaczej każdy odczyt pliku zapisuje log dostępu, co generuje zbędny ruch głowicy.

Krok 3 - udział SMB i ACL. Shares → Windows (SMB) Shares → Add, wskażcie DataSet. Przy pierwszym udostępnieniu system zapyta o konfigurację ACL. Typowe scenariusze:

  • Zasób prywatny: szablon Restricted, usuńcie domyślne grupy, zostawcie właściciela z Full Control. Reszta sieci nie ma dostępu.
  • Zasób współdzielony: szablon Open, dodajcie grupę builtin_users (trafiają tam wszyscy nowi użytkownicy lokalni) z uprawnieniem Modify.
  • Zasób tylko do odczytu (np. archiwum zdjęć): właściciel z Full Control, grupa builtin_users z Read - nikt przez pomyłkę nie skasuje zbiorów.
  • Zasób dla wybranych: szablon Restricted, właściciel z Full Control, Add Item → konkretny użytkownik (np. ania) z Read lub Modify. Reszta sieci nadal bez dostępu.

Nic nie stoi na przeszkodzie, by powtórzyć kroki 2–3 kilka razy i mieć osobne DataSety dla każdego domownika czy kategorii danych (Home, Kids, Videos) - każdy z własnymi uprawnieniami.

Podsumowanie i co dalej

Wirtualny TrueNAS z poprawnym Disk Passthrough i twardo przydzieloną pamięcią bez Ballooningu nie ustępuje fizycznemu NAS-owi ani stabilnością, ani wydajnością.

To dopiero początek możliwości. TrueNAS SCALE ma wbudowany katalog aplikacji, dzięki któremu na tym samym serwerze postawicie np. Immich - odpowiednik Zdjęć Google, z rozpoznawaniem twarzy i tagowaniem AI, ale działający wyłącznie lokalnie, na waszych dyskach. Zamiast wgrywać zdjęcia z telefonu do Google Photos czy pliki do Google Drive, trzymacie je u siebie - i to wy, a nie zewnętrzna firma, decydujecie, kto ma do nich dostęp. To jest prawdziwa siła posiadania własnego homelabu.

To TrueNAS #01 w osobnej serii TrueNAS. TrueNAS #02 będzie jednym łączonym filmem: krótko odeśle do osobnego artykułu o wymianie dysku, a główną część poświęci rozbudowie storage, użytkownikom, grupom, uprawnieniom i szyfrowaniu Datasetu.

Linki (oficjalne źródła)


Jeśli postawiliście już swoją pierwszą pulę ZFS, dajcie znać w komentarzu do filmu YT, jaką topologię wybraliście i na jakich dyskach działacie.


Ten wpis był pomocny? Postaw mi kawę, abym miał energię do tworzenia kolejnych treści.

Postaw mi kawę☕