NFS Paylaşımı Kurulumu

İkinci bir web sunucusu eklediğiniz gün karşınıza çıkan ilk sorun neredeyse her zaman aynıdır: kullanıcı yüklemeleri yalnızca ilk makinede duruyordur ve yük dengeleyici ziyaretçiyi ikinci makineye gönderdiğinde görseller kaybolur. NFS paylaşımı kurulumu, bu sorunu uygulama kodunuza tek satır dokunmadan çözmenin en hızlı yoludur; bir sunucudaki dizini diğerlerine ağ üzerinden bağlar ve her makine o dizini yerel bir klasörmüş gibi görür.

Bu rehberde iki Linux sunucu arasında NFSv4 paylaşımını uçtan uca kuracağız: sunucu tarafında paketlerin kurulumu ve /etc/exports yapılandırması, seçeneklerin tek tek ne işe yaradığı, istemci tarafında mount ve fstab ayarları, en çok baş ağrıtan konu olan UID/GID eşleme sorunları, performans parametreleri ve güvenlik sınırları. Ayrıca NFS'in ne zaman doğru araç olmadığını da açıkça söyleyeceğim.

NFS Ne Zaman Doğru Araçtır#

NFS (Network File System), POSIX semantiğini ağ üzerinden taşır. Yani paylaşılan dizindeki bir dosyayı açabilir, ortasına yazabilir, kilitleyebilir ve izinlerini değiştirebilirsiniz; uygulamanız yerel bir dosya sisteminden farkını anlamaz. Bu, NFS'in en büyük avantajıdır: eski bir PHP uygulaması /var/www/uploads dizinine yazıyorsa, o dizini NFS paylaşımına çevirdiğinizde kodda hiçbir değişiklik yapmadan çok sunuculu mimariye geçebilirsiniz.

NFS'in doğru seçim olduğu senaryolar şunlardır: aynı yerel ağdaki birkaç uygulama sunucusunun ortak yükleme dizinini paylaşması, bir yedek sunucusunun disk alanının diğer makinelere sunulması, konteyner düğümlerinin ortak yapılandırma dosyalarına erişmesi ve geliştirme ortamlarında ortak proje dizinleri.

Doğru seçim olmadığı durumlar da en az bunlar kadar önemlidir. NFS'i internet üzerinden, farklı veri merkezleri arasında kullanmayın; protokol düşük gecikmeli bir yerel ağ varsayar ve gecikme arttıkça performans dramatik biçimde düşer. Veritabanı veri dizinini NFS üzerinde tutmayın; dosya kilitleme semantiği ve fsync davranışı beklenmedik sorunlar üretir. Milyonlarca küçük dosyanın sürekli listelendiği iş yüklerinde de NFS metadata trafiği altında ezilir. Bu senaryolarda ya blok depolama ya da nesne depolama daha uygundur; karşılaştırma için nesne depolama mı blok depolama mı yazısına bakabilirsiniz.

Sunucu Tarafı Kurulumu#

Paylaşımı sunacak makinede NFS sunucu paketini kurup servisi başlatalım. Örnekte sunucu 185.12.34.56, istemciler ise 10.0.0.0/24 özel ağında olsun.

# Debian / Ubuntu
sudo apt update
sudo apt install -y nfs-kernel-server

# RHEL / Rocky / AlmaLinux
sudo dnf install -y nfs-utils

sudo systemctl enable --now nfs-server
sudo systemctl status nfs-server --no-pager

Paylaşılacak dizini oluşturup sahipliğini ayarlayın. Burada seçtiğiniz UID/GID değerleri ilerideki izin sorunlarının kaynağı olacağı için baştan bilinçli davranın:

sudo mkdir -p /srv/paylasim/yuklemeler

# Web sunucusu kullanıcısıyla aynı sayısal UID/GID kullanın
sudo chown -R 33:33 /srv/paylasim/yuklemeler
sudo chmod 2775 /srv/paylasim/yuklemeler

chmod 2775 içindeki baştaki 2, setgid bitidir: bu dizinde oluşturulan tüm yeni dosya ve klasörler dizinin grubunu miras alır. Çok sunuculu paylaşımlarda grup tutarlılığını korumanın en kolay yolu budur.

Şimdi paylaşımı tanımlayalım:

# /etc/exports
/srv/paylasim/yuklemeler  10.0.0.0/24(rw,sync,no_subtree_check,root_squash)
/srv/paylasim/yedek       10.0.0.15(rw,sync,no_subtree_check,root_squash)
/srv/paylasim/statik      10.0.0.0/24(ro,sync,no_subtree_check,root_squash)

Dosyayı kaydettikten sonra çekirdeğe bildirin ve doğrulayın:

