Zabiłem subskrypcję Google Drive. Oto czym ją zastąpiłem i ile mnie to kosztowało.

1. Hetzner Storage Box — co to właściwie jest i czym nie jest
2. Pięć wymagań, które postawiłem rozwiązaniu
3. Co istnieje na rynku — przegląd narzędzi
4. Podejście pierwsze: HybridMount + Qsync — trick z symlinkami
5. Podejście drugie: rclone mount + Qsync
6. Przy okazji: mapa wewnętrznych folderów HybridMount
7. Rozwiązanie: Nextcloud jako brakujące ogniwo
8. Jak Nextcloud synchronizuje pliki — edukacyjna wycieczka pod maskę
9. Jak to wszystko działa razem — cache, FUSE i przezroczystość
10. Uczciwe wnioski — co zyskujesz, czego nie masz

Mam konto Google One (kto nie ma) ze skromnym limitem 200 GB dla całej rodziny. Kosztuje mnie ono na dzień publikacji tego artykułu niecałe 140 złotych rocznie, czyli jakieś 11,6 złotego miesięcznie. 200 GB dla całej rodziny to jednak nieco maławo, dlatego mam też OneDrive w ramach Microsoft 365 Family, które oferuje mi dla odmiany 1 terabajt miejsca dla każdego członka rodziny za około 56 złotych miesięcznie. I mam Hetzner Storage Box BX21 — 5 TB surowego miejsca na dysku w europejskim centrum danych, za 13,41 euro miesięcznie, co przy aktualnym kursie daje jakieś 58 złotych. Jak widać Hetzner Storage Box w kategorii koszt za terabajt jest po prostu nie do pobicia.

Z tych hetznerowych 5 terabajtów zajęte mam 2,5. Reszta czeka.

Czeka, bo przez długi czas używałem Storage Box wyłącznie jako cel backupów. Lądują tam kopie zapasowe moich usług chmurowych — Box, Dropbox, Google Drive, OneDrive — oraz najważniejsze dane z QNAP‑a, obsługiwane przez Hybrid Backup Sync 3. Hetzner Storage Box doskonale sprawdza się w tej solidnej, niezawodnej roli. Ale 2,5 TB wolnego miejsca na serwerze z macierzą RAID, automatycznymi snapshotami i dostępem przez pół tuzina protokołów aż się prosi, żeby to jakoś sensowniej wykorzystać.

Taki pomysł mi się urodził: a gdyby tak zrobić z tego własny odpowiednik Dysku Google?

Spoiler: nie jest to takie proste. Droga do czegokolwiek działającego prowadziła przez kilka ślepych uliczek, które warto znać zanim się w nie wejdzie. A na końcu tej drogi czekało rozwiązanie, którego się zupełnie nie spodziewałem.

Zanim przejdę do eksperymentów, kilka słów o samej usłudze, bo jej natura jest kluczem do zrozumienia całego problemu.

Hetzner Storage Box to nie jest chmura w stylu Google Drive czy OneDrive. To surowy dysk sieciowy — pojemna przestrzeń dyskowa na serwerach Hetznera, do której można się dostać przez kilka protokołów: SFTP, FTP, FTPS, SCP, Rsync, SMB/CIFS i WebDAV. Serwer jest zabezpieczony macierzą RAID, obsługuje snapshoty (do 40 slotów w zależności od planu), pozwala tworzyć subkonta z dostępem do podkatalogów i… to właściwie wszystko. Po prostu hektar stosunkowo niedrogiego miejsca, z którym czyń, co chcesz.

Ceny zaczynają się od 3,20 euro za 1 TB miesięcznie; przy moim pakiecie BX21 wychodzi 13,41 euro za 5 TB. Dla porównania: Google One 2 TB kosztuje w Polsce około 10 euro miesięcznie. Za nieco więcej mam u Hetznera ponad dwukrotnie więcej miejsca, własne snapshoty, pełną kontrolę nad danymi i serwery w Niemczech, co przy RODO ma znaczenie.

Ale nie jest tak kolorowo. Hetzner Storage Box nie oferuje fancy interfejsu webowego umożliwiającego dostęp do zgromadzonych plików, aplikacji mobilnej oraz — co najistotniejsze — klienta desktopowego z synchronizacją, placeholderami i dostępem offline do plików. Hetzner sprzedaje infrastrukturę, nie gotowy produkt konsumencki. I właśnie tu zaczyna się problem, bo ja chciałem produktu konsumenckiego, tyle że na własnym serwerze.

Warto wspomnieć, że Hetzner oferuje też rozwiązanie konsumenckie o nazwie Hetzner Storage Share — to sklejka usługi Storage Box z Nextcloud. Przerabiałem już podobne rozwiązanie od webh.pl i sprawuje się to całkiem spoko. Za kilka euro więcej (plan 5 TB pojemności z Nextcloud jako środowiskiem do zarządzania całością wychodzi 17,45 euro, a więc nieco ponad 75 złociszy) można mieć całkiem sensowną alternatywę dla Google Drive i zdecydowanie korzystniejszą finansowo. No ale ja mam inną usługę i tę chciałem zmusić do współpracy.

