DevOps dari nol · Pelajaran 22 dari 25 · 15 menit

Cara Membaca Permission File Linux: ls -l, chmod, chown

Cara membaca permission file Linux: ls -l, arti r/w/x di file dan folder, angka 600/644/755, chmod, chown, umask, dan uid saat container menulis file.

Oleh Matthews WongDitinjau pada 18 Oktober 2026

Poin utama

Permission file di Linux menentukan proses mana yang boleh membaca, menulis, atau menjalankan sebuah file. Setiap file menyimpan uid pemilik, gid grup, dan sembilan bit mode: read, write, dan execute untuk pemilik, grup, dan semua orang lain. Kernel membandingkan id numerik proses dengan id milik file, memilih tepat satu dari tiga set itu, lalu memeriksa bit-nya. Root melewati pemeriksaan ini.

Setelah pelajaran ini, Anda bisa

Membaca satu baris ls -l dari kiri ke kanan, lalu mengubah mode-nya ke angka oktal dan sebaliknya.
Menjelaskan arti r, w, dan x pada direktori, dan kenapa bit pemilik tetap berlaku walaupun memberi akses lebih sedikit daripada bit lainnya.
Memperbaiki Permission denied antara container dan file di host dengan menyamakan uid, bukan dengan chmod 777.

Lihat cara kerjanya

Ikuti diagramnya langkah demi langkah

Tekan Putar, atau melangkah dengan panah. Setiap langkah juga ditulis di bawah diagram.

Bagaimana kernel memutuskan siapa yang boleh menulis file

Satu file di host, mode 640, milik uid 1000. Shell Anda menulisnya lewat bit pemilik, container yang berjalan sebagai uid 1001 jatuh ke bit other dan ditolak, root melewati semua bit, dan chown ke 1001 membuat container masuk lewat bit pemilik.

report.txt ada di folder host yang di-mount oleh container. Pemiliknya uid 1000, grup 1000, mode 640. Shell Anda, container app, dan root masing-masing mencoba menulisnya.-rw-r----- 1 1000 1000 report.txt

Tombol: ← → langkah · Home / End · K putar atau jeda

report.txt ada di folder host yang di-mount oleh container. Pemiliknya uid 1000, grup 1000, mode 640. Shell Anda, container app, dan root masing-masing mencoba menulisnya.
-rw-r----- 1 1000 1000 report.txt
Shell Anda berjalan sebagai uid 1000, pemilik file itu. Kernel memakai bit owner, rw-, dan tidak melihat yang lain. Bit write menyala, jadi penulisan berhasil.
echo ok >> report.txtTebak langkah berikutnya Berikutnya, container app menulis sebagai uid 1001, yang bukan anggota grup 1000. Bit mana yang menentukan? (Bit owner, rw- · Bit group, r-- · Bit other, ---)
Di dalam container, prosesnya adalah uid 1001. Kernel hanya melihat angka itu: bukan 1000, bukan anggota grup 1000. Jadi bit other, ---, yang menentukan: Permission denied.
touch: report.txt: Permission denied
Root, uid 0, melewati pemeriksaan read dan write. Karena itu mount yang sama berjalan saat image masih memakai root, lalu rusak begitu image beralih lewat USER.
CAP_DAC_OVERRIDETebak langkah berikutnya Apa perubahan paling kecil agar uid 1001 bisa menulis report.txt? (chmod 777 report.txt · chown 1001 report.txt · Jalankan container sebagai root)
chown 1001 menjadikan uid 1001 pemiliknya dan grupnya tetap 1000. Container app kini mendapat bit owner, rw-, dan shell Anda tetap bisa membaca lewat bit group.
sudo chown 1001 report.txt

Apa itu permission file di Linux?

Permission file di Linux adalah aturan yang dipakai kernel setiap kali sebuah proses membuka, membuat, atau menjalankan file. Inode setiap file mencatat dua angka, yaitu user ID pemilik dan group ID, ditambah mode: sembilan bit permission dan tiga bit khusus. Sembilan bit itu adalah read, write, dan execute, masing-masing sekali untuk pemilik, sekali untuk grup, dan sekali untuk semua orang lain.

Baca selengkapnya (2)

Pemeriksaannya sendiri singkat. Kalau user ID proses sama dengan pemilik file, kernel memakai tiga bit pertama. Kalau tidak, dan grup file itu adalah grup proses atau salah satu supplementary group-nya, kernel memakai tiga bit tengah. Selain itu, yang dipakai tiga bit terakhir. Hanya satu set yang dipakai, jadi pemilik file ----r--r-- tidak bisa membacanya, padahal semua orang lain bisa.