sudo exportfs -ra          # exports dosyasını yeniden yükle
sudo exportfs -v           # aktif paylaşımları ve seçeneklerini göster
sudo ss -tlnp | grep 2049  # NFS 2049 portunu dinliyor mu

Güvenlik duvarında yalnızca iç ağa izin verin; NFS'i doğrudan internete açmak kimlik doğrulaması zayıf bir protokolü herkese sunmak demektir:

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

exports Seçenekleri: Hangisi Ne Yapar#

/etc/exports satırındaki parantez içi seçenekler davranışı tamamen değiştirir. En çok kullanılanlar:

İki seçeneğe özellikle dikkat edin. no_root_squash kullanmak, istemci makinede root olan herkesin sunucudaki paylaşılan dosyalar üzerinde de root yetkisi kazanması demektir; bir istemci ele geçirilirse sunucu da gider. Yalnızca kontrollü yedekleme senaryolarında ve gerçekten gerekliyse kullanın.

async ise yazma performansını belirgin şekilde artırır ama sunucu, veriyi henüz diske yazmadan istemciye "tamam" der. Elektrik kesintisi ya da kernel panic durumunda istemci başarılı sandığı yazmaları kaybeder. Yedek deposu gibi yeniden üretilebilir verilerde kabul edilebilir; kullanıcı yüklemelerinde sync kalsın.

İstemci Tarafı: mount ve fstab#

İstemci makinede yalnızca NFS istemci paketini kurmanız yeterlidir:

# Debian / Ubuntu
sudo apt install -y nfs-common
# RHEL ailesi
sudo dnf install -y nfs-utils

# Sunucunun sunduğu paylaşımları listele
showmount -e 10.0.0.10

# Elle bağla ve dene
sudo mkdir -p /var/www/uploads
sudo mount -t nfs4 10.0.0.10:/srv/paylasim/yuklemeler /var/www/uploads
df -hT /var/www/uploads

Test başarılıysa kalıcı hâle getirin. Buradaki seçenekler, sunucu erişilemez olduğunda makinenizin nasıl davranacağını belirler ve seçim gerçekten önemlidir:

# /etc/fstab
10.0.0.10:/srv/paylasim/yuklemeler  /var/www/uploads  nfs4  rw,_netdev,soft,timeo=100,retrans=3,noatime,nofail  0  0

Seçenekleri açalım. _netdev ve nofail, sistemin ağ hazır olmadan bağlamaya çalışmasını ve paylaşım erişilemezse açılışta takılıp kalmasını engeller — bu ikisi olmadan NFS sunucusu kapalıyken istemci makine tek başına açılamayabilir. soft seçeneği, sunucu yanıt vermediğinde işlemin sonsuza kadar beklemek yerine hata dönmesini sağlar; hard ise veri bütünlüğü açısından daha güvenlidir ama süreçler D durumunda takılır ve kill bile edilemez. Web sunucusu gibi kullanıcıya yanıt vermesi gereken makinelerde soft genellikle daha doğru tercihtir; kritik yazma yapan sistemlerde hard,intr mantığı tercih edilir.

Yapılandırmayı test edin:

sudo systemctl daemon-reload
sudo mount -a
mount | grep nfs4

Kullanıcı ve İzin Eşleme Sorunları#

NFS'te en çok zaman kaybettiren konu budur, o yüzden mekanizmayı net anlatmak istiyorum. NFS dosya izinlerini sayısal UID ve GID üzerinden taşır, kullanıcı adı üzerinden değil. Sunucuda www-data kullanıcısının UID'si 33, istemcide ise 82 ise, sunucudaki dosyalar istemcide bambaşka bir kullanıcıya aitmiş gibi görünür ve "Permission denied" alırsınız — hâlbuki her iki makinede de kullanıcı adı aynıdır.

Çözüm için önce mevcut durumu kontrol edin:

# Her iki makinede de çalıştırın ve sayıları karşılaştırın
id www-data
# örnek çıktı: uid=33(www-data) gid=33(www-data) groups=33(www-data)

# Paylaşımdaki dosyaların sayısal sahipliğini gör
ls -ln /var/www/uploads

Sayılar farklıysa üç seçeneğiniz var:

1. UID/GID'leri elle eşitleyin. En basit ve en yaygın çözüm. İstemcide sudo usermod -u 33 www-data && sudo groupmod -g 33 www-data çalıştırıp ardından o kullanıcıya ait dosyaların sahipliğini düzeltin.
2. all_squash ile tek kimliğe indirin. /etc/exports satırına all_squash,anonuid=33,anongid=33 ekleyerek tüm istemci kullanıcılarını sunucuda tek bir kimliğe eşleyin. Paylaşımın tek bir uygulama tarafından kullanıldığı durumlarda pratiktir.
3. Merkezî kimlik kullanın. LDAP ya da benzeri bir dizin servisiyle tüm makinelerde aynı UID uzayını kullanın. Makine sayısı arttıkça tek sürdürülebilir yöntem budur.

