Server Solusi – Pesan Permission denied pada Nginx biasanya menunjukkan bahwa proses Nginx tidak memiliki izin yang diperlukan untuk membaca file, mengakses direktori, atau membuka resource tertentu. Masalah ini bisa membuat website menampilkan halaman 403 Forbidden, menghasilkan 500 Internal Server Error dalam kondisi tertentu, atau mencatat error meskipun service Nginx masih berjalan normal.

Penyebabnya tidak selalu terletak pada permission file. Direktori induk yang tidak bisa diakses, ownership yang keliru, konfigurasi PHP-FPM, hingga kebijakan keamanan SELinux juga bisa menjadi sumber masalah.

Dalam panduan ini, saya akan menguraikan alur diagnosis yang bisa kamu gunakan pada VPS Linux, terutama Ubuntu dan Debian dengan Nginx. Karena belum ada log error atau konfigurasi server tertentu yang diberikan, langkah-langkah berikut merupakan panduan troubleshooting, bukan laporan perbaikan yang diklaim sudah diuji pada server nyata.

Mengapa Nginx Mengalami Permission Denied?

Cara memperbaiki Nginx permission denied adalah dengan memeriksa log error, memastikan user yang menjalankan Nginx memiliki akses yang sesuai terhadap file dan seluruh direktori induknya, lalu memeriksa pembatas keamanan tambahan jika permission sudah benar.

Jangan langsung menjalankan chmod 777 pada direktori website. Tindakan tersebut memberikan izin terlalu luas dan tidak selalu menyelesaikan masalah. Mulailah dengan menemukan path yang ditolak, mengetahui proses yang mengaksesnya, dan memperbaiki izin hanya pada bagian yang bermasalah.

Gejala dan Penyebab Nginx Permission Denied

Sebelum mengubah permission, perhatikan pesan error yang muncul dan kapan masalah mulai terjadi. Detail tersebut membantu mempersempit kemungkinan penyebab.

1. Nginx tidak bisa membaca file website

Log dapat menampilkan pesan seperti berikut:

open() "/var/www/html/index.html" failed (13: Permission denied)

Contoh tersebut menggambarkan kegagalan akses ketika Nginx mencoba membuka file. Angka 13 merujuk pada EACCES, yaitu akses ditolak oleh sistem operasi.

Kemungkinan penyebabnya meliputi:

• File tidak memiliki izin baca untuk user atau grup Nginx.

• Salah satu direktori induk tidak mengizinkan proses Nginx melewatinya.

• Ownership file berubah setelah deployment atau pemindahan website.

• Kebijakan keamanan sistem membatasi akses meskipun permission Unix terlihat benar.

  Baca JugaCara Mengatasi Konflik Port Nginx dan Apache di VPS Linux

Path pada log perlu diperiksa secara spesifik. Jangan menganggap seluruh direktori website bermasalah hanya karena satu file gagal dibaca.

2. Website menampilkan 403 Forbidden

Status HTTP 403 Forbidden berarti server menolak memenuhi permintaan. Dalam konteks Nginx, salah satu penyebabnya adalah akses ke file atau direktori ditolak.

Namun, status 403 tidak selalu berarti permission Linux salah. Konfigurasi deny, aturan akses pada blok location, atau kondisi direktori tanpa index yang sesuai juga dapat menghasilkan respons tersebut.

Periksa log dan konfigurasi terlebih dahulu sebelum mengubah hak akses file.

3. Error muncul setelah deployment atau perubahan server

Jika website sebelumnya berjalan normal lalu mengalami permission denied setelah deployment, pemindahan file, restore backup, atau perubahan user aplikasi, periksa perubahan ownership dan permission.

Sebagai contoh, file yang disalin menggunakan akun administrator bisa memiliki owner berbeda dari file sebelumnya. Hal itu belum tentu bermasalah, tetapi akses tetap harus sesuai dengan user yang menjalankan proses terkait.

4. File bisa dibaca, tetapi Nginx tetap ditolak

