Użytkownik źródłowy miał działającą synchronizację zdjęć z telefonu w Syncthing, ale pliki ciągle trafiały na dysk systemowy zamiast na dysk zewnętrzny. Skopiowanie ścieżki z aplikacji Pliki i bezpośrednie wklejenie jej do Syncthing spowodowało, że Syncthing odtworzył identycznie wyglądające drzewo katalogów we własnym systemie plików kontenera.
Ostateczne rozwiązanie miało charakter koncepcyjny, a nie polegało na użyciu magicznego polecenia systemu plików: Docker ma ścieżkę hosta i ścieżkę kontenera. Syncthing musi używać ścieżki widocznej wewnątrz kontenera, a nie surowej ścieżki widocznej dla CasaOS lub ZimaOS.
Dlaczego ścieżka zewnętrzna była odtwarzana w niewłaściwym miejscu
Jeśli Syncthing otrzyma ścieżkę, której faktycznie nie może zobaczyć, może utworzyć ją we własnym zapisywalnym systemie plików lub w zmapowanej lokalizacji konfiguracji. Użytkownik źródłowy zinterpretował nazwę folderu jako ścieżkę do zewnętrznego dysku, podczas gdy kontener zinterpretował ją jako ścieżkę względem własnego systemu plików.
Znajdź rzeczywisty punkt montowania hosta
Społeczność użyła polecenia lsblk aby ustalić, gdzie system operacyjny zamontował zewnętrzny dysk. W przykładzie osoby udzielającej odpowiedzi dysk pojawił się pod ścieżką podobną do /media/devmon/...; dyski autora oryginalnego wpisu pojawiły się później w lokalizacjach /mnt/Storage1 i /mnt/Storage2.
Te dokładne historyczne ścieżki montowania to przykłady z CasaOS/ZimaBlade i nie należy ich traktować jako aktualnych, uniwersalnych ścieżek ZimaOS.
Zmapuj dysk hosta w Syncthing
Osoba udzielająca odpowiedzi użyła /DATA jako ścieżkę po stronie Syncthing. Po utworzeniu tego mapowania Syncthing powinien odwoływać się do folderów znajdujących się w /DATA zamiast pierwotnej ścieżki montowania hosta.
Użytkownik początkowo wprowadził ścieżkę hosta w Syncthing
Syncthing zwrócił następnie błąd dotyczący uprawnień/ścieżki, ponieważ ta ścieżka wewnętrzna nie odpowiadała zmapowanemu woluminowi.
Ostatecznie działająca ścieżka to /DATA/Documents
Osoba udzielająca odpowiedzi wyjaśniła, że po zmapowaniu dysku hosta do /DATA, Syncthing powinien używać:
/DATA/Documentslub odpowiednik ~/Documents skrótowej ścieżki, gdy katalog domowy Syncthing wskazuje na zmapowaną lokalizację danych.
Autor oryginalnego wpisu wrócił następnego dnia i potwierdził, że rozwiązanie działa.
Rekurencyjne chown było częścią procedury społeczności, a nie kluczowym rozwiązaniem
W wątku użyto również rekurencyjnego chown na zewnętrznym dysku. Może to być odpowiednie w systemie plików zarządzanym przez Linuksa, ale zmienia właściciela w całym miejscu docelowym i nie było wymaganiem opracowanym przez IceWhale.
Nie wykonuj rekurencyjnej zmiany właściciela na istniejącym współdzielonym dysku, dopóki nie wiesz, którzy użytkownicy i aplikacje już korzystają z jego uprawnień.
Obecny ZimaOS ułatwia mapowanie pamięci masowej aplikacji
Obecny ZimaOS bezpośrednio dokumentuje ścieżki hosta i kontenera w ustawieniach aplikacji oraz zaleca przechowywanie danych aplikacji w zarządzanej pamięci masowej, zamiast pozwalać aplikacjom zapełniać dysk systemowy.
Użyj aktualnego modelu ścieżek aplikacji ZimaOS dla woluminów Dockera, zamiast polegać na starych lokalizacjach montowania CasaOS.
Użytkownik źródłowy ponownie zainstalował Syncthing i odtworzył mapowanie
Gdy pierwsze próby nadal były niejasne, autor oryginalnego wpisu przeprowadził nową instalację Syncthing, ponownie dodał dyski pamięci masowej i zamapował /mnt/Storage1 na hoście do /DATA wewnątrz kontenera. Ten czysty test powtórny usunął stare ustawienia kontenera z procesu diagnozowania.
Same uprawnienia hosta nie sprawiły, że nieprawidłowa ścieżka kontenera zaczęła działać
Użytkownik mógł połączyć się przez SSH z dyskiem pamięci masowej i utworzyć katalogi, jednak Syncthing nadal kończył działanie niepowodzeniem, gdy wskazano mu /mnt/Storage1/Documents wewnątrz. Ten negatywny wynik jest cenną informacją: możliwość zapisu jako użytkownik hosta nie oznacza, że kontener widzi tę samą przestrzeń nazw.
Widoczność w kontenerze musi być prawidłowa, zanim dostosowanie uprawnień będzie mogło cokolwiek naprawić.
Obecny ZimaOS powinien preferować zarządzane ścieżki pamięci masowej
Ten wątek dotyczy urządzenia ZimaBlade dostarczonego ze ścieżkami pamięci masowej w stylu CasaOS. Obecny ZimaOS ma inne zasady zarządzania pamięcią masową i czytelniejszy interfejs woluminów aplikacji. Na aktualnym serwerze użyj ścieżki pamięci masowej wybranej w ZimaOS, zamiast zakładać, że /mnt/Storage1 lub /media/devmon będzie istnieć.
Zmieniaj tylko uprawnienia faktycznie wymagane przez aplikację
Syncthing zwykle potrzebuje dostępu do odczytu i zapisu w swoim folderze synchronizacji. Jeśli zamapowany folder jest widoczny, ale nie można w nim zapisywać, sprawdź właściciela i uprawnienia grupy dla tego konkretnego folderu. Unikaj rekurencyjnej zmiany właściciela na całym wielofunkcyjnym dysku, dopóki nie uwzględnisz wszystkich innych usług korzystających z tego dysku.
Najczęstsze pytania dotyczące zewnętrznych dysków HDD w Syncthing
Dlaczego Syncthing utworzył ścieżkę zewnętrznego dysku wewnątrz dysku systemowego?
Ścieżka hosta nie była ścieżką, którą Syncthing mógł zobaczyć wewnątrz swojego kontenera.
Jaka ścieżka działała po zamapowaniu dysku na /DATA?
Użytkownik źródłowy potwierdził /DATA/Documents zadziałało.
Czy rekurencyjna zmiana właściciela była jedynym rozwiązaniem?
Nie. Decydujące było rozróżnienie między ścieżką hosta a ścieżką kontenera.