Bir de NFSv4'e özgü klasik bir tuzak var: dosyalar nobody:nogroup görünüyorsa sorun genellikle izinlerde değil, idmapd alan adı ayarındadır. Her iki makinede /etc/idmapd.conf dosyasındaki Domain değerinin aynı olduğundan emin olun:

# /etc/idmapd.conf — hem sunucuda hem istemcide aynı olmalı
[General]
Domain = firmaniz.local

Dosya izinlerinin ve kota davranışının genel mantığı için disk kotası ve inode yazısı da faydalı bir tamamlayıcıdır.

Performans Ayarları ve Güvenlik#

NFS performansının büyük bölümü ağdan ve blok boyutlarından gelir. Varsayılan değerler çoğu durumda iyidir, ancak büyük dosya transferlerinde okuma/yazma tampon boyutlarını açıkça belirtmek fark yaratır:

# Büyük dosya transferleri için ayarlanmış istemci satırı
10.0.0.10:/srv/paylasim/yedek  /mnt/yedek  nfs4  rw,_netdev,hard,rsize=1048576,wsize=1048576,noatime,nofail  0  0

rsize ve wsize değerlerini 1 MB'a çıkarmak, sıralı okuma/yazmada sistem çağrısı sayısını azaltır. noatime ise her okumada erişim zamanı güncellemesini engelleyerek gereksiz ağ trafiğini keser. Gerçekten ne olduğunu görmek için istatistiklere bakabilirsiniz:

# İstemci tarafı NFS işlem istatistikleri
nfsstat -c

# Bağlı paylaşımların anlık gecikme ve verim değerleri
mountstats /var/www/uploads

Güvenlik tarafında dört kural yeterlidir. Birincisi, NFS'i asla internete açmayın; yalnızca özel ağ arayüzünden dinlemesini sağlayın ve güvenlik duvarında kaynak IP kısıtlaması koyun. İkincisi, root_squash seçeneğini kapatmayın. Üçüncüsü, /etc/exports içinde tek tek IP ya da dar CIDR blokları kullanın; * (herkes) yazmaktan kaçının. Dördüncüsü, gerçekten güvensiz bir ağdan geçmek zorundaysanız NFS trafiğini bir VPN tüneli içine alın, çünkü klasik NFS trafiği şifrelenmez ve içeriğiniz ağda açık gider.

Windows istemcileri de olan karma bir ortamınız varsa NFS yerine ya da yanında SMB kurmanız gerekir; bunun için Samba ile dosya paylaşımı yazısına bakın. Paylaşımlı dosya sistemi yerine ham blok cihaz sunmak istiyorsanız iSCSI daha uygun olabilir.

Sık Yapılan Hatalar ve Tuzaklar#

nofail ve _netdev yazmamak. Bu ikisi olmadan NFS sunucusu kapalıyken istemci makine açılış sırasında bağlamayı bekler ve konsola düşer. Uzak sunucuda bu, makineye erişemeyeceğiniz anlamına gelir.

exportfs -ra çalıştırmayı unutmak. /etc/exports dosyasını düzenlemek tek başına yetmez; değişiklik çekirdeğe bildirilene kadar aktif olmaz. sudo exportfs -v ile aktif durumu doğrulayın.

Paylaşımın üzerine yerel bir mount bindirmek. İstemcide /var/www/uploads dizinine NFS bağlanmışken oraya yazılan dosyalar paylaşımdadır; ancak bağlama kopmuşsa aynı yola yazılan dosyalar sessizce yerel diske gider. Sonra bağlantı geri geldiğinde bu dosyalar kaybolmuş gibi görünür. Uygulama açılışında bağlantıyı doğrulamak (mountpoint -q /var/www/uploads) iyi bir alışkanlıktır.

Veritabanını NFS üzerinde çalıştırmak. MySQL ya da PostgreSQL veri dizinini NFS'e koymak, kilit ve fsync semantiği yüzünden bozulmaya davetiye çıkarır. Veritabanı her zaman yerel blok depolamada olmalıdır.

async ile hız kazandığını sanıp veriyi riske atmak. Yedek dizinlerinde makul, kullanıcı verisinde değil. Kayıp sessiz olur; fark ettiğinizde geri dönüş yoktur.

Tek NFS sunucusunu tek nokta arıza hâline getirmek. Beş web sunucunuz olsa bile hepsi tek NFS makinesine bağlıysa, o makine düştüğünde hizmet durur. Kritik ortamlarda ya yedekli bir NFS kümesi ya da dağıtık bir dosya sistemi düşünün.

