WinSCP adalah salah satu klien SFTP dan SCP yang paling populer digunakan oleh administrator sistem dan pengembang untuk mengelola file di server jarak jauh. Namun, di balik antarmukanya yang ramah pengguna, sering kali pengguna dihadapkan pada pesan error yang membingungkan, salah satunya adalah "Permission denied, Error code 3". Error ini sering muncul ketika kita mencoba mengunggah file, mengunduh file, atau mengubah direktori di server. Kesalahan ini bukan sekadar gangguan kecil; ia menghentikan alur kerja sepenuhnya dan bisa memakan waktu berjam-jam jika kita tidak tahu mustinya apa. Dalam artikel ini, kita akan membongkar pesan error ini secara mendalam, memahami akar masalahnya, dan yang terpenting, memberikan langkah-langkah perbaikan yang sistematis serta solusi permanen agar Anda tidak perlu lagi menghadapi error ini berulang kali.

Membaca pesan error ini

Ketika error ini muncul, WinSCP akan menampilkan dialog box yang cukup jelas, meskipun bagi sebagian orang kode angkanya terasa kriptik. Kutipan pesan error asli (verbatim) yang muncul di layar biasanya berbunyi seperti berikut:

Permission denied.
Error code: 3
Error message from server: Permission denied
Request code: 3

Pada beberapa variasi server atau versi WinSCP, pesan ini bisa juga dilengkapi dengan informasi tambahan seperti nama file yang gagal diakses atau tipe operasi (upload, download, atau move) yang sedang dicoba. Namun, inti dari pesan tersebut tetap sama: akses ditolak karena masalah hak akses atau kepemilikan.

Makna pesan ini dari pesan error ini dalam bahasa Indonesia adalah "Izin ditolak". Secara teknis, ini berarti bahwa akun pengguna (user) yang Anda gunakan untuk login ke server melalui WinSCP tidak memiliki hak yang cukup untuk melakukan operasi tertentu pada file atau direktori yang dituju. Error code 3 adalah kode standar dalam protokol SFTP (SSH File Transfer Protocol) yang secara spesifik merepresentasikan kondisi "Permission denied". Ini adalah respons langsung dari server jauh (remote server), bukan error yang dihasilkan oleh aplikasi WinSCP itu sendiri. WinSCP hanya bertindak sebagai pembawa pesan yang menerjemahkan kode numerik dari protokol SFTP menjadi teks yang bisa dibaca manusia.

Asal masalahnya Secara fundamental, sistem operasi berbasis Unix/Linux (yang menjadi mayoritas server tempat WinSCP terhubung) memiliki sistem keamanan berbasis file permissions dan ownership. Setiap file dan direktori memiliki tiga kategori pengguna: pemilik (owner), grup (group), dan lainnya (others). Masing-masing kategori ini memiliki tiga jenis izin: baca (read/r), tulis (write/w), dan eksekusi (execute/x). Ketika akun SSH yang Anda gunakan mencoba menulis ke sebuah direktori, sistem operasi akan memeriksa apakah akun tersebut adalah pemilik direktori, anggota grup pemilik, atau orang lain, lalu mencocokkan apakah izin tulis (w) diberikan pada kategori tersebut. Jika tidak, kernel akan menolak operasi dan server SFTP akan mengirimkan Error code 3 ke klien WinSCP.

Sebagai contoh, bayangkan Anda login dengan user deploy dan mencoba mengunggah file config.yaml ke direktori /var/www/html/. Jika direktori tersebut dimiliki oleh user root dan grup root dengan permission 755 (drwxr-xr-x), maka user deploy akan diperlakukan sebagai "others". Izin untuk "others" pada permission tersebut hanya adalah r-x (baca dan eksekusi), tanpa hak tulis (w). Saat WinSCP meminta server untuk menulis file baru, server menolak dan error inilah yang muncul.