Dla ciekawskich podrzucam stronę, gdzie znajdą porównanie obydwu usług Hetznera i wskazanie różnic: https://docs.hetzner.com/storage/storage-box/faq/storage-box-vs-storage-share

Żeby Storage Box mógł zastąpić mi Google Drive w codziennym użytkowaniu, potrzebowałem spełnienia pięciu warunków jednocześnie:

1. Pliki widoczne bez pobierania treści — tak jak w Google Drive, gdzie widzę plik w folderze, ale nie zajmuje on miejsca na dysku dopóki go nie otworzę (tzw. placeholdery lub pliki na żądanie).
2. Pobieranie on-demand — treść pliku pobierana dopiero przy otwarciu.
3. Możliwość zwolnienia miejsca — oznaczenie wybranych plików do zachowania lokalnie, reszta tylko w chmurze.
4. Dostęp offline — wybrane pliki dostępne bez połączenia z siecią.
5. Cross-platform — działa na Windows, macOS i Linux jednakowo.

Brzmi rozsądnie. Okazało się jednak, że spełnienie wszystkich pięciu warunków jednocześnie (przynajmniej w moim środowisku i z moją wiedzą) jest albo bardzo drogie, albo niemożliwe, albo wymaga obejść.

Zanim wziąłem się za eksperymenty na własnym sprzęcie, zrobiłem mały research. Oto co znalazłem:

rclone mount + VFS

Rclone to open-source’owy kombajn do obsługi storage w chmurze, jak i udziałów sieciowych z ponad 70 backendami (sic!), w tym SFTP i WebDAV, a więc Hetzner Storage Box obsługuje bez problemu. Komenda rclone mount montuje zdalny zasób jako lokalny system plików przez FUSE, z trybami cache VFS: od off (streaming bezpośrednio z serwera) aż do full (pełny cache lokalny). Parametry --vfs-cache-max-size i --vfs-cache-max-age pozwalają automatycznie zwalniać miejsce po przekroczeniu dozwolonej objętości albo po ustalonym czasie. Działa na Windows (wymaga WinFsp), macOS (wymaga macFUSE) i Linux (FUSE natywnie).

Rclone to potężne narzędzie, ale to wirtualny mount przez FUSE, który nie oferuje prawdziwych placeholderów systemowych — raczej korzysta ze sparse files (tak zwanych plików rzadkich). Nie integruje się z Eksploratorem Windows czy Finderem na poziomie ikon statusu pliku. I — jak się okaże — posiada kluczowe ograniczenie architektoniczne, które wyjdzie przy próbie połączenia z Qsync. Warto też wspomnieć, że rclone oferuje transparentne szyfrowanie end-to-end, dzięki czemu możesz zaszyfrować pliki przed wysłaniem ich na serwer Hetznera. Więcej o szyfrowaniu przeczytasz tutaj: https://rclone.org/crypt/

Mountain Duck 5

Wydany w sierpniu 2025 roku, wprowadza tryb Integrated Connect Mode. Używa Cloud Files API na Windows i File Provider API na macOS — tych samych, których używa OneDrive i iCloud Drive. Efekt: prawdziwe placeholdery systemowe, ikony statusu w Eksploratorze i Finderze, opcja “Zwolnij miejsce” pod prawym klikiem myszy. Obsługuje SFTP i WebDAV, więc Hetzner Storage Box podłączyłby się bez problemu. Cena: 49 USD per seat — za każde urządzenie osobno. Mam kilka komputerów. Koszty rosną liniowo i szybko Mountain Duck 5 przestaje być atrakcyjny. Obsługi Linuksa brak.

Nextcloud

Nextcloud to platforma do self-hostingu danych, która z biegiem lat wyrosła z prostego narzędzia do synchronizacji plików w rozbudowany ekosystem. Dziś Nextcloud to nie tylko synchronizacja plików — to kalendarz, kontakty, edytor dokumentów online, zarządzanie projektami, wideokonferencje i dziesiątki innych aplikacji dostępnych przez App Store. Można go postawić na własnym serwerze, VPS-ie, Raspberry Pi czy właśnie na NAS-ie. Oficjalny klient desktopowy działa na Windows, macOS i Linux.

Z perspektywy synchronizacji plików Nextcloud oferuje mechanizm wirtualnych plików (VFS) na Windows i macOS — czyli dokładnie te placeholdery, których szukałem. Na Linuksie tej funkcji nie ma, issue na GitHubie jest otwarty od lat. Podpięcie Hetzner Storage Box jako external storage przez SFTP jest technicznie możliwe, ale znane z problemów ze stabilnością. Natomiast Storage Share to osobny produkt Hetznera, nie nakładka na Storage Box.

