Ho riscontrato un problema simile durante la condivisione di un punto di montaggio nfs come volume utilizzando docker-compose. Sono stato in grado di risolvere il problema con:
docker-compose up --force-recreate
Anche se hai riscontrato il problema, questo potrebbe aiutare qualcun altro.
Un'autorizzazione negata all'interno di un contenitore per una directory condivisa potrebbe essere dovuta al fatto che questa directory condivisa è archiviata su un dispositivo. Per impostazione predefinita, i contenitori non possono accedere ad alcun dispositivo. Aggiunta dell'opzione $docker run --privileged consente al contenitore di accedere a tutti dispositivi ed esegue chiamate al kernel. Questo non è considerato sicuro.
Un modo più pulito per condividere il dispositivo è usare l'opzione docker run --device=/dev/sdb (se /dev/sdb è il dispositivo che desideri condividere).
Dalla pagina man:
--device=[] Add a host device to the container (e.g. --device=/dev/sdc:/dev/xvdc:rwm) --privileged=true|false Give extended privileges to this container. The default is false. By default, Docker containers are “unprivileged” (=false) and cannot, for example, run a Docker daemon inside the Docker container. This is because by default a container is not allowed to access any devices. A “privileged” container is given access to all devices. When the operator executes docker run --privileged, Docker will enable access to all devices on the host as well as set some configuration in AppArmor to allow the container nearly all the same access to the host as processes running outside of a container on the host.
Ho ricevuto risposta da un commento in:Perché il contenitore docker richiede Autorizzazione negata?
man docker-run dà la risposta corretta:
I sistemi di etichettatura come SELinux richiedono che le etichette appropriate siano posizionate sul contenuto del volume montato in un contenitore. Senza un'etichetta, il sistema di sicurezza potrebbe impedire ai processi in esecuzione all'interno del contenitore di utilizzare il contenuto. Per impostazione predefinita, Docker non modifica le etichette impostate dal sistema operativo.
Per modificare un'etichetta nel contesto del contenitore, puoi aggiungere uno dei due suffissi :z o :Z al montaggio del volume. Questi suffissi indicano a Docker di rietichettare gli oggetti file sui volumi condivisi. L'opzione z indica a Docker che due contenitori condividono il contenuto del volume. Di conseguenza, Docker etichetta il contenuto con un'etichetta di contenuto condivisa. Le etichette del volume condiviso consentono a tutti i contenitori di leggere/scrivere contenuto. L'opzione Z indica a Docker di etichettare il contenuto con un'etichetta privata non condivisa. Solo il contenitore corrente può utilizzare un volume privato.
Ad esempio:
docker run -it --name oracle_install -v /root/database:/tmp/install/database:z ...
Un altro motivo è una mancata corrispondenza con l'UID/GID. Questo spesso si presenta come la possibilità di modificare un montaggio come root ma non come utente container
Puoi impostare l'UID, quindi per un contenitore ubuntu eseguito come ubuntu potresti dover aggiungere :uid=1000 (controlla con id -u ) o imposta l'UID localmente in base al tuo caso d'uso.
uid=valore e gid=valore
Imposta il proprietario e il gruppo dei file nel filesystem (default:uid=gid=0)
C'è un buon blog qui con questo esempio di tmpfs
docker run \
--rm \
--read-only \
--tmpfs=/var/run/prosody:uid=100 \
-it learning/tmpfs
http://www.dendeer.com/post/docker-tmpfs/