Od momentu publikacji dokonałem edycji tego wpisu - zmieniłem linię do dodania do pliku /etc/fstab, a także jej opis.

Dzień dobry, w tym dziewiczym wpisie opiszę pokrótce jak wziąłem porzucony komputer i zrobiłem z niego domowy dysk sieciowy.

użyte sprzęty i oprogramowanie

  • router Linksys EA6350 v4 z zainstalowaną najnowszą wersją OpenWrt (24.10)
  • komputer Lenovo ThinkStation M93p Tiny
    • Intel i5-4590T, RAM 8 GB, dysk SSD WD RED 500 GB
    • system operacyjny RHEL 9.5
      • zainstalowany jako Server with GUI z dodatkowym pakietem oprogramowania File and Storage Server
      • Red Hat udostępnia bezpłatną licencję na 16 instalacji RHEL, dlatego zdecydowałem się na ten system
        • proces zadziała również na kompatybilnych z RHEL systemach, takich jak Rocky Linux lub AlmaLinux
    • połączony z siecią lokalną po kablu Ethernet
      • początkowo był połączony po Wi-Fi, ale transfery były dramatyczne
      • nazwa serwera w sieci to NAS
  • komputery użytkowników łączących się z NASem stoją na Fedorze

przygotowania

router

Zanim zabrałem się do konfigurowania dysku sieciowego, skonfigurowałem swój router zgodnie z głosem mojego serca. Mój router obsługuje OpenWrt, dzięki czemu jestem dość spokojny o bezpieczeństwo sieci. Jeśli twój router to nieaktualizowany przez producenta relikt, ale jest wspierany przez społeczność i nie masz nic do stracenia (szczególnie czasu), to rozważ postawienie na nim OpenWrt. Jak nie, to kup coś nowego, najlepiej takiego z dobrym wsparciem producenta (np. Mikrotik, choć te podobno są nieco skomplikowane w obsłudze).

W przypadku OpenWrt, wszystko udało mi się zrobić w GUI.

Co konkretnie zrobiłem:

  • ustawiłem mocne hasło (z szyfrowaniem WPA3) do sieci oraz do konta admina routera
  • zadbałem o aktualne oprogramowanie
  • utworzyłem sieć WI-Fi dla gości, żeby chwilowi użytkownicy byli odseparowani od głównej sieci z dyskiem sieciowym
  • ustawiłem statyczne przydzielanie jednego adresu IP (w sieci lokalnej) dla adresu MAC mojego serwera (DHCP static lease)
    • nie wyłączałem DHCP, nie było takiej potrzeby

komputer

Użyty przeze mnie komputer prawdopodobnie pobiera nieco więcej prądu niż wyspecjalizowany serwer NAS oraz potrafi szumieć w przypadku nagłego zapotrzebowania na moc. W celu ustabilizowania poboru energii oraz zmniejszenia ryzyka głośnej pracy, w UEFI wyłączyłem dla procesora tryb Turbo, a w systemie operacyjnym ustawiłem profil zasilania powersave używając narzędzia tuned (o czym później).

W takiej konfiguracji komputer pobiera około 9 W w trybie bezczynności, a w przypadku zapotrzebowania na moc - mniej więcej 20 W.

konfiguracja systemu operacyjnego serwera

  • główny użytkownik komputera nazywa się admin i ma ustawione mocne hasło
    • ustawienie zajebiście silnego hasła i skonfigurowanie klucza SSH to jeszcze lepszy pomysł
  • eksportowanym do sieci położeniem jest /home/exports/main
  • początkowo system konfigurowałem korzystając ze standardowego środowiska graficznego (GNOME)
    • gdy skończyłem konfigurację, wyłączyłem usługi dotyczące GNOME, bo nie ma potrzeby, żeby środowisko graficzne na okrągło działało, skoro finalnie urządzenie nie będzie podłączone do żadnego monitora i będzie zarządzanie po SSH w sieci lokalnej

Wszystkie czynności wykonywałem jako root (sudo -i).

ustawienie profilu zasilania

  1. aktywowanie systemowej usługi tuned
  2. trwałe wyłączanie gnomowych trybów zasilania
  3. ustawianie profilu oszczędzania energii w tuned
systemctl enable --now tuned
systemctl mask --now power-profiles-daemon
tuned-adm profile powersave
  • do zarządzania poborem mocy przez komputer użyłem tuned, który domyślnie jest wyłączony, ponieważ GNOME posiada swoją własną usługę do zarządzania trybami zasilania (power-profiles-daemon.service)
    • power-profiles-daemon.service siłowo wyłącza tuned podczas każdego restartu systemu (patrz: baza wiedzy Red Hat[1]), co trzeba było dodatkowo skorygować

utworzenie współdzielonego położenia

  1. tworzę grupę nas-users o GID 1234, która będzie właścicielem folderu współdzielonego
  2. dodaję admina do grupy nas-users
  3. tworzę folder do udostępnienia i nadaję odpowiednie uprawnienia
  4. w udostępnianym folderze tworzę jakiś plik - pozwoli to na łatwe sprawdzenie, czy zdalne położenie odpowiednio się montuje u użytkowników
    1. polecenie wykonuje jako użytkownik admin, bo inaczej mogę mieć problem z usunięciem pliku z komputera użytkownika
groupadd -g 1234 nas-users
usermod -aG nas-users admin
mkdir /home/exports/main
chown admin:nas-users /home/exports/main
chmod 3770 /home/exports/main
sudo -u admin touch '/home/exports/main/witam w nasa'
  • użytkownicy podłączeni do sieci lokalnej też będą musieli być dodani do grupy o takim GID, żeby mieć uprawnienia do tego miejsca
  • chown admin:nas-users ... - właścicielem miejsca staje się admin, a grupą posiadającą nas-users
  • chmod 3770 - nadanie uprawnień
    • 3___ - SetGID + sticky bit, czyli każdy utworzony wewnątrz plik będzie miał grupę nas-users jako właściciel oraz użytkownicy będą mogli usuwać tylko pliki, które oni utworzyli (o ich UID)
      • to ostatnie nie zawsze może będzie działać zgodnie z oczekiwaniami - o czym później
    • _770 - właściciel i grupa posiadająca mogą dowolnie korzystać z położenia, pozostali nie będą mieli żadnego dostępu

konfigurowanie i uruchamianie usługi NFS

Najpierw instaluję brakujące oprogramowanie:

dnf install nfs-utils

Potem konfiguruję NFSv4 (z wyłączoną obsługą NFSv3, bo nie była mi potrzebna). Część kroków bezmyślnie skopiowana z dokumentacji RHEL 9[2].

nano /etc/nfs.conf    # w nfs.conf znalezienie linii z 'vers3' i ustawienie 'vers3=n'
systemctl mask --now rpc-statd.service rpcbind.service rpcbind.socket
mkdir -p /etc/systemd/system/nfs-mountd.service.d
nano /etc/systemd/system/nfs-mountd.service.d/v4only.conf    # patrz niżej
systemctl daemon-reload
systemctl restart nfs-mountd

Taka ma być zawartość pliku v4only.conf:

[Service]
ExecStart=
ExecStart=/usr/sbin/rpc.mountd --no-tcp --no-udp

Potem tworzę plik konfiguracyjny z opisanym położeniem do udostępnienia:

nano /etc/exports.d/home-nas.exports
  • może nazywać się inaczej (nie musi być home-nas), ale musi mieć rozszerzenie .exports
  • u mnie zawiera jedną linię - /home/exports/main 192.168.1.0/24(rw)
    • oznacza ona udostępnienie miejsca /home/exports/main dla wszystkich urządzeń w sieci 192.168.1.0 z zezwoleniem do odczytu i zapisu
      • dostosuj tę linię tak, żeby pasowała po twojego położenia i adresu sieci
    • trzeba pamiętać o dopisaniu maski, np. /24, bo inaczej nie będzie działać