Qsync (QNAP)

Natywne narzędzie QNAP ma Space-Saving Mode, który używa Cloud Files API (Windows) i File Provider API (macOS). A więc Qsync oferuje prawdziwe placeholdery i całą resztę opcji znanych z klientów takich, jak Google Drive czy OneDrive. Poza tym jest bezpłatny (no, wliczony w cenę NAS‑a) i mocno wbudowany w ekosystem QNAP. Na Ubuntu działa, ale bez Space-Saving Mode. I wszystko wygląda na papierze pięknie, ale… jak diabeł z pudełka pojawia się kluczowe ograniczenie, o którym za chwilę.

Porównanie narzędzi

* na Ubuntu działa, ale bez Space-Saving Mode

Mój QNAP TS-664 ma zainstalowany HybridMount — aplikację do montowania zasobów zdalnych i usług chmurowych. Mam przez nią podłączone usługi Google Drive, OneDrive, Box i Dropbox w trybie Podłączenie dysku w chmurze (Cloud Drive Mount). Ten tryb podłączenia oznacza, że HybridMount montuje zasoby bez lokalnego cache, a dostęp do plików realizowany jest bezpośrednio przez API danej usługi. Zasoby Hetzner Storage Box mam zamontowane w trybie Bramy do chmury plików, czyli z lokalnym cache, co znakomicie wpływa na responsywność zasobu, a ponadto zasób widoczny jest w systemie plików serwera jako folder współdzielony.

Pomysł był prosty: połączyć HybridMount z Qsync. HybridMount montuje zasoby pod wewnętrznymi ścieżkami systemowymi, niedostępnymi bezpośrednio w selektorze Qsync Central. Postanowiłem to obejść: stworzyłem folder współdzielony costa-cloud na puli DataVol1 i w nim dowiązania symboliczne do wszystkich zamontowanych zasobów:

cloud-box@
cloud-dropbox@
cloud-googledrive@
cloud-onedrive@
ftp-ferguson@
ftp-webh@
smb-ds213@
smb-pve@
webdav-hetzner-box1@

Qsync Central widzi costa-cloud jako normalny folder współdzielony. Symlinki przeżywają restart QNAP‑a, bo są wewnątrz folderu na puli dyskowej, nie bezpośrednio w /share. W jednym miejscu mam naraz wszystkie zamontowane zasoby: chmury, serwery SMB, FTP i Hetzner Storage Box. Przez chwilę wyglądało to jak przełom.

Zacząłem testować rozwiązanie. Scenariusz wyglądał następująco:

1. 1. Zakładam podfolder w folderze /share/costa-hetzner-box1 (to folder z zasobami Hetznera zamontowanymi za pomocą WebDAV w trybie Bramy do chmury plików, czyli z lokalnym cache)
   2. Folder pojawia się w symlinkowanym folderze /share/costa-cloud/webdav-hetzner-box1
   3. W aplikacji QNAPa o nazwie Qsync Central (serwerze synchronizacji i obsługi kopii zapasowych z aplikacji Qsync) mam wskazany folder /share/costa-cloud/webdav-hetzner-box1 jako folder udostępniony i mogę go synchronizować w aplikacji Qsync.
   4. Qsync czyta zmiany w zawartości folderu i je synchronizuje.

Tyle scenariusz.

Niestety, coś to nie zadziałało. Zerkam do klienta Qsync, patrzę w logi Qsync Central — cisza. Żaden trigger synchronizacji nie odpalił i folderu na komputerze nie widzę. Restart klienta Qsync na komputerze — nic. Folder nadal się nie pojawił.

Nie działa, mimo iż ustawiłem sobie synchronizację według wszelkich prawideł aplikacji Qsync. Niestety, po initial sync nic już więcej w Qsync się nie chciało dziać. Rozczarowanie było pełne. Psia mać!

Diagnoza: inotify kontra FUSE

Qsync Central używa inotify do wykrywania zmian w systemie plików. Inotify to mechanizm jądra Linux, który działa świetnie na natywnych folderach, ale nie przechodzi przez symlinki do zasobów FUSE. HybridMount montuje wszystkie zasoby przez FUSE czyli własny sterownik wirtualnego systemu plików. Zmiany w zamontowanym zasobie nie generują zdarzeń inotify, które Qsync mógłby przechwycić. To nie jest bug. To fundamentalna granica architektury.

Żeby to zobrazować: wyobraź sobie, że Qsync stoi przy drzwiach i czeka na dzwonek. inotify to właśnie ten dzwonek — system plików dzwoni za każdym razem, gdy coś się zmienia. Ale FUSE to osobny budynek, do którego Qsync nie ma kabla. Może patrzeć przez okno (przeglądać pliki), ale dzwonka nie usłyszy nigdy.