Jika permission dan ownership tampak benar, jangan terus menambahkan izin secara acak. Pada sistem yang menggunakan SELinux, akses juga dipengaruhi oleh security context. Kebijakan tersebut dapat menolak akses yang sebenarnya diizinkan oleh permission Unix biasa.

Pada tahap ini, kamu perlu memeriksa log keamanan dan konteks file, terutama jika menggunakan distribusi Linux berbasis RHEL, Rocky Linux, AlmaLinux, atau CentOS.

Cara Mendiagnosis Penyebabnya

Saya menyarankan pemeriksaan dilakukan secara berurutan, mulai dari log hingga izin akses pada path yang dilaporkan.

1: Periksa log error Nginx

Pada Ubuntu dan Debian dengan instalasi Nginx standar, jalankan:

sudo tail -n 100 /var/log/nginx/error.log

Perintah tersebut menampilkan 100 baris terakhir dari log error. Jika pesan permission denied muncul berulang kali, perhatikan bagian open(), stat(), atau operasi file lain yang gagal.

Kamu juga dapat mengikuti log secara langsung:

sudo tail -f /var/log/nginx/error.log

Biarkan perintah berjalan, kemudian akses kembali halaman website yang bermasalah melalui browser atau permintaan HTTP yang sesuai. Tekan Ctrl+C untuk menghentikan pemantauan.

Baca JugaCara Mengatasi Nginx Tidak Bisa Terhubung ke PHP-FPM di Ubuntu

Jika file log tersebut tidak ditemukan, periksa konfigurasi error_log Nginx atau log melalui systemd:

sudo journalctl -u nginx -n 100 --no-pager

Yang perlu dicari: path file yang ditolak, kode error, dan waktu kejadian. Jika log menunjukkan kegagalan pada socket PHP-FPM, file log, atau direktori cache, penanganannya berbeda dari file HTML biasa.

2: Pastikan user worker Nginx

Nginx memiliki proses master dan worker. Pada instalasi Linux yang umum, proses master berjalan dengan hak istimewa lebih tinggi, sedangkan worker menangani permintaan menggunakan user yang dibatasi.

Periksa proses yang sedang berjalan:

ps -eo user,group,pid,comm,args | grep '[n]ginx'

Perhatikan user pada baris worker, bukan hanya proses master.

Untuk memeriksa konfigurasi yang digunakan Nginx:

sudo nginx -T 2>&1 | grep -E '^[[:space:]]*user[[:space:]]'

Direktif user dalam konfigurasi utama menentukan kredensial user dan grup untuk worker jika Nginx dijalankan dengan hak yang memungkinkan pengaturan tersebut. Jika direktif tidak terlihat, jangan langsung menyimpulkan user yang digunakan; periksa hasil proses dan cara instalasinya.

Pada banyak instalasi Ubuntu atau Debian, worker menggunakan user www-data. Akan tetapi, server dengan panel hosting, container, atau konfigurasi khusus dapat menggunakan user berbeda.

3: Periksa permission dan ownership file

Misalnya, log menunjukkan bahwa Nginx gagal membuka file berikut:

/var/www/html/index.html

Periksa atribut file tersebut:

ls -l /var/www/html/index.html

Kemudian periksa seluruh direktori induknya:

namei -l /var/www/html/index.html

Perintah kedua sangat berguna karena akses ke file bergantung pada setiap komponen path. User yang mengakses file memerlukan izin execute (x) pada direktori induk untuk melewatinya, serta izin baca yang sesuai pada file.

Contohnya, jika /var/www dapat diakses tetapi /var/www/html memiliki permission yang terlalu ketat, Nginx mungkin tidak dapat mencapai file meskipun file tersebut sendiri memiliki izin baca.

Jangan mengubah permission dulu. Gunakan hasil pemeriksaan untuk menentukan komponen path mana yang benar-benar menghalangi akses.

Baca JugaCara Mengatasi Error 502 Bad Gateway Nginx: Diagnosis dan Solusinya

4: Periksa konfigurasi document root

Cari konfigurasi virtual host yang digunakan website:

sudo nginx -T

Perintah ini menampilkan konfigurasi aktif yang berhasil dimuat Nginx, termasuk file yang diikutsertakan melalui include. Output-nya bisa panjang, jadi kamu dapat mencari nama domain atau direktif root dan alias.

Contoh konfigurasi:

server {listen 80;server_name example.com;root /var/www/example.com/public;index index.html index.htm;location / {try_files $uri $uri/ =404;}}

Dalam contoh tersebut, Nginx mencari file website di /var/www/example.com/public. Jika log justru menunjukkan path lain, periksa apakah ada konfigurasi root, alias, atau blok location lain yang memengaruhi permintaan tersebut. Fungsi root dan alias dijelaskan dalam dokumentasi modul HTTP Nginx.

Periksa juga apakah symlink mengarah ke direktori yang memiliki batasan akses. Jangan mengubah konfigurasi hanya berdasarkan contoh di atas; sesuaikan dengan konfigurasi aktif server kamu.

Langkah Memperbaiki Nginx Permission Denied

Setelah menemukan lokasi penolakan akses, pilih solusi sesuai hasil diagnosis. Tidak semua server membutuhkan perubahan permission, dan beberapa kasus justru memerlukan perbaikan konfigurasi keamanan atau user aplikasi.

1. Perbaiki permission file dan direktori yang bermasalah

Untuk file statis yang memang perlu disajikan kepada pengunjung, pola permission yang umum digunakan adalah:

• Direktori: 755

• File: 644

Angka tersebut merupakan contoh pola permission, bukan aturan yang wajib diterapkan ke seluruh isi website.

Misalnya, kamu sudah memastikan bahwa /var/www/example.com/public merupakan document root yang benar dan file statis di dalamnya harus dapat dibaca Nginx. Kamu dapat mengatur permission pada file dan direktori yang sesuai.

Untuk satu file:

sudo chmod 644 /var/www/example.com/public/index.html

Untuk satu direktori:

sudo chmod 755 /var/www/example.com/public

Perintah pertama memberikan izin baca kepada owner, grup, dan pengguna lain. Perintah kedua memberikan izin baca dan traverse kepada pengguna lain, dengan izin tulis hanya untuk owner.

Penting: perintah tersebut tidak memperbaiki direktori induk lain yang berada di luar path itu. Jika namei -l menunjukkan direktori induk bermasalah, periksa izin direktori tersebut secara terpisah.

Baca JugaCara Mengatasi Apache Failed to Start di Ubuntu: Diagnosis dan Perbaikan

Hindari menerapkan chmod -R 777 atau mengganti permission seluruh direktori website tanpa mengetahui kebutuhan aplikasinya. File konfigurasi sensitif, direktori upload, dan file aplikasi tidak semuanya memerlukan hak akses yang sama.

2. Perbaiki ownership jika memang salah

Permission yang terlihat benar belum tentu cukup jika file dimiliki user atau grup yang tidak sesuai dengan rancangan akses server.

Periksa terlebih dahulu:

ls -ld /var/www/example.comls -l /var/www/example.com/public/index.html

Jika kamu memastikan bahwa file statis seharusnya dimiliki akun deployment tertentu dan dibaca oleh grup web server, perbaiki ownership sesuai desain tersebut.

Contoh, jika grup www-data memang ditetapkan untuk akses baca file statis:

sudo chgrp www-data /var/www/example.com/public/index.htmlsudo chmod 640 /var/www/example.com/public/index.html

Dengan pola tersebut, owner dan anggota grup dapat membaca file, sementara pengguna lain tidak memperoleh izin baca.

Perintah ini hanya tepat jika user worker Nginx benar-benar memiliki akses melalui grup www-data. Periksa keanggotaan grup dan konfigurasi server sebelum menggunakannya.

Jika ownership seluruh aplikasi memang salah, jangan langsung menjalankan chown -R www-data:www-data tanpa pertimbangan. Pada aplikasi Laravel, misalnya, akun deployment, PHP-FPM, dan Nginx bisa memiliki tugas serta kebutuhan akses yang berbeda.

