Kenali akses yang ditolak

Contoh pesan berikut menunjukkan Docker CLI gagal mengakses socket daemon:

permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock

Ini berbeda dari permission denied saat aplikasi di dalam container menulis ke bind mount, menjalankan file tanpa executable bit, atau menarik image dari registry. Jangan menambah group Docker untuk menyelesaikan semua pesan yang mengandung kata “permission”.

Mulai dengan endpoint yang digunakan CLI. Langkah menambah group docker di artikel ini hanya untuk Docker Engine rootful pada Linux, bukan resep universal untuk Docker Desktop, rootless, atau daemon remote.

1. Periksa context dan endpoint

Perintah berikut membaca konfigurasi context dan versi, tanpa membuat container:

docker context show
docker context ls
docker context inspect
docker version

Lihat Endpoints.docker.Host pada hasil inspect, lalu bandingkan dengan endpoint yang disebut pesan error. Periksa juga apakah perintah memakai --context/--host atau environment DOCKER_CONTEXT/DOCKER_HOST. Override tersebut dapat membuat CLI terhubung ke daemon yang berbeda dari dugaan; inspect context saja belum tentu menunjukkan override DOCKER_HOST. Menurut referensi CLI Docker, DOCKER_CONTEXT mengalahkan DOCKER_HOST dan context default; jangan membaca keduanya sebagai pengaturan yang setara.

Pemeriksaan environment di shell Linux/macOS:

printf 'DOCKER_HOST=%s\nDOCKER_CONTEXT=%s\n' "$DOCKER_HOST" "$DOCKER_CONTEXT"

Di PowerShell:

Get-Item Env:DOCKER_HOST, Env:DOCKER_CONTEXT -ErrorAction SilentlyContinue
Jenis instalasi Endpoint yang perlu diperiksa
Engine rootful Linux Umumnya unix:///var/run/docker.sock
Engine rootless Linux Umumnya unix://$XDG_RUNTIME_DIR/docker.sock, misalnya /run/user/1000/docker.sock
Docker Desktop macOS Socket milik pengguna seperti ~/.docker/run/docker.sock; dapat tersedia symlink /var/run/docker.sock
Docker Desktop Linux Context Desktop, umumnya socket di ~/.docker/desktop/docker.sock
Docker Desktop Windows Dapat menggunakan named pipe; di WSL mengikuti integrasi/context yang dipakai
Daemon remote Endpoint SSH/TCP; periksa autentikasi dan izin pada host tujuan

Path di tabel adalah contoh umum, bukan nilai untuk dipaksakan ke semua instalasi. Jangan mengganti context atau menghapus environment override sebelum memastikan daemon tujuan yang benar.

2. Diagnosis Docker Engine rootful di Linux

Lanjutkan bagian ini hanya jika endpoint memang socket Engine lokal. Pada Linux dengan systemd:

id -un
id -nG
id -nG "$(id -un)"
stat -Lc '%U:%G %a %n' /var/run/docker.sock
systemctl status docker.service --no-pager

id -nG tanpa nama menampilkan group efektif sesi saat ini. Bentuk dengan nama pengguna membaca informasi keanggotaan pengguna dari database akun; hasil keduanya dapat berbeda setelah perubahan group. Proses anak biasanya mewarisi group dari proses induk. Membuka tab terminal baru dari sesi desktop lama belum tentu memuat group baru.

Socket Engine rootful umumnya dimiliki root:docker dengan mode 660, tetapi konfigurasi daemon bisa berbeda. Jika stat melaporkan file tidak ada, periksa daemon/context, bukan langsung mengubah permission. Docker CLI tidak membuat socket daemon yang hilang; socket dibuat oleh daemon atau pengelola socket. Error no such file, connection refused, dan permission denied membutuhkan diagnosis berbeda.

Jika daemon berhenti, periksa log dan penyebabnya sebelum memulai service. Memulai atau me-restart Docker dapat memengaruhi workload; lakukan hanya dengan izin administrator dan rencana dampak yang jelas.

3. Akses group docker: pahami risikonya dahulu

