NFS: File Sharing antar Linux

Bab 24 menyelesaikan kebutuhan file sharing lintas platform melalui Samba, cocok untuk situasi ketika Windows dan Linux harus berbagi folder yang sama. Skenario pada Bab 25 sedikit berbeda. Andaikan tim Developer sudah menambahkan server aplikasi kedua (app-02) di belakang load balancer yang kita bangun pada Bab 16, dan laporan pertama yang masuk adalah: file yang di-upload user melalui app-01 tidak muncul saat request berikutnya dilayani app-02, karena keduanya masih menyimpan file di disk lokal masing-masing. Ini adalah masalah klasik arsitektur horizontal scaling, dan solusi paling umum di lingkungan Linux murni adalah NFS (Network File System), protokol file sharing yang dirancang khusus untuk sesama Unix/Linux, tanpa beban kompatibilitas Windows seperti yang dibawa SMB/CIFS. Kita akan memahami konsep dan evolusi NFS, memasang NFS server dan client di Ubuntu Server 26.04 LTS, meng-export direktori bersama melalui /etc/exports, lalu menutup bab dengan dua cara mounting dari sisi client: mount permanen melalui /etc/fstab dan mount otomatis on-demand melalui autofs.

25.1 Konsep NFS dan Use Case-nya

Bagian ini membekali kita dengan pemahaman dasar NFS sebelum masuk ke instalasi: hal yang membuatnya berbeda dari Samba, bagaimana evolusi versinya, dan kapan protokol ini benar-benar menjadi pilihan yang tepat.

25.1.1 Apa Itu NFS dan Cara Kerjanya

NFS adalah protokol jaringan yang memungkinkan satu sistem (NFS server) membagikan sebagian direktori di disknya, lalu sistem lain (NFS client) me-mount direktori tersebut sehingga tampil dan berperilaku persis seperti direktori lokal. Protokol ini awalnya dikembangkan oleh Sun Microsystems pada tahun 1984 dan sejak saat itu menjadi standar de facto untuk file sharing di lingkungan Unix dan Linux, jauh sebelum Samba hadir menjembatani Linux dengan dunia Windows.

Perbedaan mendasar NFS dari Samba terletak pada lapisan autentikasinya. Samba mewajibkan setiap user login dengan username dan password Samba tersendiri, sedangkan NFS versi klasik (NFSv3 dan default NFSv4 tanpa Kerberos) memakai host-based trust, yaitu server hanya memeriksa dari IP address atau subnet mana request tersebut datang, lalu memercayai begitu saja UID dan GID yang dikirim oleh client. Model kepercayaan seperti ini membuat NFS jauh lebih ringan dan cepat disiapkan untuk jaringan internal yang sudah terpercaya, seperti antarserver aplikasi di belakang load balancer, tetapi juga berarti NFS tidak boleh sembarangan diekspos ke jaringan yang tidak terpercaya. Detail keamanan ini dibahas lebih dalam pada Bagian 25.3 dan 25.5.

25.1.2 Evolusi Versi: NFSv2, NFSv3, dan NFSv4

Seperti SMB pada Bab 24, NFS juga melewati beberapa generasi besar yang memengaruhi cara kita mengonfigurasinya hari ini.

Ubuntu Server 26.04 LTS, seperti rilis-rilis sebelumnya, menegosiasikan versi NFS tertinggi yang didukung bersama antara server dan client secara otomatis begitu client memakai tipe filesystem generik nfs saat mounting, sehingga dalam praktiknya NFSv4 selalu menjadi pilihan pertama tanpa perlu dipaksa melalui parameter tambahan. Kita akan tetap menuliskan versi secara eksplisit pada beberapa contoh di sepanjang bab ini agar perilakunya jelas dan mudah didiagnosis saat troubleshooting.

25.1.3 NFS vs Samba: Kapan Memilih yang Mana

Pertanyaan yang sering muncul dari Sysadmin yang baru mengenal dua teknologi ini: kalau sudah ada Samba, mengapa masih membutuhkan NFS? Jawabannya berada pada ranah audiens dan overhead. Samba wajib dipasang begitu ada client Windows atau macOS yang perlu ikut mengakses share, sedangkan NFS jauh lebih ringan dan sederhana untuk skenario Linux-ke-Linux murni, seperti storage bersama antar-node cluster, home directory terpusat untuk banyak server, atau kasus app-02 yang kita bahas pada pembuka bab ini. Tidak ada aturan baku yang melarang keduanya berjalan bersamaan pada satu server, karena setiap protokol melayani share yang berbeda, tinggal disesuaikan dengan siapa client yang akan mengaksesnya.

25.2 Instalasi NFS Server dan Client

Bagian ini memasang komponen NFS pada dua sisi: nfs-kernel-server pada server utama kita (192.168.1.10), dan nfs-common pada app-02 sebagai client yang nantinya akan me-mount direktori upload bersama.

25.2.1 Instalasi Package di Server

Langkah Praktik

1. Di server utama, perbarui daftar package, lalu pasang nfs-kernel-server. Package ini secara otomatis menarik beberapa dependency pendukung seperti rpcbind, yang masih dibutuhkan untuk kompatibilitas client NFSv3 meski fokus kita pada bab ini adalah NFSv4.

   sudo apt update
   sudo apt install -y nfs-kernel-server

2. Pastikan service utamanya aktif dan otomatis menyala saat boot.

   sudo systemctl enable --now nfs-kernel-server

Verifikasi dan Troubleshooting

• Konfirmasikan status service.

  systemctl status nfs-kernel-server --no-pager

• Periksa versi NFS yang didukung kernel server saat ini.

  cat /proc/fs/nfsd/versions

  Output semacam -2 -3 +4 +4.1 +4.2 menandakan NFSv4 beserta minor version-nya (4.1 dan 4.2) aktif, sedangkan NFSv2 dan NFSv3 (ditandai minus) nonaktif secara default.

25.2.2 Instalasi Package di Client

Langkah Praktik

1. Di app-02, pasang nfs-common, kumpulan tool client yang menyediakan dukungan mounting NFS beserta utility seperti showmount.

   sudo apt update
   sudo apt install -y nfs-common

Verifikasi dan Troubleshooting

• Uji koneksi dasar dari app-02 ke server untuk memastikan port NFS memang bisa dijangkau sebelum berlanjut ke konfigurasi export.

  nc -zv 192.168.1.10 2049

  Jika koneksi ditolak, kemungkinan besar firewall pada server belum membuka port 2049, langkah yang baru saja kita lakukan pada Bagian 25.3.3.

25.2.3 Mengenal /etc/nfs.conf

Sejak beberapa rilis nfs-utils terakhir, seluruh pengaturan operasional NFS (jumlah thread nfsd, port mountd, dan lain-lain) dipusatkan ke dalam satu file bergaya INI pada /etc/nfs.conf, ditambah drop-in directory /etc/nfs.conf.d/ untuk potongan konfigurasi tambahan tanpa perlu mengedit file utama secara langsung. Pola ini serupa dengan drop-in unit systemd yang sudah kita kenal sejak Bab 5.

Langkah Praktik

1. Lihat konfigurasi efektif yang benar-benar dipakai NFS saat ini, yang merupakan gabungan dari nilai default dan seluruh file konfigurasi yang ada.

   sudo nfsconf --dump

Verifikasi dan Troubleshooting

• Kita tidak perlu mengubah /etc/nfs.conf untuk skenario dasar pada bab ini, tetapi mengetahui keberadaan file ini penting untuk kebutuhan lanjutan seperti membatasi rentang port mountd agar mudah di-whitelist oleh firewall yang lebih ketat.

25.3 Export Directory Lewat /etc/exports

Bagian ini menyiapkan direktori /srv/nfs/uploads pada server utama sebagai lokasi penyimpanan file upload bersama, lalu meng-export-nya agar bisa diakses oleh app-02 dan server aplikasi lain yang mungkin ditambahkan oleh Developer pada masa depan.

25.3.1 Menyiapkan Direktori dan Permission

Langkah Praktik

1. Buat direktori tempat file upload disimpan, lalu serahkan kepemilikannya kepada user www-data, user yang sama yang dipakai oleh worker Nginx dan PHP-FPM sejak Bab 12 dan Bab 14.

   sudo mkdir -p /srv/nfs/uploads
   sudo chown www-data:www-data /srv/nfs/uploads

2. Terapkan permission 2775, mengikuti pola bit setgid yang sama seperti pada Bagian 24.3.1 agar file baru yang dibuat melalui proses apa pun tetap mengikuti kepemilikan group www-data.

   sudo chmod 2775 /srv/nfs/uploads

Verifikasi dan Troubleshooting

• Pastikan kepemilikan dan bit setgid sudah terpasang dengan benar.

  ls -ld /srv/nfs/uploads

25.3.2 Menulis Baris Export dan Opsi Pentingnya

Langkah Praktik