# Contoh kondisi direktori yang memicu error
ls -ld /var/www/html/
# Output: drwxr-xr-x 3 root root 4096 May 10 12:00 /var/www/html/

# User 'deploy' mencoba menulis
touch /var/www/html/test.txt
# Output: -bash: touch: cannot touch '/var/www/html/test.txt': Permission denied

Pesan error ini adalah mekanisme pertahanan inti dari sistem operasi Linux. Tanpa adanya mekanisme penolakan izin ini, setiap pengguna di sistem bisa saja menimpa file sistem yang kritis, menyebabkan kekacauan atau celah keamanan yang fatal. Oleh karena itu, meskipun error ini menjengkelkan, keberadaannya menandakan bahwa sistem keamanan server Anda bekerja dengan baik.

Penyebab umum

Memahami pesan error hanyalah langkah pertama. Untuk memperbaikinya secara efektif, kita harus mengidentifikasi akar masalahnya. Berikut adalah lima root cause paling umum yang menyebabkan WinSCP mengeluarkan Error code 3, diurutkan dari yang paling sering dijumpai:

  1. Kurangnya Hak Tulis (Write Permission) pada Direktori Tujuan: Ini adalah penyebab paling klasik dan paling sering terjadi. Anda mencoba mengunggah (upload) file ke sebuah direktori, namun akun Anda tidak memiliki izin tulis (w) pada direktori tersebut. Tanpa izin tulis pada direktori parent, sistem tidak akan mengizinkan pembuatan file baru (inode baru) di dalamnya.

  2. Kurangnya Hak Tulis pada File yang Ingin Diubah (Overwrite/Edit): Kadang-kadang, direktori sudah memiliki izin tulis, namun file yang sudah ada di dalamnya (yang ingin Anda timpa atau ubah) memiliki permission read-only (misalnya 644 atau 444). Jika Anda bukan pemilik file tersebut, Anda tidak akan bisa mengubahnya meskipun Anda bisa membuat file baru di direktori yang sama.

  3. Ketidakcocokan Kepemilikan (Ownership) File/Direktori: Setiap file dimiliki oleh seorang user dan sebuah grup. Jika sebuah direktori dimiliki oleh root:root dan permission-nya adalah 750 (drwxr-x---), maka hanya user root dan anggota grup root yang bisa berinteraksi dengannya. User lain akan langsung mendapat permission denied, terlepas dari jenis operasi apa pun yang dicoba.

  4. Kebijakan Shell Pembatasan (Restricted Shell / Chroot Jail): Jika server menggunakan konfigurasi SSH yang membatasi pergerakan user (misalnya menggunakan ChrootDirectory dalam sshd_config), user mungkin terkunci dalam direktori tertentu. Menurut aturan chroot, direktori jail dan semua direktori induknya di dalam jalur tersebut harus dimiliki oleh root dan tidak boleh bisa ditulisi oleh user lain. Ini sering kali membatasi user untuk menulis ke akar direktori jail mereka sendiri.

  5. Atribut File Khusus (Immutable Flag): Ini lebih jarang terjadi tetapi sangat membingungkan ketika terjadi. Di sistem berbasis ext4/btrfs, administrator bisa menyetel atribut immutable pada file menggunakan perintah chattr +i. File dengan atribut ini tidak bisa dihapus, diubah, atau diganti namanya, bahkan oleh user root sekalipun (sampai atribut tersebut dihapus). Pesan error Linux-nya sama: Permission denied.

Cek penyebab yang berlaku di kasusmu:

Langkah diagnosa terbaik adalah login ke server menggunakan SSH melalui terminal (bukan WinSCP) menggunakan akun yang sama persis dengan yang Anda gunakan di WinSCP. Setelah masuk, navigasikan ke direktori tempat error terjadi. Jalankan perintah ls -la atau ls -ld untuk melihat kepemilikan dan permission secara detail.

# Masuk ke direktori target
cd /path/ke/direktori/target