Sprawdziłem też, co się dzieje, gdy HybridMount odmontuje zasób z jakichś powodów — na przykład po utracie połączenia z internetem. Qsync nie reaguje w żaden sposób. Nie kasuje plików, nie raportuje błędu. Po prostu zawiesza synchronizację tego folderu i czeka. To akurat dobra wiadomość: nie ma ryzyka, że Qsync zinterpretuje pusty symlink jako “pliki usunięte” i wyczyści je na komputerze. Niemniej oznacza to, że mechanizm synchronizacji po prostu nie otrzymuje informacji z systemu o zdarzeniach, jakie dzieją się w folderach montowanych przez FUSE. No i zalecam mocno jednak nie bawić się w ten sposób albo zadbać o backup swoich danych.

Może rclone zadziała tam, gdzie HybridMount zawiódł? Nie miałem na to wielkich nadziei, bo rclone też działa w przestrzeni użytkownika a nie na poziomie jądra, przez co inotify po prostu nie jest wyzwalane. No ale polling powinien w tym przypadku pomóc, tak mi się przynajmniej wydawało. Zamontowałem Hetzner Storage Box przez rclone bezpośrednio w folderze współdzielonym na QNAP-ie.

Wynik: identyczny problem. rclone też używa FUSE i inotify znowu nie widzi zmian. Wychodzi na to, że narzędzie nie ma znaczenia — Qsync będzie miał ten sam problem z każdym mountem dokonywanym przez FUSE.

Wniosek jest prosty i brutalny: Qsync Central nie jest zaprojektowany do pracy z zasobami FUSE jako źródłem synchronizacji. Nie ma trybu pollingu, nie ma obejścia. To świadoma decyzja architektoniczna QNAP‑a i niestety wyklucza klienta Qsync z zastosowań w tym przypadku.

Eksplorując system podczas tych eksperymentów, odkryłem coś, co może się przydać każdemu, kto chce pisać własne skrypty lub automatyzacje na QNAP-ie.

HybridMount trzyma swoje punkty montowania w ukrytych folderach pod /share/external/. Wbrew temu, co można by sądzić po nazwach, wszystkie typy połączeń — zarówno Cloud Drive Mount jak i File Cloud Gateway — trafiają do folderu .cm/. Różnica jest w parametrze --mode procesu cmfs:

.cm/ z --mode 1 — Cloud Drive Mount — usługi chmurowe bez lokalnego cache. Tu trafiają Google Drive, OneDrive, Box, Dropbox w trybie bezpośredniego dostępu przez API.

.cm/ z --mode 0 — File Cloud Gateway — usługi chmurowe z lokalnym cache (Brama do chmury plików). Tu trafia mój Hetzner Storage Box przez WebDAV.

.nd/ — Network Drive Mount — tradycyjne zasoby sieciowe bez cache: SMB/CIFS, FTP, WebDAV, NFS. Nielimitowane połączenia, darmowe.

Foldery z kropką na początku są ukryte w środowisku Linux — QTS nie wyświetla ich bezpośrednio, zamiast tego mapuje je do widocznego drzewa w File Station. Punkty montowania pojawiają się tylko gdy połączenie jest aktywne i znikają przy odmontowaniu lub restarcie. Jeśli piszesz skrypty bashowe na QNAP-ie i chcesz odwoływać się do zamontowanych zasobów, używaj bezwzględnych ścieżek do tych folderów, ale zawsze sprawdzaj najpierw, czy HybridMount zdążył zainicjować połączenie po starcie systemu.

Po serii nieudanych prób z Qsync i rclone zrobiłem krok w tył i pomyślałem inaczej. Skoro problem leży w tym, że żadne narzędzie synchronizujące nie potrafi wykryć zmian w zasobach FUSE — to może zamiast szukać narzędzia, które to potrafi, powinienem znaleźć takie, które w ogóle nie polega na inotify? 

I tu wróciłem do Nextcloud. Wcześniej odrzuciłem go z powodu problemów ze stabilnością przy podpięciu Hetzner Storage Box przez SFTP. Ale… co nas obchodzi SFTP? Przecież mogę uruchomić Nextcloud w kontenerze Dockera i po prostu podpiąć folder costa-hetzner-box1 — czyli folder współdzielony QNAP‑a, który jest już zamontowanym przez HybridMount zasobem Hetzner Storage Box — bezpośrednio do zasobów Nextcloud. Bez żadnego SFTP, bez żadnych problemów ze stabilnością. 

Konfiguracja docker-compose wygląda następująco:

services: 
  nextcloud: 
    image: lscr.io/linuxserver/nextcloud:latest 
    container_name: nextcloud 

    environment: 
      - PUID=1000 
      - PGID=100 
      - TZ=Europe/Warsaw 

    volumes: 
      - /share/vol2-data/docker-data/app-nextcloud/config:/config 
      - /share/vol3-data/docker-data/app-nextcloud:/data 
      - type: bind 
        source: /share/costa-hetzner-box1 
        target: /data/costa-hetzner-box1 
        read_only: false 

    ports: 
      - 10005:443 

    restart: unless-stopped