1. Buka /etc/exports, lalu tambahkan satu baris export untuk direktori upload.

   sudo nano /etc/exports

   /srv/nfs/uploads  192.168.1.0/24(rw,sync,no_subtree_check,root_squash)

   Setiap opsi di dalam tanda kurung memiliki makna penting. Opsi rw mengizinkan aktivitas tulis, bukan hanya baca. Opsi sync mewajibkan server benar-benar menuliskan perubahan ke disk sebelum membalas client dengan status sukses; opsi ini lebih lambat dibanding async tetapi jauh lebih aman terhadap risiko korupsi data saat server tiba-tiba mati. Opsi no_subtree_check mematikan pemeriksaan tambahan terhadap subdirektori di dalam filesystem yang sama; opsi ini sudah menjadi rekomendasi default nfs-utils karena pemeriksaan subtree justru sering menimbulkan masalah lain, terutama saat ada file yang sedang dibuka lalu di-rename. Opsi root_squash (nilai default meski tidak dituliskan secara eksplisit) memetakan user root pada sisi client menjadi user nobody saat menulis ke share, yang mencegah root pada satu client leluasa mengubah file milik user lain melalui NFS. Ini adalah lapisan keamanan yang sebaiknya tidak pernah dimatikan (no_root_squash) kecuali benar-benar ada kebutuhan khusus yang dipahami risikonya.
2. Perhatikan target akses 192.168.1.0/24. Kita sengaja membatasi akses ke rentang subnet internal tempat app-02 berada, bukan memakai wildcard * yang mengizinkan siapa saja. Karena NFS mengandalkan host-based trust seperti yang dijelaskan pada Bagian 25.1.1, pembatasan client pada tingkat /etc/exports ini merupakan lini pertahanan pertama sebelum firewall pada langkah berikutnya.

Verifikasi dan Troubleshooting

• Jalankan exportfs secara verbose untuk langsung menangkap kesalahan ketik. exportfs tidak punya mode "cek saja" terpisah, jadi perintah ini sekaligus menerapkan baris yang baru ditulis begitu tidak ada error, sama seperti yang akan kita lakukan resmi pada Bagian 25.3.3.

  sudo exportfs -av

  Pesan exportfs: Failed to stat /srv/nfs/uploads menandakan path yang dituliskan salah ketik atau direktorinya belum benar-benar dibuat pada Bagian 25.3.1.

25.3.3 Menerapkan Export dan Membuka Firewall

Langkah Praktik

1. Terapkan seluruh baris pada /etc/exports ke tabel export aktif milik kernel. Kombinasi flag -r (re-export, yang menyinkronkan ulang seluruh isi termasuk menghapus entry lama yang sudah tidak ada pada file) dan -a (export semua baris) merupakan kebiasaan paling aman setiap kali file /etc/exports selesai diedit.

   sudo exportfs -ra

2. Buka port firewall untuk NFSv4, dibatasi hanya untuk subnet internal yang sama seperti pada /etc/exports, bukan dibuka bebas ke seluruh jaringan.

   sudo ufw allow from 192.168.1.0/24 to any port 2049 proto tcp

   Karena kita hanya mengandalkan NFSv4 yang menggunakan satu port tunggal, kita tidak perlu membuka port tambahan seperti 111 (rpcbind) atau rentang port dinamis milik mountd yang wajib dibuka jika masih mendukung client NFSv3.

Verifikasi dan Troubleshooting

• Lihat daftar export yang sedang aktif beserta opsinya langsung dari server.

  sudo exportfs -v

• Dari app-02, konfirmasikan share memang terlihat dari sisi client sebelum benar-benar melakukan mounting.

  showmount -e 192.168.1.10

  Perintah ini tetap berfungsi walaupun kita berfokus pada NFSv4, karena rpc.mountd masih berjalan pada server untuk keperluan protokol MOUNT lama sekaligus tooling semacam showmount.
• Pesan clnt_create: RPC: Port mapper failure - Unable to receive: errno 113 (No route to host) saat menjalankan showmount hampir selalu berarti firewall pada server belum benar-benar terbuka, sehingga periksa ulang langkah sebelumnya dengan sudo ufw status numbered.

25.4 Mount NFS Share dari Client Linux

Share sudah ter-export dan bisa dijangkau. Bagian ini melakukan mounting dari app-02, lalu memastikan mount tersebut tetap ada setiap kali server di-reboot, ditutup dengan alternatif mount otomatis melalui autofs untuk skenario yang lebih dinamis.

25.4.1 Mount Manual dan Uji Baca/Tulis

Langkah Praktik