Root adalah pengecualian. Man page path_resolution menyebut superuser melewati pemeriksaan permission; di Linux kemampuan itu adalah capability CAP_DAC_OVERRIDE, yang tetap hanya memberi izin execute kalau minimal satu bit execute menyala. Docker mempertahankan DAC_OVERRIDE di daftar capability default-nya, dan container berjalan sebagai root kecuali image atau docker run menentukan lain. Karena itu banyak hal lancar saja sampai sebuah image beralih ke user biasa.

Bagaimana membaca ls -l dari kiri ke kanan?

Ambil contoh baris -rw-r--r-- 1 alice staff 6 Oct 18 08:40 notes.txt. Karakter pertama adalah jenis file: - untuk file biasa, d untuk direktori, l untuk symbolic link. Sembilan karakter berikutnya adalah mode dalam tiga kelompok berisi tiga: rw- untuk pemilik, r-- untuk grup, r-- untuk semua orang lain. Tanda strip berarti bit itu mati.

Baca selengkapnya (2)

GNU ls bisa mencetak satu karakter lagi tepat setelah mode: titik untuk file yang punya security context SELinux, tanda plus untuk metode akses lain seperti ACL. Setelah itu ada jumlah hard link, pemilik, grup, ukuran dalam byte, waktu modifikasi, dan nama file. Di posisi execute, s berarti set-user-ID atau set-group-ID ditambah execute, t berarti sticky bit ditambah execute, dan huruf besar S atau T berarti bit khusus itu menyala tanpa execute.

Pemilik dan grup ditampilkan sebagai nama, tetapi yang disimpan file adalah angka. ls memetakan user ID ke nama lewat /etc/passwd, dan kalau sebuah angka tidak punya nama, GNU ls mencetak angkanya saja. ls -n melewati nama dan menampilkan user ID serta group ID dalam bentuk angka. Tampilan inilah yang penting ketika container dan host berbagi file.

Apa arti r, w, dan x pada direktori?

Pada file, r membaca isinya, w mengubahnya, dan x menjalankan file itu sebagai program. Pada direktori, bit yang sama punya arti lain. Manual GNU coreutils menyebutnya dengan jelas: read untuk melihat daftar isi, write untuk membuat dan menghapus file di dalamnya, dan execute untuk mengakses file di dalamnya. Karena itu x pada direktori juga disebut search.

Baca selengkapnya (2)

Keduanya bisa terpisah. Dengan r tanpa x, Anda bisa membaca nama-nama file tetapi tidak bisa membuka apa pun di dalamnya, dan GNU ls -l mencetak tanda tanya di tempat detailnya. Dengan x tanpa r, Anda tidak bisa melihat daftar isi direktori, tetapi tetap bisa membuka file yang namanya sudah Anda ketahui. Untuk menjangkau sebuah file, proses butuh x di setiap direktori sepanjang path-nya; satu x yang hilang membuat pencarian berhenti dengan Permission denied.

Menghapus adalah perubahan pada direktori, bukan pada file. rm -f bisa menghapus file read-only milik Anda dari direktori yang bisa Anda tulisi, dan gagal untuk file apa pun di dalam direktori bermode 555. Sticky bit, yaitu huruf t di ujung drwxrwxrwt milik /tmp, mempersempitnya lagi: di sana hanya pemilik file, pemilik direktori, atau proses privileged yang bisa menghapus atau mengganti nama sebuah file.

Bagaimana cara kerja mode oktal seperti 600, 644, dan 755?

Setiap kelompok tiga bit muat dalam satu digit oktal: read bernilai 4, write 2, execute 1, lalu dijumlahkan. rw- adalah 6, r-x adalah 5, r-- adalah 4, dan --- adalah 0. Tiga digit mewakili pemilik, grup, dan semua orang lain, dengan urutan itu. Jadi 644 adalah rw-r--r--, 600 adalah rw-------, 755 adalah rwxr-xr-x, dan 700 adalah rwx------.

Baca selengkapnya (1)

Digit keempat yang opsional di depan menyimpan bit khusus: 4 untuk set-user-ID, 2 untuk set-group-ID, 1 untuk sticky bit. Karena itu ssh menampilkan mode sebuah key sebagai 0640: angka nol di depan adalah digit khusus yang kosong. Pilihan yang umum dipakai mengikuti siapa butuh apa: 644 untuk file yang boleh dibaca siapa saja, 755 untuk direktori dan program yang boleh dimasuki atau dijalankan siapa saja, 600 untuk secret, dan 700 untuk direktori pribadi.

chmod: simbol atau angka oktal?

chmod menerima kedua bentuk. Mode oktal menyetel semua bit sekaligus dan mengganti nilai sebelumnya; manual GNU mencatat bahwa bentuk ini hanya bisa menyetel bit secara absolut. Mode simbol hanya mengubah yang Anda sebut: siapa (u untuk pemilik, g untuk grup, o untuk orang lain, a untuk semua), operator (+ menambah, - mengurangi, = menyetel persis dan mengosongkan sisanya untuk pihak itu), dan bit-nya (r, w, x, ditambah X, s, dan t).

Baca selengkapnya (2)

Jadi chmod 640 notes.txt dan chmod u=rw,g=r,o= notes.txt menghasilkan mode yang sama, sedangkan chmod g+r hanya menambah izin baca untuk grup dan mempertahankan sisanya. Kalau huruf siapa dihilangkan, chmod bekerja seolah Anda menulis a, kecuali bit yang ada di umask dibiarkan: dengan umask 022, chmod +w hanya menambah write untuk pemilik, sedangkan a+w memberikannya ke semua orang. -R menelusuri seluruh pohon direktori, dan chmod tidak pernah mengubah permission milik symbolic link itu sendiri.

Hanya pemilik file atau proses privileged yang boleh mengubah mode-nya; selain itu hasilnya EPERM. Aturan ini melihat kepemilikan, bukan mode, sehingga di latihan di bawah Anda bisa mengunci diri dari sebuah file dengan chmod 044 dan tetap bisa membukanya kembali dengan chmod 644.

chown, dan kenapa pemilik file berupa angka

chown OWNER:GROUP file mengubah keduanya, chown OWNER file hanya mengubah pemilik, chown :GROUP file hanya mengubah grup, dan OWNER: dengan titik dua di belakang juga menyetel grupnya ke login group milik user itu. OWNER dan GROUP boleh berupa nama atau angka. Mengganti pemilik butuh hak istimewa, yaitu CAP_CHOWN di Linux, karena itu Anda mengetik sudo chown; pemilik file hanya boleh mengganti grupnya ke grup yang ia ikuti.

Baca selengkapnya (1)

Kernel tidak pernah melihat nama. User ID dan group ID sebuah proses adalah bilangan bulat, inode menyimpan pemilik dan grup sebagai bilangan bulat, dan /etc/passwd hanyalah tabel yang mengubah nama login menjadi user ID dan primary group ID berupa angka. Dua sistem yang berbagi file bisa memberi nama berbeda untuk angka yang sama, atau tidak memberi nama sama sekali, dan kernel tidak peduli.

Container menulis file sebagai uid berapa?

Angka berapa pun yang dipakai prosesnya. User default di dalam container Docker adalah root, uid 0. USER di Dockerfile menyetel user, lewat nama atau UID, untuk sisa stage itu, termasuk RUN dan perintah container, dan docker run --user bisa memilihnya saat container dijalankan. COPY membuat file milik UID dan GID 0 kecuali --chown menyebut lain; nama di --chown dicari di /etc/passwd dan /etc/group milik image itu sendiri, sedangkan ID berupa angka tidak perlu dicari.

Baca selengkapnya (2)

Di bind mount tidak ada penerjemahan. Kecuali daemon memakai user namespace remapping, yang harus Anda aktifkan sendiri, uid yang dipakai proses container untuk menulis adalah uid yang disimpan host. Dalam uji coba di host Docker Linux, container root meninggalkan file milik 0, container yang berjalan sebagai 1001 meninggalkan file milik 1001, dan folder host milik 1000 dengan mode 755 menolak uid 1001: bukan pemilik, bukan anggota grup, jadi yang berlaku bit other r-x.

Docker Desktop di Mac membagikan folder host lewat lapisan file sharing miliknya sendiri, dan uji coba yang sama di sana hasilnya berbeda: penulisan berhasil dan file-nya tercatat milik user Mac. Jadi reproduksi masalah kepemilikan di host Linux, atau dengan named volume, yang dengan langkah sama tetap menghasilkan Permission denied di Docker Desktop.