Jak widać, korzystam z obrazu stworzonego przez LinuxServer.io a nie z oficjalnego. Ten po prostu jest banalny w konfiguracji i do moich celów nadaje się idealnie. Więcej informacji o obrazie stworzonym przez LinuxServer.io można znaleźć tutaj: https://docs.linuxserver.io/images/docker-nextcloud/

Kluczowy element to bind mount: ścieżka /share/costa-hetzner-box1 z hosta (QNAP‑a) jest montowana wewnątrz kontenera jako /data/costa-hetzner-box1. Nextcloud widzi ten folder jako lokalny — nie wie i nie musi wiedzieć, że za nim stoi Hetzner Storage Box.

Po uruchomieniu Nextcloud, w jego Ustawieniach administracyjnych (po zainstalowaniu aplikacji External storage support) przeszedłem do zakładki Magazyn zewnętrzny, kliknąłem na Dodaj magazyn zewnętrzny i wskazałem lokalny dla Nextcloud, podmontowany zasób /data/costa-hetzner-box1. Zainstalowałem klienta desktopowego Nextcloud na macOS oraz Windows 11 i… Nie widzę żadnych problemów z funkcjonowaniem obydwu klientów. Pliki ładnie się wgrywają na serwer QNAP, który wgrywa je następnie do Hetzner Storage Box. Synchronizacja działa w obie strony, placeholdery działają, dostęp offline działa. Wszystkie pięć punktów z mojej listy wymagań — odhaczone. Wow! To wydaje się działać! Ale jakim cudem, skoro systemowe narzędzie zawiodło?

Skoro Nextcloud zadziałał tam, gdzie Qsync i rclone poległy, warto zrozumieć dlaczego. To nie jest przypadek ani magia — to konsekwencja zupełnie innej filozofii wykrywania zmian, jaką zastosowali twórcy Nextcloud i jego klienta desktopowego.

WebDAV, czyli HTTP na sterydach

Nextcloud nie stworzył własnego, zamkniętego protokołu sieciowego. I niechaj jego twórcom będą za to dzięki — nie wymyślali koła na nowo, skorzystali z czegoś, co działa, jest sprawdzone i używane przez deweloperów. Cała bowiem komunikacja między klientem desktopowym a serwerem opiera się na WebDAV — oficjalnym rozszerzeniu dobrze znanego protokołu HTTP/HTTPS. Więcej o WebDAV można poczytać tutaj (kieruję do anglojęzycznej wersji Wiki, bo polskojęzyczny wpis jest po prostu słabej jakości): https://en.wikipedia.org/wiki/WebDAV

Dlaczego to genialne w swojej prostocie? Ponieważ klient Nextcloud rozmawia z serwerem dokładnie tak samo, jak przeglądarka internetowa. Ruch bez problemu przechodzi przez standardowe porty (zazwyczaj bezpieczny port 443), nie wymagając otwierania egzotycznych portów na routerze.

Synchronizacja w Nextcloud — jak to działa?

Klient desktopowy Nextcloud nie skanuje bezmyślnie całego dysku i serwera przy każdej synchronizacji, bo zabiłoby to wydajność NAS‑a i komputera. Zamiast tego stosuje algorytm oparty na trzech źródłach plikowo-folderowej prawdy — stąd nazwa: trójdrożne uzgadnianie stanów (3‑way comparison).

W każdym zsynchronizowanym folderze na komputerze klient Nextcloud prowadzi ukrytą, lokalną bazę danych SQLite. Porównuje ze sobą trzy stany: stan lokalny (czyli to, co aktualnie znajduje się na dysku twardym), stan zdalny (czyli to, co znajduje się na serwerze) oraz bazę stanu plików z poprzedniej synchronizacji. Jeśli coś się w którymś z tych stanów zmieni, zaczyna się procedura synchronizacji.

Dzięki informacjom o stanach plików i folderów w tej bazie, klient potrafi podjąć bez zgadywania decyzje o wysyłce pliku na serwer, pobrania nowszej wersji pliku lokalnie czy obsłudze konfliktu, jeśli plik zmienił się i na serwerze, i lokalnie.

Dodatkowo do identyfikacji zmian serwer używa także tak zwanych ETagów (Entity Tags). To unikalny ciąg znaków — rodzaj odcisku palca — który serwer nadaje każdej wersji pliku i katalogu. Jeśli ETag katalogu na serwerze się nie zmienił, klient wie, że nie musi zaglądać do środka. To ogromna oszczędność zasobów przy dużych strukturach katalogów.

Jak klient i serwer ze sobą rozmawiają?

I tu dochodzimy do sedna — do odpowiedzi na pytanie, dlaczego Nextcloud zadziałał tam, gdzie Qsync poległ na granicy inotify i FUSE.

Klient desktopowy Nextcloud nie pyta Twojego dysku co sekundę, czy coś się zmieniło. Wykorzystuje do tego natywne mechanizmy systemu operacyjnego do monitorowania plików: w Windowsie jest to FileSystemWatcher, w macOS FSEvents, a w Linuksie — inotify. Gdy tylko zapiszesz plik w obserwowanym folderze, system operacyjny szturcha klienta Nextcloud: “Ej, plik raport.docx właśnie się zmienił”. Klient natychmiast uruchamia procedurę wysyłania.

Na serwerze sprawa wygląda nieco inaczej. Tu Nextcloud oferuje dwa podejścia:

Polling (podejście tradycyjne): Klient co określony czas (domyślnie co 30–60 sekund) wysyła do serwera zapytanie o główny katalog. Jeśli ETag się nie zmienił, klient nie podejmuje dalszych akcji. Jeśli jednak ETag się zmienił, klient wchodzi głębiej w strukturę katalogów i sprawdza poczynione w nich zmiany. Jak widać polling jest inicjowany przez klienta i to też co jakiś czas, więc zmiany na serwerze mogą przez jakiś czas nie być widoczne w kliencie.

Push przez WebSocket (podejście nowoczesne): Jeśli na serwerze Nextcloud zainstalowano moduł notify_push (tzw. High Performance Backend), komunikacja wchodzi na wyższy poziom. Klient otwiera stałe, dwukierunkowe połączenie przez WebSockets. Gdy serwer wykryje zmianę, natychmiast “pcha” informację do klienta. Synchronizacja odpala się w ułamku sekundy po wrzuceniu pliku z innego urządzenia. Jak widać to podejście może synchronizować zmienione dane właściwie w czasie rzeczywistym.

Kluczowa jest tu jedna obserwacja: klient po swojej stronie używa technologii natywnych dla systemu plików systemu operacyjnego, które triggerują proces synchronizacji. Natomiast po stronie serwera takie natywne mechanizmy nie są wykorzystywane, dzieje się to w zupełnie inny sposób, dzięki czemu Nextcloud w moim przypadku działa w przeciwieństwie do innych testowanych rozwiązań.

W moim przypadku klient odpytuje serwer przez polling. Nie mam skonfigurowanego notify_push — to kolejny krok do optymalizacji, ale nawet bez niego synchronizacja działa sprawnie i zmiany pojawiają się na komputerze w ciągu kilkudziesięciu sekund.

Jak pliki są przesyłane?

Wysyłanie małych plików przez HTTP jest proste, ale co z filmem o wadze 5 GB? Gdyby klient próbował wysłać go w jednym kawałku, jakikolwiek chwilowy skok ping‑u lub zerwanie Wi-Fi anulowałoby cały proces i trzeba by zaczynać od nowa.

Nextcloud radzi sobie z tym przez tak zwany Chunking: klient tnie duży plik na mniejsze paczki (domyślnie po 10 MB) i wysyła każdy kawałek jako osobne, niezależne żądanie HTTP PUT do tymczasowego katalogu na serwerze. Jeśli transfer 45. kawałka się wywali — klient ponowi próbę wysłania tylko tego jednego kawałka, a nie całego pliku. Po wysłaniu ostatniej części serwer Nextcloud składa kawałki w jeden plik, sprawdza sumę kontrolną i przenosi do docelowego folderu. Jest to eleganckie i odporne na błędy sieci rozwiązanie. Bardzo podobnie działa wspomniane wcześniej rclone, w którym można bardzo precyzyjnie ustawić ilość i wielkość fragmentów, na jakie plik jest dzielony przy wysyłce na serwer ale także podczas pobierania pliku z serwera. Ma to mega wielkie znaczenie przy streamingu filmów ze zdalnych lokalizacji ale o tym może innym razem.

A jak działają pliki wirtualne?

W nowszych wersjach klienta Nextcloud na Windows i macOS dostępna jest funkcja plików wirtualnych — czyli właśnie te placeholdery, których szukałem od początku tej przygody.

Działa to przez głęboką integrację z systemem operacyjnym. Na Windows klient Nextcloud używa Cloud Files API — tego samego, którego używa OneDrive. Na macOS korzysta z File Provider API — tego samego, którego używa iCloud Drive. Klient tworzy na dysku specjalne pliki-skróty (placeholdery), które wyglądają jak normalne pliki, mają prawidłowe nazwy i rozmiary, ale nie zajmują miejsca na dysku.

Dopiero w momencie, gdy system operacyjny zgłasza żądanie otwarcia takiego pliku — bo np. kliknąłeś go dwukrotnie — klient Nextcloud wstrzymuje na chwilę proces otwierania, pobiera plik przez WebDAV z serwera, podmienia placeholder na prawdziwy plik i pozwala aplikacji go otworzyć. Z perspektywy użytkownika wygląda to jak otwarcie lokalnego pliku, tyle że z chwilowym opóźnieniem na pobranie pliku przy pierwszym dostępie.

I tu wracamy do pytania, dlaczego to wszystko działa w moim przypadku. Nextcloud po stronie serwera nie używa inotify do wykrywania zmian w folderze FUSE — używa pollingu przez WebDAV. Po stronie klienta używa natywnych mechanizmów systemu operacyjnego (FileSystemWatcher, FSEvents) do wykrywania lokalnych zmian. Żadna z tych warstw nie potrzebuje inotify po stronie serwera. Dlatego FUSE nie jest dla Nextcloud żadną przeszkodą.

Żeby zobaczyć pełny obraz, warto spojrzeć na całą architekturę od Hetznera do klienta desktopowego.

HybridMount w trybie Bramy do chmury plików (File Cloud Gateway) tworzy na QNAP-ie dedykowany wolumin cache — u mnie nazywa się ten wolumen HybridMount3 i ma pojemność 100 GB na puli HDD RAID 5. Ten cache działa jak inteligentny bufor między Hetzner Storage Box a resztą systemu. Pliki pobrane z Hetznera trafiają do cache i są stamtąd serwowane lokalnie. Pliki wgrane lokalnie trafiają najpierw do cache, a następnie są asynchronicznie uploadowane na Hetzner Storage Box przez WebDAV.

Efekt praktyczny jest taki, że operuję plikami z prędkością mojego łącza domowego (symetryczny gigabit), a nie połączenia z Hetznerem. Spowolnienia widać dopiero przy pobieraniu nowych plików, które nie są jeszcze w cache — muszą najpierw zostać pobrane z Hetznera do bufora na QNAP-ie, by później być wysłane do klienta desktopowego. Ale przy odpowiednich ustawieniach cache, pliki — dopóki nie zostaną zmodyfikowane — znajdują się w cache serwera QNAP i są dostępne bardzo szybko.

I tu jest sedno całego rozwiązania: Nextcloud nie ma własnego systemu cache. Ale bind mount z folderem współdzielonym powoduje, że cache HybridMount staje się dla Nextcloud całkowicie przezroczysty. Nextcloud widzi lokalny folder, operuje na nim jak na lokalnym dysku, a całą magię cache — pobieranie, uploadowanie, zarządzanie buforem — robi za niego QNAP przez HybridMount. Żadnego dodatkowego zamieszania, żadnych konfliktów między dwoma warstwami cache.

Cały łańcuch wygląda tak:

Hetzner Storage Box (WebDAV)
↕ HybridMount File Cloud Gateway (cache 100 GB na wolumenie HybridMount3)
/share/costa-hetzner-box1 (folder współdzielony QNAP)
↕ bind mount w docker-compose
/data/costa-hetzner-box1 (wewnątrz kontenera Nextcloud)
↕ External Storage w Nextcloud + polling WebDAV (PROPFIND + ETagi)
Klient desktopowy Nextcloud (Windows / macOS)
↕ Cloud Files API (Windows) / File Provider API (macOS)
Placeholdery w systemie plików komputera

Każda warstwa robi dokładnie to, do czego jest stworzona. HybridMount zarządza cache i komunikacją z Hetznerem. Nextcloud zarządza synchronizacją i placeholderami. Klient desktopowy integruje się z systemem operacyjnym. Nikt nikomu nie wchodzi w drogę.

Rozwiązanie działa. I to całkiem dobrze. Ale warto być szczerym co do tego, co ono daje i czego nie daje.

Mój use case — jak to wygląda w praktyce

Przez lata korzystałem z kilku komercyjnych usług chmurowych jednocześnie — Google One, OneDrive, Box, Dropbox. Każda z nich oferuje skromną ilość miejsca w stosunku do ceny, a łącznie generują miesięczny koszt, który zaczął mnie uwierać. Hetzner Storage Box był w tym zestawieniu czymś innym: dużo miejsca, niska cena, ale bez wygodnego interfejsu do codziennej pracy z plikami.

Dziś mam to, czego szukałem. Na macOS i Windows 11 klient Nextcloud zachowuje się dokładnie tak, jak klient Google Drive czy OneDrive — pliki widoczne w Finderze i Eksploratorze jako placeholdery, pobieranie on-demand przy otwarciu, możliwość oznaczenia wybranych folderów do zachowania offline. Wgrywanie plików jest szybkie, bo operuję na cache QNAP‑a, a nie bezpośrednio na Hetznerze. Pobieranie nowych plików, których jeszcze nie ma w cache, wymaga chwili cierpliwości ale to uczciwy kompromis za 5 TB miejsca za 58 złotych miesięcznie bez vendor lock-in.