1. Buat titik mount di app-02, lalu mount share secara manual untuk pengujian awal.

   sudo mkdir -p /mnt/nfs/uploads
   sudo mount -t nfs4 192.168.1.10:/srv/nfs/uploads /mnt/nfs/uploads

2. Uji tulis file dari app-02, lalu pastikan file tersebut benar-benar tersimpan pada server.

   touch /mnt/nfs/uploads/test-dari-app02.txt
   ls -l /mnt/nfs/uploads

Verifikasi dan Troubleshooting

• Konfirmasikan mount benar-benar terpasang dan menggunakan NFSv4.

  df -hT /mnt/nfs/uploads

• Kembali ke server, pastikan file uji tadi memang muncul di /srv/nfs/uploads, yang membuktikan bahwa tulisan dari client benar-benar sampai ke storage server, bukan hanya tersimpan secara lokal di app-02.

  ls -l /srv/nfs/uploads

• Error mount.nfs4: access denied by server while mounting biasanya berarti IP app-02 berada di luar rentang subnet yang diizinkan pada Bagian 25.3.2, atau baris export belum sempat di-exportfs -ra ulang setelah diedit.

25.4.2 Mount Permanen via /etc/fstab

Langkah Praktik

1. Lepas dahulu mount manual sebelumnya agar tidak bentrok saat pengujian /etc/fstab.

   sudo umount /mnt/nfs/uploads

2. Tambahkan baris berikut ke /etc/fstab di app-02.

   192.168.1.10:/srv/nfs/uploads  /mnt/nfs/uploads  nfs4  defaults,_netdev  0  0

   Sama seperti mount CIFS pada Bagian 24.5.2, opsi _netdev memberi tahu systemd bahwa filesystem ini bergantung pada jaringan, sehingga proses mount ditunda sampai koneksi jaringan benar-benar siap saat boot.
3. Uji entry tersebut tanpa perlu melakukan reboot pada server.

   sudo mount -a
   df -hT /mnt/nfs/uploads

Verifikasi dan Troubleshooting

• Jika sudo mount -a tidak menghasilkan error tetapi mount tidak muncul di df, periksa sintaks baris /etc/fstab menggunakan findmnt --verify, yaitu perintah yang secara khusus memvalidasi isi /etc/fstab tanpa benar-benar melakukan mounting.

25.4.3 Mount On-Demand dengan autofs

Mount permanen melalui /etc/fstab cocok untuk share yang memang selalu dibutuhkan seperti /srv/nfs/uploads di app-02. Namun, bayangkan skenario lain: Developer memiliki belasan direktori proyek berbeda pada server NFS, dan setiap workstation hanya sesekali membutuhkan salah satu di antaranya. Mounting semuanya melalui /etc/fstab secara permanen menjadi boros, karena setiap mount tetap aktif dan "menempel" walaupun tidak sedang dipakai. autofs menjawab kebutuhan ini: direktori NFS baru benar-benar di-mount saat pertama kali diakses, lalu otomatis di-unmount lagi setelah periode tidak terpakai (default-nya sekitar 10 menit, bisa diatur melalui opsi timeout).

Langkah Praktik

1. Pasang package autofs di app-02.

   sudo apt install -y autofs

2. Daftarkan satu master map baru di /etc/auto.master.d/, mengarah ke titik mount /mnt/nfs/auto dan file map terpisah bernama auto.nfs. Memakai direktori auto.master.d/ lebih aman daripada mengedit /etc/auto.master secara langsung, sama seperti pola drop-in sudoers.d/ pada Bab 4.

   sudo nano /etc/auto.master.d/nfs.autofs

   /mnt/nfs/auto  /etc/auto.nfs  --timeout=60

3. Buat indirect map /etc/auto.nfs yang mendefinisikan subdirektori apa saja yang akan muncul di bawah /mnt/nfs/auto.

   sudo nano /etc/auto.nfs

   uploads  -fstype=nfs4,rw  192.168.1.10:/srv/nfs/uploads

   Baris ini berarti begitu ada proses yang mengakses /mnt/nfs/auto/uploads, autofs baru men-trigger mount NFSv4 dari 192.168.1.10:/srv/nfs/uploads secara otomatis di baliknya.
4. Restart service autofs agar membaca ulang seluruh konfigurasi map.

   sudo systemctl restart autofs

Verifikasi dan Troubleshooting

• Akses direktori tersebut, lalu segera cek apakah mount benar-benar ter-trigger.

  ls /mnt/nfs/auto/uploads
  mount | grep uploads