Sıkça Sorulan Sorular#

NFS mi SMB mi kullanmalıyım#

Tüm istemcileriniz Linux ise NFS daha doğal ve genellikle daha hızlıdır; POSIX izinlerini doğrudan taşır ve ek bir kimlik katmanı gerektirmez. Ortamda Windows makineler ya da masaüstü kullanıcıları varsa SMB (Samba) tercih edilir, çünkü Windows NFS'i yerleşik olarak sınırlı destekler. Karma ortamlarda aynı dizini hem NFS hem SMB ile paylaşmak mümkündür ancak izin modellerinin çakışmamasına dikkat etmelisiniz.

NFS paylaşımında "Permission denied" hatası alıyorum#

Önce sayısal kimlikleri karşılaştırın: her iki makinede id kullanici çalıştırıp UID ve GID'lerin aynı olduğunu doğrulayın, çünkü NFS kullanıcı adını değil sayıyı taşır. Ardından /etc/exports satırındaki rw seçeneğinin ve istemci IP aralığının doğru olduğunu kontrol edin. Dosyalar nobody:nogroup görünüyorsa sorun idmapd alan adı uyuşmazlığıdır; her iki makinede /etc/idmapd.conf içindeki Domain değerini eşitleyin.

NFS internet üzerinden güvenli midir#

Hayır. Klasik NFS trafiği şifrelenmez ve kimlik doğrulaması büyük ölçüde istemci IP adresine güvenir; bu, açık internette kabul edilebilir bir güvenlik modeli değildir. Farklı lokasyonlar arasında paylaşım gerekiyorsa trafiği bir VPN tüneli içine alın ya da Kerberos ile kimlik doğrulamalı NFS kullanın. Daha basit bir alternatif, bu senaryoda nesne depolamaya geçmek ve HTTPS üzerinden imzalı erişim kullanmaktır.

soft mu hard mount mu seçmeliyim#

hard seçeneğinde istemci, sunucu yanıt verene kadar bekler; veri kaybı riski yoktur ama sunucu düşerse süreçler kilitlenir ve bazen kill bile edilemez. soft seçeneğinde işlem belirli bir zaman aşımından sonra hata döner; uygulama hatayı görür ve hizmet vermeye devam edebilir ama yarım kalmış yazmalar mümkündür. Web sunucularında soft genellikle daha uygundur, kritik veri yazan sistemlerde hard tercih edilir.

Kaç sunucu aynı NFS paylaşımına bağlanabilir#

Protokol açısından pratik bir sınır yoktur; onlarca istemci aynı paylaşımı bağlayabilir. Asıl sınır sunucunun disk verimi, ağ bant genişliği ve metadata işlem kapasitesidir. Çok sayıda istemcinin aynı dizinde yoğun listeleme yapması, veri trafiğinden çok daha önce metadata darboğazı yaratır. Ölçek büyüdükçe ya paylaşımları bölmek ya da dağıtık bir dosya sistemine geçmek gerekir.

NFS performansını nasıl ölçerim#

En pratik başlangıç nfsstat -c çıktısıdır; hangi işlemlerin (getattr, read, write, lookup) ne sıklıkta yapıldığını gösterir. getattr ve lookup oranı çok yüksekse sorun veri değil metadata trafiğidir. Gerçek verim için paylaşımda dd ile büyük bir dosya yazıp okumayı deneyin ve aynı testi yerel diskte tekrarlayarak farkı görün. mountstats komutu ise işlem başına ortalama gecikmeyi verir ve ağ mı disk mi sorusunu ayırmanıza yardımcı olur.

Kapanış#

NFS, aynı yerel ağdaki Linux sunucular arasında dosya paylaşmanın en doğrudan yoludur ve uygulamanızda hiçbir değişiklik gerektirmez. Aklınızda kalması gereken pratik alışkanlıklar şunlar: root_squash seçeneğini kapatmayın, fstab satırına mutlaka _netdev ve nofail ekleyin, UID/GID uyumunu baştan kurun ve paylaşımı yalnızca özel ağdan erişilebilir yapın. Bir de bağlantının gerçekten kurulu olduğunu uygulama düzeyinde doğrulamayı alışkanlık hâline getirin; sessizce yerel diske yazmak, fark edilmesi en geç sorunlardan biridir.

Kendi ağınızda birden fazla sunucuyu yan yana çalıştıracaksanız VDS ve bulut sunucu paketlerimiz özel ağ üzerinden bu tür bir kurulum için uygundur. Kurulum, izin modeli ve izleme tarafını bize bırakmak isterseniz sunucu yönetimi hizmetimiz devreye girer; paylaşılan verinin ayrı bir kopyasını tutmak için yedekleme çözümlerimize göz atabilirsiniz.