Apa fungsi umask?

umask menentukan permission apa yang tidak didapat file baru. Program meminta sebuah mode saat membuat file, lalu kernel mematikan setiap bit yang menyala di umask milik proses itu. Default yang umum adalah 022, yang membuang write untuk grup dan semua orang lain: file yang diminta dengan mode 0666 jadi 0644, rw-r--r--. Proses anak mewarisi umask induknya, jadi nilai awal sebuah shell atau service berlaku untuk semua yang dijalankannya.

Baca selengkapnya (1)

Jalankan umask untuk melihat nilai Anda: di latihan, macOS mencetak 022 dan Alpine mencetak 0022, lalu file baru jadi 644 dan direktori baru jadi 755. umask hanya bekerja saat file dibuat. File yang sudah ada tetap mempertahankan mode-nya ketika sebuah program mengosongkan lalu menulis ulang isinya, jadi memperketatnya belakangan adalah tugas chmod, dan script yang menulis secret bisa menjalankan umask 077 lebih dulu supaya file-nya langsung lahir dengan mode 600.

Cara situs ini melakukannya

Konfigurasi nyata di balik pelajaran ini

Kutipan dari repositori yang membangun dan men-deploy situs ini, apa adanya.

Dockerfile:63-69

RUN addgroup --system --gid 1001 nodejs && adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs

Tiga keputusan kepemilikan. public disalin tanpa --chown, jadi miliknya uid dan gid 0 dan server membacanya lewat bit other. File server dan file statis mendapat --chown=nextjs:nodejs, tersimpan sebagai 1001:1001, dan USER nextjs membuat prosesnya berjalan sebagai uid 1001, pemilik file itu, sehingga kernel memberinya bit owner. Saat baris-baris ini di-build di node:20-alpine lalu id dijalankan, hasilnya uid=1001(nextjs) gid=65533(nogroup): adduser --system memasukkan nextjs ke nogroup, jadi proses ini tidak pernah cocok dengan grup nodejs di file miliknya sendiri.

.github/workflows/deploy.yml:226-234

            cat > .env <<'ENVEOF'
            GROQ_API_KEY=${{ secrets.GROQ_API_KEY }}
            RESEND_API_KEY=${{ secrets.RESEND_API_KEY }}
            CONTACT_FROM_EMAIL=${{ vars.CONTACT_FROM_EMAIL }}
            CONTACT_TO_EMAIL=${{ vars.CONTACT_TO_EMAIL }}
            IMAGE=${{ needs.build-and-push.outputs.image }}
            APP_PORT=${{ vars.APP_PORT || 3002 }}
            ENVEOF
            chmod 600 .env

cat > .env membuat file dengan mode sisa dari umask server, 644 dengan umask umum 022, yang bisa dibaca akun lain yang bisa menjangkau folder itu. chmod 600 menyisakan read dan write hanya untuk user deploy, dan docker compose berjalan sebagai user yang sama di sesi SSH yang sama, jadi bit owner sudah cukup. Pada deploy berikutnya file itu sudah ada, jadi cat hanya mengosongkannya dan mode 600 tetap: mode hanya diterapkan saat file dibuat.

Yang sering rusak

Kesalahan yang benar-benar membuang waktu

Permission denied di bind mount setelah menambahkan USER
Dulu container berjalan sebagai root, yang melewati semua bit. Sekarang container berjalan sebagai uid 1001, sedangkan folder host milik uid Anda, atau milik root kalau folder itu dibuat oleh docker run -v. Bandingkan ls -ln di host dengan id di dalam container, lalu samakan angkanya: sudo chown 1001 untuk folder itu, atau jalankan container dengan --user "$(id -u):$(id -g)".
chmod 777 membuat error-nya hilang
Cara ini berhasil karena menyalakan rwx di bit other, sehingga setiap uid di mesin itu lolos pemeriksaan. Pada direktori, artinya akun atau container mana pun bisa membuat, menghapus, dan mengganti nama file di dalamnya. Ketidakcocokan uid-nya tetap ada; Anda hanya berhenti melihatnya. Serahkan file ke uid yang menulisnya, atau pakai grup bersama: chgrp folder itu ke grup yang diikuti proses, lalu chmod g+w.
WARNING: UNPROTECTED PRIVATE KEY FILE
OpenSSH mencetak Permissions 0640 for 'lab_key' are too open, lalu mengabaikan key itu. Manual ssh menyatakan private key tidak boleh bisa diakses orang lain, dan dalam uji coba, izin baca untuk grup saja sudah cukup memicunya. chmod 600 pada key memperbaikinya, dan 400 juga bisa. Ini klien yang memeriksa file Anda sendiri; pelajaran 2 membahas apa yang diperiksa server.
Permission denied saat menjalankan script sendiri
./deploy.sh butuh bit execute, sedangkan file baru yang dibuat dengan echo, printf, atau touch dimulai dengan mode 644 jika umask-nya 022. Shell melaporkan Permission denied dengan exit status 126. Jalankan chmod u+x deploy.sh, atau 755 kalau orang lain juga perlu menjalankannya. sh deploy.sh bisa jalan tanpa x, karena yang dijalankan adalah program sh dan script itu hanya file yang dibacanya.