• Tunggu lebih dari 60 detik tanpa mengakses direktori itu lagi, lalu cek ulang dengan mount | grep uploads. Baris mount tersebut seharusnya sudah hilang, membuktikan mekanisme unmount otomatis bekerja sesuai dengan --timeout=60 yang kita tetapkan.
• Jika ls /mnt/nfs/auto/uploads menampilkan direktori kosong tanpa error tetapi mount tidak menunjukkan apa pun, periksa log autofs melalui journalctl -u autofs -n 30 untuk melihat pesan penolakan dari sisi map.

25.5 Troubleshooting dan Praktik Keamanan NFS

Bagian penutup ini merangkum dua hal yang paling sering menjadi sumber masalah NFS di lapangan: kebingungan mengenai kepemilikan file, dan kebutuhan memantau siapa saja yang sedang terhubung ke share kita.

25.5.1 Masalah UID/GID: Kenapa File Muncul Sebagai nobody:nogroup

Ini adalah jebakan paling umum yang ditemui Sysadmin baru saat pertama kali memakai NFSv4. Berbeda dari NFSv3 yang mengirim UID dan GID sebagai angka mentah, NFSv4 mengirim identitas kepemilikan file di jalur protokolnya sebagai string berformat user@domain. Proses penerjemahan angka UID lokal menjadi string ini (dan sebaliknya) disebut ID mapping, ditangani melalui program nfsidmap berdasarkan nilai Domain yang diatur di /etc/idmapd.conf. Jika nilai Domain pada server dan client tidak sama persis, proses penerjemahan ini gagal secara diam-diam, akibatnya setiap file di share yang di-mount tampil dengan kepemilikan nobody:nogroup walaupun sebenarnya UID pada kedua sisi sama persis.

Langkah Praktik

1. Samakan nilai Domain di /etc/idmapd.conf pada server maupun app-02, memakai domain internal yang sama seperti zone DNS pada Bab 9.

   sudo nano /etc/idmapd.conf

   [General]
   Domain = example.local

2. Bersihkan cache pemetaan ID yang mungkin masih menyimpan hasil terjemahan lama, lalu mount ulang share yang bermasalah.

   sudo nfsidmap -c
   sudo umount /mnt/nfs/uploads
   sudo mount -a

Verifikasi dan Troubleshooting

• Setelah mount ulang, cek ulang kepemilikan file uji dari Bagian 25.4.1.

  ls -l /mnt/nfs/uploads

  Kepemilikan seharusnya kembali menunjukkan www-data, bukan lagi nobody:nogroup.
• Catatan jujur dari lapangan: cara paling tuntas menghindari masalah ini bukan sekadar menyamakan Domain, melainkan memastikan UID dan GID user penting seperti www-data memang identik angkanya di seluruh server yang saling terhubung melalui NFS. Jika jumlah server sudah banyak, menyamakan UID/GID satu per satu menjadi tidak praktis; di sinilah identity source terpusat seperti LDAP yang disinggung pada Bab 4 mulai masuk akal untuk dipertimbangkan.

25.5.2 Memantau Koneksi dan Export Aktif

Langkah Praktik

1. Lihat statistik operasi NFS server secara umum, yang berguna untuk memastikan server benar-benar menerima traffic dari client yang diharapkan.

   nfsstat -s

2. Lihat daftar export aktif kapan pun dibutuhkan, kebiasaan cepat sebelum menambah atau mengubah baris /etc/exports.

   sudo exportfs -v

Verifikasi dan Troubleshooting

• NFS tidak menyediakan dashboard koneksi real-time sedetail smbstatus di Samba, sehingga untuk kebutuhan audit siapa saja yang sedang mounting share, cara paling praktis adalah memeriksa log koneksi pada firewall server (sudo ufw status verbose) atau memantau koneksi TCP aktif ke port 2049 secara langsung.

  sudo ss -tnp | grep :2049

Sampai di sini, server utama kita sudah berperan sebagai NFS server, meng-export /srv/nfs/uploads dengan permission dan opsi keamanan yang jelas, dan sudah diakses app-02 baik melalui mount permanen di /etc/fstab maupun mount on-demand melalui autofs. Bersama Samba pada Bab 24, Bagian VI series ini menutup kebutuhan file sharing dari dua sisi paling umum di lapangan: lintas platform dan sesama Linux. Bab 26 membuka Bagian VII dengan topik yang sama sekali berbeda, yaitu containerization melalui Docker, mulai dari konsep dasarnya sampai perintah container pertama kita.