Keanggotaan group docker pada Engine rootful memberikan kemampuan yang secara praktis setara akses root pada host. Panduan post-install Docker menyatakan risiko ini secara eksplisit. Pengguna yang dapat mengendalikan daemon dapat meminta operasi container yang mengakses filesystem host. Ini bukan sekadar izin menjalankan satu aplikasi.

Tambahkan hanya pengguna tepercaya yang disetujui administrator. Pada host bersama atau lingkungan dengan kebutuhan isolasi, pertimbangkan rootless atau mekanisme akses yang lebih terbatas terlebih dahulu. Jangan membuka socket agar bisa ditulis semua pengguna dan jangan memasang socket host ke container yang tidak tepercaya.

Untuk Linux yang menyediakan usermod, jalankan dari sesi pengguna biasa yang hendak diberi akses, bukan dari root shell atau identitas service yang tidak dimaksud:

# Pastikan nama ini adalah akun yang memang disetujui
id -un
getent group docker

# Jalankan hanya setelah administrator menyetujui akses setara root
sudo usermod -aG docker "$(id -un)"

Jika group tidak ada, periksa cara instalasi dan konfigurasi Engine bersama administrator. Jangan membuat atau mengganti group secara membabi buta. Flag -aG menambahkan group tambahan; menghilangkan -a dapat mengganti keanggotaan group lain.

Logout penuh lalu login kembali. Alternatif untuk pengujian satu shell interaktif:

newgrp docker
id -nG
docker version
docker ps

newgrp memulai shell dengan group baru; ketik exit untuk kembali. Ia tidak memperbarui group terminal lain atau proses service/CI yang sudah berjalan. Proses background yang dimulai dari shell tersebut tetap mewarisi akses sampai prosesnya berhenti; exit bukan pencabutan akses global. Untuk service account, administrator perlu memperbarui konfigurasi dan sesi proses yang benar, bukan mengandalkan newgrp dalam script provisioning.

Keberhasilan docker version pada bagian server dan docker ps membuktikan CLI dapat mengakses daemon itu, bukan menjamin semua operasi container akan berhasil. Pengujian ini tidak perlu menarik image hello-world dari jaringan.

4. Jika ownership socket tidak sesuai

Jangan memperbaiki socket secara permanen dengan chown atau chmod ad hoc. Socket dapat dibuat ulang ketika service dimulai, sehingga perubahan manual bisa hilang dan menyembunyikan konfigurasi yang salah.

Untuk instalasi yang memakai systemd socket activation, periksa unit aktual:

systemctl cat docker.service docker.socket
sudo journalctl -u docker.service -u docker.socket --no-pager -n 50

Ilustrasi properti socket untuk Engine rootful, sesuai contoh unit socket upstream Moby:

[Socket]
SocketUser=root
SocketGroup=docker
SocketMode=0660

Tidak semua instalasi memakai docker.socket; pada instalasi lain daemon membuat socket sendiri dengan konfigurasi group-nya. Bandingkan dengan konfigurasi paket yang terpasang, bukan membuat override baru tanpa diagnosis. Minta administrator memperbaiki sumber pengaturan dan menjadwalkan restart jika perlu. Restart dapat mengganggu workload; jangan menjalankannya sebagai langkah otomatis artikel.

5. Rootless bukan Docker Desktop

Engine rootless menjalankan daemon dan container dalam user namespace tanpa daemon root. Socket umumnya berada di $XDG_RUNTIME_DIR/docker.sock (sering /run/user/<UID>/docker.sock), bukan path socket Docker Desktop macOS.

Jika rootless sudah dipasang, periksa context yang dibuat instalasinya dan service pengguna:

docker context ls
systemctl --user status docker.service --no-pager

Perintah systemd hanya berlaku pada sistem yang memang memakai user service systemd. Pastikan DOCKER_HOST atau context lama tidak mengarahkan CLI kembali ke Engine rootful. Jangan menambahkan pengguna rootless ke group rootful hanya untuk menghilangkan pesan error: itu mengganti batas keamanannya, bukan memperbaiki context.

Pemasangan rootless memiliki prasyarat seperti user namespaces, pemetaan subordinate UID/GID, dan helper yang diperlukan distribusi. Ikuti panduan resmi dan rencanakan migrasi image, volume, jaringan, serta limit resource. Data daemon rootful tidak otomatis berpindah ke daemon rootless.