3. Pastikan seluruh direktori induk dapat diakses

Ini merupakan penyebab yang sering terlewat ketika file sudah memiliki izin baca.

Misalnya, website berada di:

/home/deployuser/sites/example.com/public/index.html

Nginx membutuhkan izin untuk melewati setiap direktori pada path tersebut. Direktori home pengguna dengan permission 700, misalnya, dapat menghalangi akses worker yang berjalan menggunakan akun berbeda.

Periksa path lengkap:

namei -l /home/deployuser/sites/example.com/public/index.html

Jika direktori home memang membatasi akses, jangan langsung membukanya untuk semua pengguna. Pertimbangkan untuk menempatkan document root pada lokasi yang sesuai untuk layanan web atau menggunakan pengaturan grup dan ACL yang terbatas.

Untuk memberikan izin akses baca dan traverse kepada user tertentu tanpa mengubah izin pengguna lain, ACL dapat menjadi pilihan.

Periksa ACL terlebih dahulu:

getfacl /home/deployuser/sites/example.com/public

Jika diagnosis menunjukkan bahwa Nginx perlu akses baca dan traverse pada direktori tertentu, kamu bisa memberikan ACL kepada user worker yang sudah terverifikasi. Contoh berikut mengasumsikan user worker adalah www-data:

sudo setfacl -m u:www-data:--x /home/deployusersudo setfacl -m u:www-data:--x /home/deployuser/sitessudo setfacl -m u:www-data:--x /home/deployuser/sites/example.comsudo setfacl -m u:www-data:--x /home/deployuser/sites/example.com/publicsudo setfacl -m u:www-data:r-- /home/deployuser/sites/example.com/public/index.html

Contoh ini memberikan izin traverse pada direktori dan izin baca pada satu file. Jika Nginx perlu menampilkan banyak file statis, ACL perlu disesuaikan untuk file dan direktori yang relevan. ACL juga tidak mengesampingkan penolakan dari SELinux atau mekanisme keamanan lainnya.

Sebelum menggunakan pendekatan ini, pastikan paket acl tersedia. Jangan menerapkan ACL secara luas ke direktori home yang berisi data pribadi atau file sensitif.

4. Periksa SELinux jika permission Linux sudah benar

Jika server menggunakan SELinux, periksa apakah ada penolakan akses pada lapisan keamanan tersebut.

Cek status SELinux:

getenforce

Jika hasilnya Enforcing, SELinux sedang menegakkan kebijakan akses. Namun, hasil ini saja tidak membuktikan bahwa SELinux menjadi penyebab error.

Pada sistem berbasis RHEL, periksa pesan penolakan keamanan:

sudo ausearch -m AVC -ts recent

Jika perintah ausearch tidak tersedia, kamu mungkin perlu memasang paket audit yang sesuai dengan distribusi Linux tersebut.

Periksa juga security context file:

ls -Z /var/www/html

Jika log audit menunjukkan penolakan yang sesuai dengan path website, periksa label yang seharusnya digunakan berdasarkan kebijakan SELinux pada sistem kamu. Untuk konten web statis pada sistem yang menggunakan kebijakan standar RHEL, tipe seperti httpd_sys_content_t lazim digunakan, tetapi konteks yang benar tetap bergantung pada lokasi file dan kebijakan yang aktif.

Jangan menonaktifkan SELinux hanya untuk menghilangkan error. Perbaiki label atau kebijakan berdasarkan bukti dari audit log. Untuk lokasi khusus, perubahan label persisten dapat diperlukan agar konfigurasi tidak hilang setelah relabel.

5. Periksa AppArmor jika server menggunakan Ubuntu

Ubuntu dapat menggunakan AppArmor untuk membatasi akses proses. Jika permission file dan direktori sudah sesuai, tetapi Nginx tetap tidak dapat mengakses resource, periksa apakah ada penolakan AppArmor yang relevan.

sudo journalctl -k --since "30 minutes ago" --no-pager

Cari pesan yang menyebut apparmor="DENIED" dan profil terkait proses Nginx. Sesuaikan rentang waktunya jika masalah terjadi lebih lama.

Jangan mengubah atau menonaktifkan profil AppArmor secara keseluruhan tanpa memastikan aturan mana yang menolak akses. Perubahan kebijakan yang terlalu luas dapat mengurangi perlindungan server.

6. Jika error berasal dari PHP-FPM, periksa akses pada sisi PHP

Tidak semua error permission pada website PHP berasal dari worker Nginx.

Jika log menunjukkan bahwa Nginx gagal mengakses socket PHP-FPM, periksa socket dan konfigurasi pool PHP-FPM. Contoh pemeriksaan:

ls -l /run/php/

Nama socket bergantung pada versi PHP dan konfigurasi server. Misalnya, www-data bisa menjadi user atau grup yang mengakses socket pada konfigurasi tertentu, tetapi kamu perlu memeriksa konfigurasi pool dan direktif listen.owner, listen.group, serta listen.mode.

Jika pesan error berasal dari PHP ketika membaca file aplikasi atau menulis cache, periksa log PHP-FPM dan aplikasi juga. Pada Laravel, direktori storage dan bootstrap/cache memiliki kebutuhan akses tulis yang berbeda dari file statis.

Jangan menjadikan seluruh direktori aplikasi dapat ditulis oleh Nginx hanya karena ada satu error dari PHP.

Cara Memverifikasi Perbaikan

Setelah mengubah permission, ownership, ACL, atau kebijakan keamanan, lakukan pemeriksaan berikut. Tidak semua perubahan file membutuhkan restart Nginx.

1. Uji respons website

Gunakan:

curl -I http://example.com/

Ganti example.com dengan domain yang sedang diperiksa.

Respons 200 OK merupakan hasil yang diharapkan jika halaman tersebut memang tersedia dan endpoint yang diuji seharusnya mengembalikan status 200. Namun, respons lain seperti 301, 302, atau 304 juga dapat normal sesuai konfigurasi website.

Jika website menggunakan HTTPS, periksa endpoint HTTPS:

curl -I https://example.com/

Jangan menggunakan hasil HTTP saja untuk menyimpulkan bahwa masalah HTTPS telah selesai.

2. Periksa log setelah permintaan baru

Jalankan:

sudo tail -n 50 /var/log/nginx/error.log

Kemudian akses kembali halaman yang sebelumnya bermasalah. Periksa apakah pesan Permission denied masih muncul untuk path yang sama.

Log lama tetap bisa berisi error sebelum perbaikan. Karena itu, cocokkan waktu pesan dengan permintaan terbaru, bukan hanya melihat apakah file log masih memuat kata tersebut.

3. Pastikan konfigurasi Nginx valid

Jika kamu juga mengubah konfigurasi virtual host, jalankan:

sudo nginx -t

Jika hasilnya menunjukkan bahwa sintaks dan pengujian konfigurasi berhasil, kamu dapat menerapkan perubahan konfigurasi menggunakan reload:

sudo systemctl reload nginx

Reload tidak diperlukan hanya untuk perubahan permission file. Jika pengujian konfigurasi gagal, jangan lanjutkan reload; perbaiki kesalahan konfigurasi terlebih dahulu.

4. Periksa status service bila ada indikasi gangguan

sudo systemctl status nginx --no-pager

Perintah ini membantu memastikan apakah service Nginx aktif. Namun, status active (running) tidak otomatis berarti seluruh halaman website dapat diakses dengan benar.

Kriteria verifikasi: endpoint memberikan respons yang sesuai, log baru tidak lagi menunjukkan penolakan akses pada resource terkait, dan fungsi website yang terdampak kembali berjalan sesuai harapan. Karena belum ada pengujian pada server tertentu, hasil tersebut harus kamu konfirmasi sendiri.

Cara Mencegah Error Permission Denied Terulang