Usługa NFS jest skonfigurowana.

Następny krok to skonfigurowania zapory sieciowej, żeby dopuszczała ruch NFS. Przy okazji upewniam się, że SSH też będzie dla mnie dostępne.

firewall-cmd --set-default-zone=home
firewall-cmd --permanent --add-service nfs
firewall-cmd --permanent --add-service ssh
firewall-cmd --reload
  • w RHEL do zarządzania zaporą sieciową służy firewall-cmd, czyli interfejs dla firewalld
  • w zaporze ustawiam strefę home (domyślnie było public), bo serwer jest w mojej sieci domowej i tam ogólnie ma być dostępny
  • do strefy dodaję usługi nfs i ssh (ta druga już tam była, więc krok w zasadzie nadmiarowy) i przeładowuję konfigurację zapory sieciowej

Czas na ostatecznie aktywowanie serwera NFS:

systemctl enable --now nfs-server

Dla weryfikacji aktywowanych wersji NFS można sprawdzić zawartość /proc/fs/nfsd/versions. W moim przypadku jest tam -3 +4 +4.1 +4.2.

cat /proc/fs/nfsd/versions
# -3 +4 +4.1 +4.2

extra: aktywowanie Cockpitu

Cockpit[3] to interfejs graficzny otwierany w przeglądarce internetowej służący do zarządzania systemem. Jest on dostępny również dla RHEL 9 i możemy go aktywować. Może on ułatwić zarządzanie naszym komputerem gdy już będzie w swoim miejscu w domu, z dostępem tylko po sieci.

systemctl enable --now cockpit.socket
firewall-cmd --add-service=cockpit
firewall-cmd --add-service=cockpit --permanent

Po takim aktywowaniu, kokpit powinien być dostępny w przeglądarce na porcie 9090, czyli w moim przypadku w przeglądarce podaję adres nas:9090. Pojawi się komunikat o niezabezpieczonym połączeniu, ale dopóki serwer nie będzie udostępniany na zewnątrz (poza sieć domową), nie ma potrzeby tworzenia certyfikatu.

extra: skrypt odświeżający ilość wolnego miejsca na dysku

Chciałem mieć możliwość łatwego sprawdzenia ilości dostępnego miejsca na dysku. W tym celu utworzyłem skrypt cron o nazwie check-avail-space.sh i wrzuciłem go do folderu /etc/cron.hourly. Trzeba plikowi nadać też uprawnienie do wykonywania (chmod +x /etc/cron.hourly/check-avail-space.sh). Skrypt w takim miejscu jest wywoływany co godzinę.

#!/bin/bash

SAVE_TO='/home/exports/main/Dostępne miejsce.txt'

echo "Czas sprawdzenia: $(date)" > "$SAVE_TO"
echo >> "$SAVE_TO"
df -h --output=size,used,avail /dev/mapper/rhel-home >> "$SAVE_TO"

chown admin "$SAVE_TO"

exit 0

Przykładowa zawartość pliku Dostępne miejsce.txt:

Czas sprawdzenia: pią, 27 lut 2025, 17:01:01 CET

rozm. użyte dost.
 387G   99G  288G

wyłączanie GUI

Po zweryfikowaniu, że do serwera mogę się zalogować po SSH uznałem, że jest on gotów do odłożenia go do kąta, gdzie nie będę miał już do niego łatwego dostępu, a więc graficzny pulpit przestaje mi być potrzebny.

systemctl set-default multi-user.target

Po wykonaniu tego polecenia, podczas następnego uruchomienia komputera nie będzie się już ładował interfejs graficzny. Można teraz wyłączyć komputer, podłączyć go w miejscu docelowym (w tym do sieci) i tam uruchomić.

konfigurowanie komputerów użytkowników

Skonfigurowanie systemów użytkowników to już znacznie mniej kroków. Nie konfigurowałem położenia na Windowsie, tylko na Fedorze (Linux), więc nie wiem jeszcze na ile to trudne i czy wymaga dodatkowej konfiguracji na serwerze.

Wszystkie polecenia wykonywałem jako root (sudo -i).

utworzenie grupy nas-users

Zdalne położenie jest ustawione, żeby dostęp do niego miały tylko osoby będące członkami grupy o GID 1234. Choć nazwa tej grupy nie ma znaczenia (liczą się identyfikatory), to dla spójności wszędzie ta grupa ma taką samą nazwę, czyli nas-users.

groupadd -g 1234 nas-users
usermod -aG nas-users bartek	# dodaje użytkownika bartek do grupy nas-users

konfiguracja montowania

Najpierw instaluję oprogramowanie:

dnf install nfs-utils

Potem tymczasowo sprawdzam czy zdalne położenie jest dostępne i montuje się elegancko, a w zamontowanym położeniu odnajduję zrobiony przeze mnie plik witamy w nasa. Folder do zamontowania (nas-test) musi już wcześniej istnieć.

mount -t nfs4 -o rw,sync NAS:/home/exports/main /home/bartek/nas-test

Jak działa, to można odmontować miejsce:

umount /home/bartek/nas-test

Teraz konfiguruję automounter systemd (na tym etapie zakładam, że Twój system ma systemd). Automounter sprawia, że niedostępność zdalnego miejsca podczas ładowania systemu nie spowoduje zatrzymania uruchamiania systemu i wejścia w tryb awaryjny.

Miejsce będzie u mnie montowane w /home/bartek/NAS. Ogólnie ścieżka do naszego miejsca lokalnego nie powinna mieć ani spacji, ani specjalnych znaków (takich jak polskie znaki lub emoji), bo inaczej wygenerowana jednostka systemd ma posraną nazwę (przykład niżej).

mkdir /home/bartek/NAS
nano /etc/fstab

Do /etc/fstab dodajemy na samym końcu linię:

NAS:/home/exports/main /home/bartek/NAS nfs vers=4,rw,sync,user,x-systemd.automount,x-systemd.device-timeout=3,x-systemd.mount-timeout=3 0 0

znaczenie pól - od lewej (pola oddzielone są spacjami, ale taby też działają):

  1. miejsce źródłowe, czyli miejsce na serwerze
  2. miejsce docelowe, czyli gdzie ma zamontować na naszym komputerze
  3. rodzaj montowanego położenia (tutaj: nfs)
  4. rw,sync,user,x-systemd.automount,x-systemd.device-timeout=3,x-systemd.mount-timeout=3
    1. vers=4 - sprecyzowanie protokołu NFS
    2. rw - montowanie do odczytu i zapisu
    3. sync - podczas kopiowania do serwera od razu zapisuje informacje na dysku docelowym (nie trzyma danych w buforze)
      1. zalecane dla NASów, bo zapobiega utracie danych gdy, przykładowo, zabraknie nam prądu
    4. user - położenie może montować zwykły użytkownik
    5. x-systemd.automount - wykorzystanie systemu systemd.automount
    6. x-systemd.device-timeout=3, x-systemd.mount-timeout=3 - ustawienie limitów czasowych (w sekundach) na wypadek gdy nasz serwer jest niedostępny
      1. bez tego, gdy serwer nie jest osiągalny, przeglądarka plików zwiesza się na śmierć
  5. 0 0 to dodatkowe pola konfiguracyjne
    1. pierwsze 0 dotyczy programu dump, który nie jest wykorzystywany w przypadku NFS
    2. drugie 0 dotyczy funkcji fsck do sprawdzania systemu plików, który nie jest wykorzystywany w przypadku NFS (ani XFS, z którego korzysta RHEL)

Po dopisaniu tej linii w /etc/fstab, wywołaj systemctl daemon-reload. Po takim poleceniu, systemd generuje plik dla konfiguracyjny naszego położenia, którego nazwa jest na podstawie pełnej ścieżki - tutaj jest to home-bartek-NAS.automount. Teraz jeszcze tylko rzeczywiste utworzenie folderu NAS w naszym katalogu domowym, restart systemu (lub systemctl start home-bartek-NAS.automount) i nasz trud skończon.