Rootless mengurangi dampak hak istimewa, bukan jaminan kebal kompromi. File yang dapat diakses akun pengguna, bind mount, secret, dan kerentanan kernel tetap perlu diperhitungkan.

6. Docker Desktop macOS dan Windows/WSL2

macOS: Docker Desktop menjalankan Engine Linux dalam VM, tetapi CLI pada host dapat berkomunikasi melalui Unix socket. Tidak benar bahwa CLI macOS harus memakai TCP. Periksa context Desktop, proses Docker Desktop, socket pengguna, dan symlink yang dikelola instalasinya. Group docker Linux bukan perbaikan umum di macOS. Jangan langsung factory reset atau menghapus data Docker hanya karena satu error izin.

Windows/WSL2: pastikan distro yang dimaksud diaktifkan pada Docker Desktop → Settings → Resources → WSL Integration. Bedakan CLI Windows, CLI di WSL dengan integrasi Desktop, dan Engine terpisah yang dipasang di distro WSL. Langkah usermod hanya relevan jika yang diakses benar-benar Engine rootful Linux dengan socket/group tersebut. Hindari mencampur daemon/context tanpa sengaja.

Untuk permission pada bind mount macOS/Windows, periksa izin host, pengaturan berbagi file Desktop, dan pengguna proses container. Itu berbeda dari izin menghubungi socket daemon.

7. SELinux, AppArmor, dan izin di dalam container

Jika izin Unix terlihat benar tetapi akses tetap ditolak, cari bukti penolakan sebelum mengubah kebijakan. Pada distro yang menyediakan auditd/SELinux dan AppArmor, gunakan pemeriksaan yang sesuai:

# SELinux/auditd, bila tersedia; hak administrator mungkin diperlukan
sudo ausearch -m AVC,USER_AVC -ts recent

# Status AppArmor, bila tersedia
sudo aa-status

# Pesan kernel terbaru pada sistem systemd
sudo journalctl -k --no-pager -n 50

Periksa proses, path, label, dan profil yang benar-benar ditolak. Jangan menonaktifkan SELinux atau AppArmor secara menyeluruh sebagai solusi. Koreksi label atau kebijakan secara terbatas bersama administrator; jangan menghasilkan policy baru hanya dengan menyetujui seluruh denial.

Jika daemon dapat diakses tetapi aplikasi container gagal menulis, periksa UID/GID proses, ownership direktori bind mount, mode read-only, serta pemetaan user namespace. Penambahan group Docker pada host tidak memperbaiki ownership file aplikasi di container. Opsi pelabelan volume SELinux juga dapat mengubah label host; jangan menerapkannya ke direktori sistem tanpa memahami dampaknya.

Ringkasan tindakan

Temuan Tindakan yang sesuai
Endpoint/context keliru Pilih daemon yang benar setelah memeriksa override
Group akun benar, sesi belum berubah Logout/login atau gunakan shell newgrp untuk uji terbatas
Akun belum berhak pada Engine rootful Tinjau kebutuhan akses setara root sebelum usermod
Socket tidak ada atau daemon berhenti Periksa service, log, dan konfigurasi; bukan membuka permission
Ownership socket menyimpang Perbaiki sumber konfigurasi bersama administrator
Rootless mengarah ke rootful Periksa context, runtime directory, dan user service
Denial SELinux/AppArmor Diagnosis log dan perbaikan kebijakan terbatas
Error aplikasi di bind mount Periksa UID/GID, mount, dan izin file aplikasi

Batas verifikasi

Review independen lokal 11 September 2026 mencocokkan penjelasan endpoint, privilege group, rootless, Desktop, dan bind mount dengan dokumentasi resmi yang diakses daring. Sintaks shell diperiksa, tetapi tidak ada eksekusi terhadap daemon atau perubahan group, izin socket, service Docker, maupun policy keamanan. Belum ada reproduksi permission denied pada Linux, macOS, atau WSL; contoh output/path bersifat ilustratif. Diagnosis harus disesuaikan dengan OS, metode instalasi, context, dan kebijakan host Anda.

Sumber resmi

Rujukan berikut diperiksa secara daring pada 11 September 2026; verifikasi dokumentasi tidak menggantikan pengujian konfigurasi host: