Bind Mount Folder Projects ke Container Tanpa Drama Permission

Hermes jalan di container, tapi semua project file tetap di host. Awalnya saya ragu mau mount folder Projects ke dalam container — trauma lama gara-gara file jadi root-owned di host, user host kehilangan akses.

Dulu saya pernah ngalamin sendiri: container yang jalan sebagai root (uid 0) nulis file di bind mount, dan pas dibuka di host, file itu punya root. User biasa nggak bisa edit, apalagi delete. Solusi cepat yang beredar ya chmod 777 atau chown rutin. Ampas banget, karena masalahnya balik lagi tiap container nulis file baru.

Saya sempet mikir mending jangan mount aja, copy file tiap kali mau dipakai. Tapi itu makin ribet, karena context yang dilihat agent jadi nggak sinkron sama yang ada di host.

Paritas path

Keputusan pertama: mount ke path yang sama persis di dalam container kayak di host. Di compose, volumenya ditulis ${HOME}/Projects:${HOME}/Projects ; pathnya identik dua sisi. Efeknya, path yang muncul di chat log, config, sampai editor, semua tetap valid dua sisi. Nggak ada lagi "ini path versi container, ini path versi host".

Paritas path itu underrated. Banyak orang lebih repot ganti-ganti path tiap pindah environment daripada ribet sama permission. Orang fokus ke UID mismatch, padahal path mismatch yang bikin workflow agent berantakan diam-diam.

Bentuk finalnya di compose sesederhana ini:

services:
  hermes:
    volumes:
      - ${HOME}/Projects:${HOME}/Projects

Tritnya cuma satu: dua sisi angkanya harus sama. Cek dulu di host:

id -u
# 1000

Lalu bandingkan dengan user yang dipakai proses di dalam container, lalu docker exec ke container itu dan jalankan id. Kalau angkanya beda, di situlah sumber semua drama permission. Perbaikannya bukan chmod, tapi samakan angkanya di sisi container.

Contoh konkret yang bikin keputusan ini keteteran setiap hari: config dan log yang ditulis tool di dalam container nyemplak path absolut. Begitu path dua sisi identik, config itu nggak peduli dia dibaca dari shell container ataupun langsung di host: angkanya sama, filenya sama, posisinya sama. Sekali dua sisi setuju soal peta, nggak ada lapisan terjemahan yang perlu dijaga.

Paritas UID

Keputusan kedua: user di container itu uid 1000, sama persis kayak user saya di host. Kernel Linux cocokkan numeric UID/GID, bukan nama user. Container root (uid 0) yang nulis ke bind mount bikin file root di host Understanding User File Ownership in Docker. Jadi file yang ditulis container di mount ini langsung terbaca sebagai milik user host. Read-write aman tanpa chmod 777.

Ini penyakit klasik yang sering muncul sebagai permission denied di Linux: container jalan sebagai root, host user uid 1000, dan kernel cuma lihat angka yang beda Fixing Docker Permission Denied on Bind Mounted Volumes. Bind mount sendiri artinya mount file atau folder host langsung ke container, tanpa copy dokumentasi bind mounts Docker. Solusi standarnya emang samain UID container sama host user, lewat USER di Dockerfile atau user: di compose Docker Mount Permissions: UID/GID and Five Fixes.

Saya pilih pendekatan ini daripada named volume atau rootless Docker, karena yang dibutuhkan akses langsung ke tree project yang udah ada, lengkap dengan riwayat git-nya. Mount sekali, dua sisi lihat data yang sama.

Kenapa nggak named volume aja supaya Docker yang urus ownership? Buat data aplikasi murni, named volume memang lebih bersih. Tapi tree project yang dipakai dikerjakan aktif (diedit editor, di-commit git, dibaca agent) butuh jadi satu objek yang sama persis dua sisi, bukan salinan yang dikelola Docker. Di titik itu bind mount dengan paritas UID jadi pilihan paling jujur.

Sekarang Hermes bisa baca dan tulis folder Projects di host dari dalam container tanpa drama, dan percaya diri modul-modul seperti OAuth loopback di host-mode tetap jalan di atas setup yang sama. Satu catatan buat masa depan: kalau suatu hari ganti host user dengan uid beda, angka di compose ini yang perlu diubah.