# Lihat detail permission dan ownership direktori saat ini
ls -ld .
# Output mungkin: drwxr-xr-x 2 root root 4096 May 12 09:00 .

# Lihat detail file di dalamnya
ls -la
# Output mungkin:
# -r--r--r-- 1 root root    0 May 12 09:00 config.yaml
# drwxr-xr-x 2 root root 4096 May 12 09:00 subdir

Dari output di atas, kita bisa membaca bahwa direktori (.) dimiliki root dan izin untuk "others" adalah r-x (tidak ada w). Ini mengonfirmasi Penyebab #1. Jika Anda mencoba mengubah config.yaml yang permission-nya 444 (-r--r--r--), itu mengonfirmasi Penyebab #2. Untuk memeriksa Penyebab #5 (Immutable flag), Anda bisa menjalankan lsattr filename. Jika outputnya mengandung huruf i, maka file tersebut di-lock secara immutable. Dengan mendiagnosa melalui terminal, Anda menghilangkan kebingungan dan bisa langsung menargetkan perbaikan yang tepat.

Langkah perbaikan

Setelah penyebab teridentifikasi, langkah selanjutnya adalah mengeksekusi perbaikan. Penting untuk diingat bahwa sebagian besar perintah perbaikan hak akses membutuhkan hak istimewa administrator, yang berarti Anda memerlukan akses sudo atau harus login sebagai root. Berikut adalah langkah-langkah perbaikan yang disertai dengan perintah dan Contoh output.