Dua bentuk chmod, sesuai penjelasan manual GNU coreutils.
Aspek	Oktal: chmod 640	Simbol: chmod g+r
Yang diubah	Semua bit permission sekaligus	Hanya pihak dan bit yang Anda sebut
Bit yang tidak disebut	Diganti	Dipertahankan, kecuali untuk pihak di operasi =
umask	Diabaikan	Dihormati kalau huruf siapa dihilangkan
Pakai saat	Anda tahu mode akhirnya: 600, 644, 755	Anda menambah atau membuang satu hal: u+x, o-r

Coba sendiri

Lakukan di komputer Anda sendiri

Langkah 1 sampai 5 hanya butuh terminal di Linux, macOS, atau WSL; langkah 6 butuh Docker. Jalankan sebagai user biasa, bukan dengan sudo atau sebagai root, karena root melewati semua pemeriksaan. Output yang dikutip sudah dicek di macOS dan di container Alpine Linux.

1
Buat folder latihan lalu baca long listing-nya. Dengan umask 022, hasilnya -rw-r--r-- untuk file dan drwxr-xr-x untuk folder, atau drwxr-sr-x kalau folder induknya punya bit set-group-ID. ls -ln menampilkan baris yang sama dengan angka, bukan nama.
```
mkdir perm-lab && cd perm-lab
echo "hello" > notes.txt
mkdir box && echo "inside" > box/file.txt
ls -l
ls -ln
umask
```
2
Setel mode dengan angka oktal, lalu tambahkan bit dengan simbol. Setelah itu buang bit baca milik Anda sendiri: cat gagal dengan Permission denied walaupun grup dan orang lain boleh membaca, dan chmod tetap bisa karena Anda pemilik file-nya.
```
chmod 600 notes.txt && ls -l notes.txt
chmod g+r,o+r notes.txt && ls -l notes.txt
chmod 044 notes.txt
cat notes.txt
chmod 644 notes.txt
```
3
Pisahkan r dari x pada direktori. Di mode 600, ls bisa mencetak nama, error, atau keduanya, tergantung ls yang Anda pakai, tetapi cat gagal. Di mode 100, ls gagal tetapi cat lewat nama file mencetak inside.
```
chmod 600 box
ls box
cat box/file.txt
chmod 100 box
ls box
cat box/file.txt
chmod 755 box
```
4
Script baru tidak bisa dijalankan sebelum punya x. ./run.sh yang pertama gagal dengan Permission denied; setelah chmod u+x, hasilnya ran.
```
printf '#!/bin/sh\necho ran\n' > run.sh
./run.sh
chmod u+x run.sh && ./run.sh
```
5
Lihat ssh menolak key yang bisa dibaca grup: Permissions 0640 for 'lab_key' are too open. Setelah chmod 600, perintah yang sama mencetak public key-nya.
```
ssh-keygen -q -t ed25519 -N "" -f lab_key
chmod 640 lab_key
ssh-keygen -y -f lab_key
chmod 600 lab_key && ssh-keygen -y -f lab_key
```

Sekarang bagian container, memakai named volume supaya hasilnya sama di semua platform. Root membuat folder, uid 1001 ditolak, lalu setelah chown ke angka itu, uid 1001 bisa menulis dan ls -ln menampilkan 1001.

docker volume create perm-lab
docker run --rm -v perm-lab:/data alpine:3 sh -c 'mkdir /data/out && ls -ln /data'
docker run --rm --user 1001:1001 -v perm-lab:/data alpine:3 touch /data/out/report.txt
docker run --rm -v perm-lab:/data alpine:3 chown 1001:1001 /data/out
docker run --rm --user 1001:1001 -v perm-lab:/data alpine:3 sh -c 'touch /data/out/report.txt && ls -ln /data/out'