Co ważne: całe rozwiązanie jest zbudowane z darmowych lub już opłaconych komponentów. Nextcloud — open-source, bez opłat licencyjnych. Kontener Docker na QNAP-ie — darmowy. HybridMount z jednym darmowym połączeniem File Cloud Gateway — wliczony w cenę NAS‑a. Jedyny koszt to abonament Hetzner Storage Box, który i tak płaciłem za backup. No i oczywiście koszt NASa, dysków, łącza, prądu i tych wszystkich rzeczy, które w 2026 roku powodują, że człowiek przeciera oczy ze zdumieniem, jakie chore pieniądze na swoje hobby musi wydawać 🙂

Podsumowując, co działa bez zarzutu:

• Synchronizacja dwukierunkowa z placeholderami na Windows i macOS. I to na tyle sprawnie, że ma się wrażenie funkcjonowania z chmurą od Google czy Microsoft.
• Dostęp offline do wybranych plików. Prawoklik na pliku/folderze, wybór opcji “Zawsze zachowuj na tym urządzeniu” i zrobione, mam dostęp offline. W drugą stronę też to działa, zawsze mogę też wymusić zwolnienie miejsca na dysku w komputerze (czyli zamiast plików zostawić placeholdery).
• Transparentny upload i download przez cache QNAP‑a. I to z prędkością mojego łącza domowego, nie Hetznera. Jasne, dotyczy to plików już istniejących w cache na NASie ale na szczęście HybridMount umożliwia całkiem sprawne zawiadywanie tym, co ma się w cache znaleźć, dzięki czemu do najczęściej używanych plików można mieć szybki dostęp.
• Wersjonowanie plików. Nextcloud automatycznie tworzy wersje historyczne przy każdej modyfikacji pliku, które to wersje są dostępne przez interfejs webowy i klienta desktopowego. Tu trzeba uważać na to, gdzie co jest zamontowane, bo wersje – przynajmniej w moim przypadku i dla moich ustawień — są tworzone na lokalnym dysku NASa a nie na zdalnym udziale Hetznera.
• Pełna kontrola nad danymi, czyli powód, dla którego mamy swoje homelaby. Własny serwer, własne reguły, dane co prawda w Niemczech ale przynajmniej w jakimś cywilizowanym reżimie prawnym.
• Stosunkowo niskie koszty. Pomijając oczywiste koszty NASa i pozostałej infrastruktury, tak właściwie jedynym kosztem jest usługa Hetznera. To miłe w obecnych, kosztownych dla miłośników elektroniki czasach.

Czego jednak nadal brakuje:

• Linux bez VFS. Klient desktopowy Nextcloud na Linuksie synchronizuje pliki klasycznie: pełna kopia lokalna, bez placeholderów. Jeśli Linux jest dla Ciebie kluczowy, rclone mount z VFS cache jest najlepszą dostępną opcją, ale bez systemowych placeholderów i bez dostępu offline to bardziej wirtualny dysk sieciowy niż zamiennik Google Drive. Inna sprawa, że rclone ładnie dostarcza coś, co nazywa się sparse files (tak zwane pliki rzadkie) i może w środowisku Linuksowym działać całkiem dobrze.
• Backup plików z komputera. Qsync 6 potrafi tworzyć kopie zapasowe plików z komputera na NAS — to przydatna funkcja, której szukałem. Ale Qsync nie działa z zasobami FUSE, więc jako klient backupu z miejscem docelowym w folderze costa-hetzner-box1 odpada. Nextcloud nie oferuje funkcji backupu w takim sensie.
• Wersje historyczne na QNAP-ie, nie na Hetznerze. To ważna różnica w stosunku do Google Drive i OneDrive. Bieżące pliki trafiają na Hetzner Storage Box przez cache HybridMount. Ale wersje historyczne plików Nextcloud przechowuje lokalnie — w swoim katalogu /data/[user]/files_versions kontenera, który w mojej konfiguracji mapuje się na DataVol3 (dysk SSD SATA na QNAP-ie). Oznacza to, że wersje historyczne nie są replikowane na Hetzner i nie korzystają z jego snapshotów. Jeśli zależy Ci na długoterminowym przechowywaniu historii wersji poza NAS-em, warto uwzględnić Twój odpowiednik mojego DataVol3 w harmonogramie backupów HBS3.

Papo CoSTa, pokaż to w tabeli a nie lejesz wodę…

Jasne, już się robi! Poniżej podrzucam małe zestawienie porównawcze usług z moim nextcloudowo-hybridmountowym rozwiązaniem.

Hetzner Storage Box to nie jest zamiennik Google Drive. To jest coś innego — pojemny, tani, prywatny dysk sieciowy z dostępem przez otwarte protokoły. Ale z Nextcloud jako warstwą synchronizacji i HybridMount jako warstwą cache staje się czymś, co w codziennym użytkowaniu jest bardzo bliskie temu, czego szukałem. Nie idealne, ale bardzo dobre.

W sumie teraz muszę przemyśleć, czy warto utrzymywać moje rozliczne dyski w chmurze. 5 TB, 58 złotych miesięcznie, zero Google… Nie spodziewałem się, że to tak fajnie zadziała. Oby więcej tak miłych zaskoczeń!