Langkah 1: Memperbaiki Permission Direktori (Solusi untuk Penyebab #1)

Jika user Anda (misalnya webmaster) tidak bisa menulis ke direktori karena kurangnya izin tulis pada kategori "others" atau "group", Anda perlu menambahkan izin tulis tersebut. Cara paling aman adalah mengubah grup direktori menjadi grup primer user Anda, lalu memberikan izin tulis ke grup.

# Mengubah grup direktori menjadi grup milik user 'webmaster'
sudo chgrp webmaster /var/www/html/

# Memberikan izin tulis ke grup (mengubah 755 menjadi 775)
sudo chmod 775 /var/www/html/

# Verifikasi perubahan
ls -ld /var/www/html/
# Contoh output:
# drwxrwxr-x 2 root webmaster 4096 May 12 09:00 /var/www/html/

Pada output di atas, izin direktori berubah dari drwxr-xr-x menjadi drwxrwxr-x, di mana grup (webmaster) sekarang memiliki huruf w. User webmaster yang merupakan anggota grup tersebut kini bisa mengunggah file.

Langkah 2: Memperbaiki Permission File yang Ingin Ditimpa (Solusi untuk Penyebab #2)

Jika masalahnya adalah file yang sudah ada bersifat read-only, ubah permission file tersebut agar bisa ditulis (writable). Hindari menggunakan chmod 777 karena itu adalah praktik keamanan yang buruk. Gunakan izin yang paling restriktif namun cukup untuk menyelesaikan tugas.

# Mengubah permission file dari 444 menjadi 644 (Pemilik bisa baca-tulis, lainnya hanya baca)
sudo chmod 644 /var/www/html/config.yaml

# Verifikasi
ls -l /var/www/html/config.yaml
# Contoh output:
# -rw-r--r-- 1 root webmaster 0 May 12 09:00 /var/www/html/config.yaml

Sekarang, jika user root atau anggota grup (tergantung konfigurasi lebih lanjut) mencoba menimpa file ini melalui WinSCP, operasi akan berhasil.

Langkah 3: Memperbaiki Ownership secara Massal (Solusi untuk Penyebab #3)

Kadang-kadang, seluruh struktur direktori salah kepemilikan—misalnya, semua file dimiliki oleh root:root padahal aplikasi web berjalan sebagai user www-data dan Anda login menggunakan www-data melalui WinSCP. Mengganti kepemilikan satu per satu tidak efisien. Gunakan opsi -R (recursive) untuk memperbaiki seluruh direktori sekaligus. Ini adalah solusi langsung yang sangat efektif.

# Mengubah kepemilikan seluruh direktori dan isinya secara rekursif
sudo chown -R www-data:www-data /var/www/html/

# Verifikasi (ambil sampel salah satu file di dalamnya)
ls -la /var/www/html/
# Contoh output:
# drwxr-xr-x 2 www-data www-data 4096 May 12 09:00 .
# -rw-r--r-- 1 www-data www-data  512 May 12 09:00 index.html

Langkah 4: Menghapus Atribut Immutable (Solusi untuk Penyebab #5)

Jika Anda sudah menjadi root, permission terlihat benar, tapi tetap tidak bisa mengubah file, periksa atributnya.

# Cek atribut file
lsattr secure_file.conf
# Output jika immutable: ----i---------e--- secure_file.conf

# Hapus atribut immutable
sudo chattr -i secure_file.conf

# Verifikasi
lsattr secure_file.conf
# Yang akan kamu lihat: --------------e--- secure_file.conf (huruf i sudah hilang)

Memastikan perbaikan berhasil:

Setelah menjalankan perintah-perintah di atas, jangan langsung buru-buru menutup terminal. Lakukan pengujian di dalam terminal dengan menyebutkan akun Anda (bukan root). Gunakan perintah sudo -u webmaster touch /var/www/html/test_file.txt. Jika perintah ini berhasil tanpa memunculkan "Permission denied", maka perbaikan di sisi server sudah sukses. Selanjutnya, buka WinSCP dan coba lakukan operasi (upload/download/edit) yang sebelumnya gagal. Jika WinSCP tidak lagi menampilkan Error code 3, masalah telah teratasi.

Fix permanen (bukan workaround)

Mengubah permission atau ownership menggunakan chmod dan chown adalah langkah perbaikan yang bersifat reaktif. Jika aplikasi web Anda secara otomatis membuat direktori baru (misalnya, saat user mengunggah foto profil) dan konfigurasi pembuatan direktori tersebut salah, error code 3 akan kembali muncul di masa depan. Untuk mencegah error ini kembali, kita harus menerapkan fix permanen yang menyangkut konfigurasi sistem secara lebih luas.

Setelan agar tidak terulang: Set Default UMASK dan SGID

Pembuatan file dan direktori baru di Linux dikendalikan oleh nilai umask. Umask adalah masker yang menentukan bit permission mana yang dihapus saat file atau direktori baru dibuat. Umask default biasanya adalah 022, yang berarti file baru dibuat dengan permission 644 (rw-r--r--) dan direktori baru dengan 755 (rwxr-xr-x). Dengan permission ini, grup tidak memiliki hak tulis. Jika aplikasi Anda berjalan sebagai user A, dan Anda login via WinSCP sebagai user B (yang berada di grup yang sama), Anda tidak bisa mengubah file yang dibuat oleh user A.

Untuk memperbaikinya secara permanen, ubah umask default proses yang membuat file tersebut menjadi 002. Dengan umask 002, file baru akan dibuat dengan permission 664 (rw-rw-r--) dan direktori baru dengan 775 (rwxrwxr-x), yang secara otomatis memberikan hak tulis kepada grup.

Selain itu, Anda harus mengaktifkan bit SGID (Set Group ID) pada direktori parent. Ketika bit SGID diaktifkan pada sebuah direktori, setiap file atau direktori baru yang dibuat di dalamnya akan secara otomatis mewarisi kepemilikan grup dari direktori parent tersebut, bukan grup primer dari user yang membuatnya.

# 1. Set bit SGID pada direktori utama (perhatikan '2' di depan 775)
sudo chmod 2775 /var/www/html/

# 2. Ubah umask aplikasi (contoh: jika menggunakan PHP-FPM)
# Buka konfigurasi pool PHP-FPM
sudo nano /etc/php/8.1/fpm/pool.d/www.conf

# Cari direktif ;php_admin_value[umask] = , uncomment dan ubah menjadi:
php_admin_value[umask] = 0002

# Restart layanan untuk menerapkan perubahan
sudo systemctl restart php8.1-fpm

Dengan kombinasi umask 002 dan SGID, setiap file yang dibuat oleh proses server (misalnya PHP) akan bisa langsung diedit oleh Anda melalui WinSCP tanpa perlu repot-repot chmod lagi.

Cara yang disarankan: Gunakan ACL (Access Control Lists)

Terkadang, konfigurasi permission tradisional (owner-group-others) terlalu kaku. Misalnya, Anda memiliki dua user WinSCP (admin1 dan admin2) dan satu proses daemon (www-data) yang semuanya perlu akses tulis ke direktori yang sama, namun mereka tidak memiliki grup primer yang sama. Di sinilah ACL berperan. ACL memungkinkan Anda memberikan permission secara granular kepada user atau grup spesifik tanpa mengubah kepemilikan utama.

# Berikan izin baca-tulis-eksekusi untuk user www-data pada direktori
sudo setfacl -m u:www-data:rwx /var/www/html/

# Berikan juga izin yang sama untuk user admin1
sudo setfacl -m u:admin1:rwx /var/www/html/

# Terapkan secara rekursif agar berlaku untuk file di dalamnya
sudo setfacl -R -m u:admin1:rwx /var/www/html/

# Atur default ACL agar file/direktori baru juga mendapat izin yang sama
sudo setfacl -d -m u:admin1:rwx /var/www/html/

# Verifikasi ACL
getfacl /var/www/html/
# Keluaran yang tampak:
# user::rwx
# user:www-data:rwx
# user:admin1:rwx
# group::r-x
# mask::rwx
# other::r-x

Penggunaan default ACL (-d) adalah fix permanen yang sangat elegan. Anda tidak perlu lagi pusing dengan waralaba permission dan umask; sistem ACL akan memastikan aturan yang Anda tentukan selalu diterapkan pada objek baru apa pun yang lahir di direktori tersebut.

Perbedaan OS: Konsep permission dan umask di atas sangat spesifik untuk sistem operasi berbasis Linux/Unix (Ubuntu, CentOS, Debian, dll). Jika server jauh Anda menggunakan Windows (misalnya Anda terhubung ke Windows Server via WinSCP menggunakan OpenSSH untuk Windows), mekanismenya berbeda. Di Windows, "Permission denied" biasanya disebabkan oleh NTFS Permissions. File atau direktori mungkin dimiliki oleh Administrator, dan akun yang digunakan WinSCP (misalnya akun Service) tidak memiliki Write NTFS permission. Perbaikannya bukan menggunakan chmod, melainkan menggunakan GUI Windows: klik kanan pada folder -> Properties -> Security tab -> Edit -> tambahkan user dan berikan centang pada "Modify" atau "Full Control". Atau melalui PowerShell menggunakan icacls:

# Contoh di Windows Server: Memberikan hak Modify ke akun "ssh_user" pada direktori C:\inetpub\wwwroot
icacls "C:\inetpub\wwwroot" /grant "ssh_user:(M)" /T

Kalau masih belum teratasi

Meskipun langkah-langkah di atas mencakup 95% kasus penyebab Error code 3 di WinSCP, ada kalanya masalah ini tetap membandel. Jika Anda sudah mengubah permission menjadi 777 (yang sangat tidak disarankan, tapi baik untuk tes isolasi), sudah mengubah ownership ke user Anda, namun WinSCP tetap menolak akses, maka masalahnya mungkin berada pada lapisan yang lebih dalam, seperti konfigurasi subsistem SFTP itu sendiri atau kebijakan keamanan sistem operasi.

Kalau solusi di atas tidak work: Pertimbangkan kemungkinan bahwa server Anda menggunakan chroot jail yang salah konfigurasi. Dalam protokol SSH, jika direktif ChrootDirectory diatur di /etc/ssh/sshd_config untuk user Anda, maka aturan ketat berlaku: direktori chroot harus dimiliki oleh root:root dan tidak boleh bisa ditulisi oleh user lain (permission maksimal 755). Ini berarti user tidak bisa menulis langsung ke akar jail. Jika administrator server lupa membuat subdirektori di dalam jail yang bisa ditulisi (misalnya /home/user/data), maka user akan terkunci di direktori read-only. Solusinya adalah meminta administrator server untuk membuat direktori yang bisa ditulisi di dalam jail tersebut, atau menonaktifkan sementara chroot untuk mendiagnosa apakah itu penyebabnya.

Kemungkinan lain adalah adanya modul keamanan seperti AppArmor atau SELinux yang aktif. Di sistem seperti CentOS/RHEL, SELinux berjalan di atas permission Linux standar. File mungkin memiliki permission 777 dalam konteks Unix, namun jika konteks keamanan SELinux (label file) tidak sesuai dengan kebijakan daemon (misalnya, label httpd_sys_content_t untuk file web), operasi tulis akan ditolak oleh kernel. Dalam kasus ini, Anda harus memperbaiki konteks SELinux, bukan sekadar permission file.

Cara baca log: Pesan error di WinSCP terkadang tidak memberikan konteks yang cukup. Untuk mengetahui apa yang sebenarnya terjadi di sisi server, Anda harus membaca log autentikasi SSH di server jauh. Di sistem berbasis Debian/Ubuntu, log ini berada di /var/log/auth.log, sedangkan di sistem berbasis RHEL/CentOS, berada di /var/log/secure.

# Pantau log SSH secara real-time saat Anda mencoba operasi yang gagal di WinSCP
sudo tail -f /var/log/auth.log
# atau
sudo journalctl -u ssh -f

Saat Anda mencoba mengunggah file dan WinSCP menampilkan Error code 3, amati terminal log server. Anda mungkin akan melihat pesan seperti fatal: Cannot make directory '/home/user/upload': Permission denied yang mengonfirmasi masalah jalur, atau pesan terkait SELinux seperti SELinux is preventing /usr/sbin/sshd from write access on the directory. Informasi ini sangat vital karena memberi tahu persis di titik mana sistem operasi menghentikan operasi.

Di sisi klien, WinSCP juga memiliki log internal yang bisa diperiksa. Sebelum mencoba koneksi, buka halaman Session di WinSCP, klik Logging, aktifkan Enable logging, dan setel level log ke Debug 2. Setelah error muncul, buka file log tersebut. Log level debug akan menampilkan pertukaran paket SFTP mentah antara WinSCP dan server, termasuk kode respons SSH_FXP_STATUS dengan error code 3, yang mengonfirmasi bahwa penolakan memang berasal dari server, bukan bug di aplikasi WinSCP.

Bacaan resmi terkait: Jika Anda masih menemui jalan buntu, dokumentasi resmi adalah tempat terbaik untuk mencari jawaban. Pertama, kunjungi FAQ WinSCP (winscp.net/eng/docs/faq) dan cari halaman tentang "Permission denied". Penulis WinSCP (Martin Prikryl) telah mendokumentasikan banyak skenario spesifik yang berkaitan dengan perilaku WinSCP. Kedua, untuk masalah yang berkaitan dengan subsistem SFTP dan chroot, baca halaman manual sshd_config di server Anda dengan menjalankan man sshd_config dan cari bagian ChrootDirectory. Ketiga, jika Anda menduga masalahnya adalah SELinux, dokumentasi Proyek Fedora (docs.fedoraproject.org) memiliki panduan komprehensif tentang cara mengelola dan memecahkan masalah SELinux (troubleshooting_selinux). Dengan memahami interaksi antara klien WinSCP, subsistem SSH, dan kernel Linux, Anda tidak hanya memperbaiki error ini, tetapi juga meningkatkan kompetensi administrasi sistem Anda secara keseluruhan.