Setelah masalah teratasi, ada beberapa kebiasaan administrasi server yang bisa membantu mencegah error serupa.

1. Periksa ownership setelah deployment. Pastikan proses deployment tidak mengubah kepemilikan atau permission file secara tidak sengaja.

2. Pisahkan izin baca dan tulis. File website yang disajikan Nginx umumnya hanya membutuhkan izin baca. Hak tulis diberikan secara terbatas kepada proses yang memang memerlukannya.

3. Simpan backup konfigurasi. Sebelum mengubah konfigurasi Nginx, simpan salinan file yang akan diedit agar perubahan bisa ditinjau atau dikembalikan.

4. Pantau log secara berkala. Perhatikan pesan Permission denied, terutama setelah memindahkan document root, memperbarui aplikasi, atau mengubah konfigurasi user dan grup.

5. Jangan menerapkan permission secara membabi buta. Perintah rekursif seperti chmod -R dan chown -R bisa mengubah hak akses file sensitif, direktori upload, atau file yang memiliki kebutuhan khusus.

6. Pertahankan kebijakan keamanan sistem. Jika SELinux atau AppArmor aktif, sesuaikan aturan berdasarkan bukti penolakan akses daripada menonaktifkan perlindungannya.

Untuk server produksi, lakukan perubahan secara terukur dan periksa dampaknya sebelum melanjutkan ke direktori atau aplikasi lain.

FAQ Seputar Nginx Permission Denied

1. Apa penyebab utama Nginx permission denied?

Penyebabnya bisa berupa permission file yang tidak sesuai, ownership yang keliru, direktori induk yang tidak dapat dilewati, atau pembatasan SELinux maupun AppArmor. Log error merupakan titik awal untuk menentukan penyebab yang perlu diperiksa.

2. Apakah chmod 777 bisa memperbaiki Nginx permission denied?

Belum tentu. chmod 777 memberikan hak baca, tulis, dan eksekusi kepada semua pengguna pada objek yang diubah. Cara ini berisiko memberikan akses berlebihan dan tidak mengatasi semua jenis penolakan, termasuk kebijakan SELinux. Gunakan izin minimum yang sesuai dengan kebutuhan aplikasi.

3. Mengapa Nginx menampilkan 403 Forbidden meskipun file sudah memiliki permission 644?

Karena Nginx juga membutuhkan izin traverse pada direktori induk. Selain itu, konfigurasi akses, document root yang salah, symlink, atau kebijakan keamanan tambahan bisa menyebabkan respons 403 meskipun file memiliki permission 644.

4. Apakah Nginx harus direstart setelah memperbaiki permission?

Biasanya tidak. Perubahan permission atau ownership file langsung berlaku tanpa restart Nginx. Reload diperlukan jika kamu mengubah konfigurasi Nginx dan ingin menerapkannya setelah memastikan konfigurasi valid.

5. Bagaimana jika Nginx tetap permission denied setelah chmod dan chown?

Periksa kembali path lengkap dengan namei -l, user worker yang sebenarnya, ACL, serta log keamanan SELinux atau AppArmor jika digunakan. Pastikan juga bahwa error berasal dari Nginx, bukan proses PHP-FPM atau aplikasi yang berjalan di belakangnya.

Penutup

Cara memperbaiki Nginx permission denied yang tepat dimulai dari membaca log, memastikan user worker, memeriksa permission dan ownership file, lalu menelusuri setiap direktori induk. Jika semuanya terlihat benar, lanjutkan dengan pemeriksaan ACL dan mekanisme keamanan tambahan.

Hindari mengubah seluruh permission website hanya untuk menghilangkan satu pesan error. Perbaikan yang baik harus menyelesaikan penolakan akses tanpa memberikan hak berlebihan kepada proses web server.

Jika masalah masih muncul, fokuskan pemeriksaan pada satu baris log error yang terbaru, terutama bagian path file dan pesan setelah failed. Informasi itu biasanya menjadi petunjuk paling berguna untuk menentukan langkah diagnosis berikutnya.