Permission Denied Padahal Sudah chmod 777? Ini Sebabnya

Ada dua keluhan yang kelihatannya kebalikan, tapi penyebabnya biasanya sama.

Yang pertama: "udah chmod 777 tapi tetap Permission denied." Yang kedua: "chmod 777 nyelesaiin, tapi katanya itu bahaya."

Dua-duanya nunjuk ke arah yang sama. Masalahnya bukan di file itu.

Kalau 777 tetap ditolak, cek foldernya

Di folder, bit x bukan berarti "boleh dijalanin". Artinya "boleh dilewatin".

Folder tanpa bit x nggak bisa dimasukin sama sekali, walaupun file di dalamnya boleh dibaca siapa aja.

Jadi kalau /var/www/data/file.txt ditolak padahal filenya udah 777, yang perlu dicek itu tiap folder di sepanjang jalur ke sana:

namei -l /var/www/data/file.txt

Perintah itu nampilin hak akses tiap tingkat sekaligus. Satu folder yang kehilangan x udah cukup mutus seluruh jalur.

Kalau 777 berhasil, yang salah kepemilikan

Ini yang lebih sering, dan lebih bahaya karena berasa selesai.

chmod 777 berhasil bukan karena izinnya tadinya kurang, tapi karena dia ngapus pertanyaan siapa pemiliknya. Semua orang boleh, jadi pemilik nggak relevan lagi.

Yang bener itu benerin pemiliknya:

sudo chown -R www-data:www-data /var/www/situs/writable
sudo chmod -R 775 /var/www/situs/writable

Ganti www-data sama user yang beneran jalanin PHP di server Anda. Cek pakai ps aux | grep php-fpm.

Kenapa 777 bahaya di hosting bareng

Karena "semua orang" di server itu bukan cuma Anda.

Di hosting bareng, akun lain ada di mesin yang sama. Kalau salah satunya kebobol lewat WordPress yang nggak pernah diupdate, folder Anda yang 777 bisa ditulisi proses milik akun itu.

Ini bukan teori. Ini pola serangan yang umum, dan file 777 itu yang pertama dicari.

Angka yang bener

Kalkulator chmod & Hak Akses nerjemahin angka ke arti dan sebaliknya, termasuk beda arti tiap bit di file sama folder.

Satu file yang harganya seluruh database

.env isinya kredensial database, kunci API, sama password email. Kalau dia bisa diunduh publik, semuanya ikut.

Ini kejadian kalau document root diarahin ke akar proyek, bukan ke public/. Pemindai otomatis nyoba /.env di tiap situs yang ketemu. Bukan karena nyari Anda, tapi karena nyoba semua.

Tutup di tingkat server web:

location ~ /(\.env|composer\.(json|lock))$ {
    deny all;
}

Generator Konfigurasi Nginx & Apache udah masukin ini secara default.

Kalau semua udah dicek tapi masih ditolak

Tersangka berikutnya bukan hak akses:

• SELinux di CentOS, Rocky, AlmaLinux. Cek getenforce.
• Pembatas systemd. Kalau layanannya jalan lewat systemd dengan ProtectSystem=full, hampir seluruh filesystem jadi read-only dari sudut pandangnya. Ada di Cron tidak jalan padahal perintahnya benar.
• Mount read-only. Cek mount | grep ro,.

Baca juga

• Cron tidak jalan padahal perintahnya benar
• Kalkulator chmod & Hak Akses
• Generator Unit systemd