gdy nazwa dysku dla automountera ma znaki specjalne

A propos niestandardowych nazw położeń - dla przykładowego folderu /home/bartek/Łódka🛥️ (czyli polskie znaki + emoji) wygenerowany plik systemd miałby nazwę home-bartek-\xc5\x81\xc3\xb3dka\xf0\x9f\x9b\xa5\xef\xb8\x8f.automount:

# systemctl status "home-bartek-\xc5\x81\xc3\xb3dka\xf0\x9f\x9b\xa5\xef\xb8\x8f.automount"
○ home-bartek-\xc5\x81\xc3\xb3dka\xf0\x9f\x9b\xa5\xef\xb8\x8f.automount
     Loaded: loaded (/etc/fstab; generated)
     Active: inactive (dead)
   Triggers: ● home-bartek-\xc5\x81\xc3\xb3dka\xf0\x9f\x9b\xa5\xef\xb8\x8f.mount
      Where: /home/bartek/Łódka🛥️
       Docs: man:fstab(5)
             man:systemd-fstab-generator(8)

Mało przyjazna.

mowa końcowa

Tak utworzony serwer nie tylko będzie mógł być serwerem plików, ale będzie można na nim udostępniać dodatkowe oprogramowanie, np. Jellyfin (tak sądzę - jeszcze nie próbowałem).

Należy pamiętać o co najmniej kilku konsekwencjach postawienia takiego serwera i skonfigurowania takiego folderu na naszym komputerze:

  • gdy ma się oprogramowanie do synchronizacji danych (np. FreeFileSync lub PikaBackup), to będzie robił kopię zapasową również tego położenia
    • niewykluczone, że będzie można tego uniknąć, gdy na naszym komputerze miejsce będziemy montować poza naszym katalogiem domowym, a potem utworzyć do niego link
    • ewentualnie - po prostu dodajmy regułę, żeby to położenie omijał
  • nie można zmieniać nazwy miejsca dla NASa na komputerach użytkowników, bo montowanie przestanie działać
    • ten problem można ominąć linkiem wspomnianym w punkcie wyżej
  • uprawnienia w Linuksie są przypisane do dla UID i GID, a nie do nazwy użytkownika, co oznacza, że sticky bit nie zawsze będzie działał zgodnie z oczekiwaniami
    • wymyślony przykład
      • w domu są dwa komputery - jeden Adama, drugi Zdzicha
      • zarówno Adam jak i Zdzichu mają UID 1000 na swoich komputerach, bo taki jest zazwyczaj domyślny pierwszy UID
      • w związku z tym, utworzone przez nich na serwerze pliki będą miały przypisane UID 1000, co oznacza, że z perspektywy Adma, on jest użytkownikiem swoich plików, ale też tych utworzonych przez Zdzicha. Analogicznie będzie z perspektywy Zdzicha - to on, nie Adam, będzie właścicielem wszystkich plików
      • oznacza to, że mimo sticky bit, Adam będzie mógł usuwać nieswoje pliki
      • aby temu zapobiec, Adam i Zdzichu (i każdy inny użytkownik NASa) powinien mieć inne UID - wtedy sticky bit rzeczywiście zabezpiecza przed usunięciem nieswoich plikóœ
  • należy regularnie aktualizować i restartować serwer
  • należy tworzyć kopie zapasowe plików na serwerze!

  1. https://access.redhat.com/solutions/7047942 ↩︎

  2. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_using_network_file_services/deploying-an-nfs-server_configuring-and-using-network-file-services#configuring-an-nfsv4-only-server_deploying-an-nfs-server ↩︎

  3. https://cockpit-project.org/ ↩︎

❦Koniec.

Wziąłem stary komputer i zrobiłem z niego NASa [aktualizacja]