Bersihkan volume dan folder latihannya.

docker volume rm perm-lab
cd .. && rm -rf perm-lab

Kuis singkat

Tiga pertanyaan sebelum lanjut

Pilih jawaban untuk melihat kenapa benar atau salah. Tidak ada nilai, jadi tebak saja dengan bebas; jawaban yang salah disimpan di browser ini agar kursus bisa menanyakannya lagi nanti.

1.ls -l menampilkan -rw-r----- untuk sebuah file. Berapa mode itu dalam oktal?
2.Sebuah direktori bermode drwx--x--x dan milik alice. Apa yang bisa dilakukan bob, yang bukan anggota grupnya, terhadap direktori itu?
3.Container yang berjalan sebagai uid 1001 mendapat Permission denied saat menulis ke folder host yang di-bind mount, milik uid 1000 dengan mode 755. Apa perbaikan yang paling sempit?

Dari pelajaran sebelumnya

Dua pertanyaan dari pelajaran sebelumnya

Mengingat kembali pelajaran lama setelah jeda membuatnya lebih melekat. Jawab dari ingatan sebelum mencari apa pun.

1.Referensi GitHub menyebut if: !cancelled() harus dibungkus ${{ }} atau diberi tanda kutip. Kenapa?
2.Sebuah swarm punya tiga manager. Berapa yang boleh gagal sebelum quorum hilang?

Dari: 21. Belajar YAML untuk Pemula: Map, List, Quote, dan Jebakannya · 19. Belajar Docker Swarm: Service, Routing Mesh, dan Rolling Update

Pikirkan dulu

Jawab dalam hati, lalu cek

1.Sebuah file milik Anda bermode 604. Bisakah Anda menulisinya? Bisakah anggota grupnya, yang bukan Anda, membacanya?Lihat jawabannya
Jawaban:Ya, Anda mendapat bit owner, rw-. Tidak, anggota grup mendapat bit group, ---, padahal semua orang di luar grup boleh membaca lewat bit other, r--. Kernel hanya memakai tepat satu set.
2.Kenapa ls -l di dalam container kadang mencetak 1001 di tempat yang Anda kira berisi nama?Lihat jawabannya
Jawaban:File hanya menyimpan angkanya. ls mencarinya di /etc/passwd milik container itu sendiri, dan kalau image tersebut tidak punya user dengan uid 1001, yang dicetak adalah angkanya.
3.Kenapa deploy situs ini menjalankan chmod 600 tepat setelah menulis .env?Lihat jawabannya
Jawaban:File itu berisi secret, dan file yang dibuat dengan umask umum 022 bermode 644, bisa dibaca akun lain di server. 600 menyisakan read dan write hanya untuk user deploy, yaitu user yang menjalankan docker compose.

Pelajari lebih dalam

Bahasan mendalam terkait di situs ini

Sumber

Sumber primer yang diperiksa pada tanggal riset. Ikuti tautannya untuk versi terbaru.

Pelajaran sebelumnyaBelajar YAML untuk Pemula: Map, List, Quote, dan Jebakannya Pelajaran berikutnyaCara Membuat Healthcheck Docker dan Memilih Restart Policy

Ikuti diagramnya langkah demi langkah

Bagaimana kernel memutuskan siapa yang boleh menulis file

Apa itu permission file di Linux?

Bagaimana membaca ls -l dari kiri ke kanan?

Apa arti r, w, dan x pada direktori?

Bagaimana cara kerja mode oktal seperti 600, 644, dan 755?

chmod: simbol atau angka oktal?

chown, dan kenapa pemilik file berupa angka

Container menulis file sebagai uid berapa?

Apa fungsi umask?

Konfigurasi nyata di balik pelajaran ini

Kesalahan yang benar-benar membuang waktu

Permission denied di bind mount setelah menambahkan USER

chmod 777 membuat error-nya hilang

WARNING: UNPROTECTED PRIVATE KEY FILE

Permission denied saat menjalankan script sendiri

Lakukan di komputer Anda sendiri

Tiga pertanyaan sebelum lanjut

Dua pertanyaan dari pelajaran sebelumnya

Jawab dalam hati, lalu cek

Bahasan mendalam terkait di situs ini

Sumber