Docker: odmowa montażu. Ścieżki… nie są współdzielone z OS X i nie są znane Dockerowi

Polecenie docker run -v /var/folders/zz/...generuje następujący błąd.

docker: Error response from daemon: Mounts denied: 
The paths /var/folders/zz/... and /var/folders/zz/...
are not shared from OS X and are not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.

Kiedy otwieram Udostępnianie plików, widzę, że / private jest już na liście.

Jeśli spróbuję dodać /var/folder/, następuje to /private/var/folders, co jest podzbiorem / private i dlatego dodanie jest odrzucane.

Podsumowując, wydaje mi się, że katalog /var/folders/..jest współdzielony przez OS X jako podkatalog /privatei dlatego musi być znany Dockerowi. Każda pomoc w rozwiązaniu tego problemu będzie mile widziana.

W ramach eksperymentu zastąpiłem /privatew Udostępnianie plików /private/var/foldersi ponownie uruchomiłem okno dokowane, ale wynik się nie zmienił.

Aby uzyskać pełniejsze informacje, jest to skrypt .sh , który uruchamia ten skrypt w języku Python , który z kolei uruchamia polecenie docker.

Podłączenia woluminów Docker for Mac zachowują się inaczej niż podstawowy system Docker. Dzieje się tak głównie dlatego, że Docker stara się przestrzegać wytycznych Apple dotyczących piaskownicy systemu plików.

Jak pokazano w preferencjach Dockera, tylko niektóre ścieżki są eksportowane przez macOS.

• /Users
• /Volumes
• /tmp
• /private

/varw macOS jest dowiązaniem symbolicznym do /private. Dotyczy to również /tmp:

$ ls -ld /tmp /var
lrwxr-xr-x@ 1 root  wheel  11 Jan 26 16:18 /tmp -> private/tmp
lrwxr-xr-x@ 1 root  wheel  11 Jan 26 16:18 /var -> private/var

Dlaczego jest /tmpwymieniony w panelu udostępniania, a /varnie (mimo że oba są częścią /private)? Dokumentacja Docker for Mac dotycząca przestrzeni nazw systemów plików wyjaśnia:

Domyślnie można udostępniać pliki /Users/, /Volumes/, /private/, i /tmpbezpośrednio. Aby dodać lub usunąć drzewa katalogów, które są eksportowane do Dockera, użyj zakładki Udostępnianie plików w menu wieloryba preferencji Dockera -> Preferencje -> Udostępnianie plików. (Zobacz Preferencje.)

Wszystkie inne ścieżki używane w instalacjach -vpowiązań pochodzą z maszyny wirtualnej Moby Linux z kontenerami Docker, więc argumenty takie jak -v /var/run/docker.sock:/var/run/docker.sockpowinny działać zgodnie z oczekiwaniami. Jeśli ścieżka macOS nie jest udostępniona i nie istnieje na maszynie wirtualnej, próba powiązania instalacji zakończy się niepowodzeniem, zamiast utworzyć ją na maszynie wirtualnej. Ścieżki, które już istnieją na maszynie wirtualnej i zawierają pliki, są zarezerwowane przez platformę Docker i nie można ich wyeksportować z systemu macOS.

Zwróć uwagę, że /var/runjest tutaj wyraźnie wymienione jako miejsce, które zostanie zamontowane z maszyny wirtualnej z systemem Linux, a nie z systemu macOS.

Kiedy poprosisz o zamontowanie woluminu, najpierw sprawdzane są eksportowanie systemu plików macOS. Jeśli nie ma tam dopasowania, maszyna wirtualna z systemem Linux, na której działa platforma Docker, jest następnie sprawdzana. Jeśli żaden z nich nie ma żądanej ścieżki, instalacja kończy się niepowodzeniem.

W twoim przypadku /varnie jest eksportowany przez macOS. /varistnieje na maszynie wirtualnej z systemem Linux, ale /var/folderstak nie jest. Dlatego ścieżka jest niedostępna, a instalacja kończy się niepowodzeniem.

Jeśli zmienisz ścieżkę na /private/var, to się powiedzie, ponieważ macOS eksportuje całe /privatedrzewo systemu plików do zamontowania.

Aby uczynić rzeczy bardziej przenośnymi, możesz przetestować, na której platformie aktualnie pracujesz, a jeśli jest to macOS, poprzedz ścieżkę montowania przedrostkiem /private.

Jako alternatywne rozwiązanie:

Zmień ścieżkę z /private/instance1-data:/homena./instance1-data:/home

W krainie * nix, a tym samym w Dockerze, symbol .wskazuje bieżący katalog. Ponieważ macOS jest wybredny i staje się jeszcze bardziej wybredny, jeśli chodzi o piaskownicę, wydaje się to realnym rozwiązaniem dla macOS. Po prostu utwórz potrzebny folder instance1w tym samym katalogu.

Kolejną zaletą tego rozwiązania jest to, że eliminuje potrzebę uruchamiania docker-composez sudo. Niezależnie od tego, w tym przypadku nie powoduje to żadnej szkody, ale nadal jest to plus.

Miałem podobny problem, gdy utworzyłem katalog /var/tmp na moim Macu, który chciałem zamontować w moim kontenerze docker.

Rozwiązano to, dodając ścieżkę katalogu do pliku w następujący sposób:

$ cat ~/Library/Group\ Containers/group.com.docker/settings.json  
{
  "filesharingDirectories" : [
    "\/Users",
    "\/Volumes",
    "\/private",
    "\/tmp",
    "\/var\/tmp"
  ],
…

Teraz mogłem zobaczyć katalog /var/tmp w Docker-> preferencje-> zasoby-> udostępnianie plików. Następnie ponownie uruchomiłem docker.

To rozwiązało mój problem z montażem.

Na przykład, używając Portainera, to polecenie działa dla mnie:

docker run -d --restart unless-stopped -p 9000:9000 \
 -v /var/run/docker.sock:/var/run/docker.sock \
 -v /var:/data portainer/portainer --no-auth

Ale jeśli w ogóle zmienię -v /var:/data, to nie zadziała. Myślę (ale nie jestem pewien), że to dlatego, że Docker próbuje zrobić mkdir. Tak więc, jeśli spróbuję zamontować -v /var/whatever:/data, mkdir kończy się niepowodzeniem, ponieważ nie ma wystarczających uprawnień i nie działa.

Mam 2 komputery Mac (High Sierra) i wypróbowałem je na obu. Taki sam problem. Próbowałem też użyć kanału Docker Beta. Myślę, że rozumiem odpowiedź Dana Lowe'a: zaktualizuję tę odpowiedź, jeśli to zadziała.

Mój problem został rozwiązany, gdy usunąłem ścieżkę projektu z udostępniania plików w preferencjach okna dokowanego i ponownie uruchomiłem okno dokowane, a następnie ponownie dodałem ścieżkę pliku projektu.

Mój problem został rozwiązany podobnie jak w Arghya. Musiałem tylko usunąć ścieżki z udostępniania plików i ponownie uruchomić docker.

W przypadku netcoreapp upewnij się, że udostępniłeś / usr / local / share /