Niestandardowa aplikacja Docker może wymagać czegoś więcej niż prostego mapowania ścieżki z hosta do kontenera. W dyskusji dotyczącej ZimaOS ze stycznia 2026 r. kontener oparty na SSHFS wymagał propagacji montowania przy użyciu opcji :shared. Wpisanie tej opcji w polu woluminu niestandardowej aplikacji ZimaOS powodowało awarię kontenera, natomiast to samo montowanie bez tej opcji nie zapewniało wymaganej przez aplikację propagacji po stronie hosta.
Najważniejsze rozróżnienie wynikające z tego wątku dotyczy edytora WebUI ZimaOS i bazowego stosu Docker. Testy społeczności pokazały, że opcje woluminów Docker i montowań bind mogą działać za pośrednictwem Docker Compose lub poleceń CLI, podczas gdy WebUI nieprawidłowo analizował ani nie zachowywał opcji takich jak :shared, :ro i :readonly.
Ograniczenie dotyczyło WebUI, a nie standardowego Dockera
Autor oryginalnego wpisu początkowo zapytał, czy w samym ZimaOS brakuje obsługi zaawansowanych flag woluminów. Po przeprowadzeniu testów dyskusja doprowadziła do węższego wniosku: silnik Docker mógł korzystać z tych opcji, ale formularz niestandardowej aplikacji ZimaOS nie udostępniał ich ani nie zachowywał prawidłowo.
Powiązany wątek z grudnia 2025 r. doprowadził do takiego samego wniosku w przypadku montowań tylko do odczytu. Członek zespołu ZimaOS, Zima-Jerry, odpowiedział, że przyszłe wersje WebGUI będą zawierać więcej opcji edytora, a prace projektowe są w toku.
Nie należy przekształcać tego historycznego stanu w obietnicę ani termin wydania. 24 sierpnia 2026 r. inny członek społeczności poinformował, że problem interfejsu tylko do odczytu nadal nie został rozwiązany, i poprosił o podanie przewidywanego terminu; wątek nie zawierał późniejszej odpowiedzi zespołu.
Dlaczego :shared ma znaczenie dla niektórych kontenerów
Opisany przypadek dotyczył SSHFS. Kontener służył do montowania zdalnego systemu plików, a użytkownik potrzebował, aby wynikowe montowanie było propagowane poza przestrzeń nazw kontenera. W tego typu zastosowaniu samo mapowanie ścieżki hosta do kontenera nie jest równoważne z użyciem wymaganej opcji propagacji montowania.
Dlatego porady oparte wyłącznie na zwykłych trwałych woluminach danych aplikacji nie rozwiązywały opisanego przypadku użycia SSHFS. Różne kontenery mogą wymagać różnej semantyki montowania.
Aktualne informacje o działaniu i składni Dockera znajdziesz w dokumentacji Dockera dotyczącej montowań bind i propagacji montowań.
Ten sam problem interfejsu dotyczył także :ro i :readonly
Powiązana dyskusja z grudnia 2025 r. opisywała podobny problem z montowaniami tylko do odczytu. Uczestnik społeczności poinformował, że interfejs ZimaOS mógł ponownie zapisać konfigurację montowania i usunąć przyrostek :ro po edycji lub ponownym otwarciu konfiguracji woluminu.
Ma to znaczenie nie tylko ze względów wygody. Montowanie, które ma być tylko do odczytu, nie powinno po cichu stać się zapisywalne. Jeśli dostęp tylko do odczytu jest elementem modelu bezpieczeństwa lub ochrony danych, sprawdź rzeczywistą konfigurację montowania kontenera, zamiast polegać wyłącznie na tym, co wpisano w historycznym WebUI.
Docker Compose było praktycznym obejściem
Autor oryginalnego wpisu potwierdził, że standardowa definicja Docker Compose mogła wyrazić wymagane opcje montowania, nawet jeśli nie potrafił tego zrobić graficzny formularz ZimaOS. Obejście opisane w wątku polegało więc na zarządzaniu zaawansowanym montowaniem za pomocą Compose zamiast korzystania z pola tekstowego woluminu.
Aktualna dokumentacja ZimaOS, zaktualizowana w sierpniu 2026 r., nadal opisuje Docker Compose jako zaawansowaną ścieżkę dla zaawansowanych użytkowników i stwierdza, że standardowa konfiguracja środowiska uruchomieniowego kontenerów powinna znajdować się w Docker Compose. Zobacz aktualną dokumentację funkcji ZimaOS oraz aktualną dokumentację ZimaOS dotyczącą Docker Compose.
Te aktualne dokumenty potwierdzają obsługę Compose, ale nie opisują dedykowanego elementu WebUI dla każdej opcji montowania Dockera. Jeśli dana flaga montowania jest niezbędna, zweryfikuj wynikową konfigurację Compose i środowiska uruchomieniowego, zamiast zakładać, że interfejs graficzny ją zachował.
Czego ten wątek nie dowodzi
- Nie oznacza to, że zwykłe woluminy danych aplikacji ZimaOS wymagają
:shared. - Nie oznacza to, że Docker w ZimaOS nie obsługuje zaawansowanych montowań.
- Nie dowodzi to, że każda obecna wersja WebUI nadal działa dokładnie tak samo jak kompilacja ze stycznia 2026 r.
- Nie podaje oficjalnego terminu udostępnienia dodatkowych elementów sterujących opcjami woluminów.
Często zadawane pytania dotyczące opcji woluminów ZimaOS
Czy niestandardowe aplikacje ZimaOS w WebUI mogą używać :shared?
W wątku źródłowym ze stycznia 2026 r. WebUI nie obsługiwało tej opcji prawidłowo. Wymagane działanie było możliwe za pośrednictwem Docker Compose.
Czy Docker w ZimaOS obsługuje :ro i :readonly?
Dyskusja rozróżnia obsługę przez Docker od historycznego ograniczenia interfejsu. Docker obsługuje opcje montowania tylko do odczytu, natomiast omawiane wątki wskazywały, że WebUI ZimaOS nie zachowywało ich niezawodnie.
Czy ograniczenie WebUI zostało oficjalnie potwierdzone?
Tak. W powiązanym wątku z grudnia 2025 r. Zima-Jerry poinformował, że dla przyszłych WebGUI projektowane są dodatkowe opcje edytora. Nie podano terminu wydania.
Czy problem został już rozwiązany?
Materiały źródłowe nie potwierdzają rozwiązania problemu. W kolejnym wpisie społeczności z 24 sierpnia 2026 r. problem interfejsu tylko do odczytu nadal opisywano jako nierozwiązany, a aktualna dokumentacja ZimaOS wciąż zaleca używanie Docker Compose do zaawansowanej konfiguracji.
