Self-hosted dosya yöneticileri karşılaştırması

Self-hosted dosya yöneticisi nedir, ne değildir

Self-hosted dosya yöneticisi, VPS (sanal özel sunucu) üzerinde halihazırda var olan dizin ağacı için bir web arayüzüdür. Giriş yaptığınızda /srv/files dosya sistemindeki haliyle görür; dosya yükler, yeniden adlandırır, indirir veya birine bağlantı paylaşırsınız. Hiçbir veri ikinci bir sisteme kopyalanmaz; tarayıcı üzerinden bıraktığınız bir dosya, ls üzerinde bir saniye sonra görünür hale gelir.

Arama sonuçları, bu tanımı farklı işlevlere sahip yazılımlarla birbirine karıştırır. Senkronizasyon araçları, her dosyanın bir kopyasını tüm cihazlarda tutar; self-hosted Dropbox alternatifi çözümler bu amaçla kullanılır. Nesne depolama (object storage), disk üzerindeki bir dizinden ziyade bucket yapıları ve bir API etrafında kurgulanmıştır; bu nedenle S3 uyumlu nesne depolama için MinIO çalıştırmak farklı bir ihtiyaca yanıt verir. Sunucu yönetim panelleri ise dosyaları değil makineyi yönetir; bu konu Cockpit ve Webmin karşılaştırması kapsamına girer.

Bir iş arkadaşınızın sunucudaki 300 MB boyutunda bir arşive ihtiyacı olduğunda veya telefondan bir yapılandırma dosyasındaki yazım hatasını düzeltmek istediğinizde bir dosya yöneticisine ihtiyaç duyarsınız. İşin kapsamı küçüktür, araçlar da öyle.

Okurken şu gerçeği göz önünde bulundurun: Bu, dosya sisteminize okuma ve yazma erişimi olan ve bir port üzerinden dinleme yapan bir web uygulamasıdır. Aşağıdaki her seçenek, aslında ilgili sürecin diskinizin ne kadarına erişebileceğine dair bir tercihtir.

FileBrowser arşivlenmiştir, kurmadan önce bunu okuyun

FileBrowser, filebrowser/filebrowser projesi, çoğu rehberin hala önerdiği çözümdür. README dosyası artık şu uyarıyla açılmaktadır:

File Browser, 2026-09-01 tarihinde arşivlenmiştir. Planlanan son sürüm yayınlanmıştır. Bundan sonra yeni sürüm, hata düzeltmesi veya güvenlik yaması yayınlanmayacaktır.

Apache 2.0 lisanslı kod çalışmaya devam eder. Ancak güvenlik güncellemeleri durmuştur. Yazılımın temel amacı HTTP üzerinden dosya sistemine yazma erişimi sağlamak olduğundan, bu durum diğer kategorilere kıyasla burada daha kritiktir.

Bakımcılar, yazılımı kullanmaya devam etmek için yapılması gerekenleri belirtmiştir ve bu tavsiyeler hangi aracı seçerseniz seçin uygulanmalıdır: Yazılımı doğrudan internete açmayın, TLS (transport layer security) sonlandırması yapan ve kendi kimlik doğrulamasını gerçekleştiren bir reverse proxy arkasına alın, komut çalıştırma özelliğini devre dışı bırakın ve yalnızca hizmet vermek istediğiniz dizini mount ederek ayrıcalıksız bir container içerisinde çalıştırın.

README dosyasındaki bir satır diğerlerinden daha önemlidir. Oturumlar sunucu tarafındaki tanımlayıcılar yerine kendi kendine yeten JWT (JSON web token) yapısındadır, bu nedenle iptal edilemezler. Sızdırılan bir oturum anahtarı süresi dolana kadar geçerli kalır ve şifreyi değiştirmek bu anahtarı geçersiz kılmaz. FileBrowser kullanmaya devam edecekseniz, önündeki kimlik doğrulama katmanı asıl işi yapan kısımdır.

FileBrowser Quantum: aktif olarak geliştirilen çatal

Aktif geliştirme süreci, Docker Hub üzerinde gtstef/filebrowser imajı ve GitHub kayıt defterinde ghcr.io/gtsteffaniak/filebrowser olarak yayınlanan FileBrowser Quantum (gtsteffaniak/filebrowser) adlı çatala taşınmıştır. Bu sürüm, eski komut satırı bayrakları ve veritabanı ayarları karmaşası yerine yapılandırmayı tek bir config.yaml dosyası etrafında yeniden inşa eder. Belgelenen hızlı deneme komutu şöyledir:

docker run -d \
  -v $(pwd):/srv \
  -p 80:80 \
  ghcr.io/gtsteffaniak/filebrowser:stable

Bu komut, mevcut dizini http://localhost adresinde sunar. 2.0.0 sürümünden itibaren ilk giriş bilgileri artık admin / admin değildir: yapılandırmada adminPassword değerini admin dışında bir şeyle değiştirmediğiniz sürece, container rastgele bir yönetici parolası oluşturur ve bunu yalnızca bir kez günlüğe kaydeder; bu nedenle parolayı docker logs ile okuyun ve ilk girişte parola sıfırlama işlemini gerçekleştirin. Bu sıfırlama işlemini, container kendi makineniz dışında herhangi bir yerden erişilebilir hale gelmeden önce tamamlayın.

Kalıcı bir kurulum için Compose kullanın, tek bir veritabanı dosyası yerine veri dizinini mount edin ve portu localhost'a bağlayın:

services:
  filebrowser:
    image: gtstef/filebrowser:stable
    user: "1000:1000"
    volumes:
      - /srv/files:/folder
      - ./data:/home/filebrowser/data
    ports:
      - 127.0.0.1:8080:80
    restart: unless-stopped

Yapılandırma dosyası /home/filebrowser/data/config.yaml konumunda, veritabanı ise /home/filebrowser/data/database.sqlite konumunda bulunur. 2.0.0 sürümü veritabanı formatını değiştirmiş ve tek seferlik bir taşıma işlemi gerçekleştirmiştir; belgelerin dizin mount etmeyi istemesinin nedeni budur: tek bir dosya mount edildiğinde, taşıma işleminin yeni dosyayı oluşturacak bir alanı olmaz. config.yaml içindeki yollar container içi yollardır, bu nedenle yapılandırmadaki bir kaynak /srv/files değil, /folder olarak okunur. Bunu ters yapmak, dizin gerçekten orada olmadığı için hata vermeden boş bir dosya listesi üretir.

Proje, FFmpeg ve belge önizlemeleri dahil yaklaşık 60 MB boyutunda latest ve stable imajlarını, yalnızca çekirdek özelliklerin bulunduğu yaklaşık 15 MB boyutunda ise stable-slim imajını yayınlar. Bunlar, Ekim 2026 itibarıyla kurulum sayfasındaki değerlerdir. Seçtiğiniz etiketi (tag) sabitleyin. latest size haber vermeden değişir ve çalışan bir container altında yapılandırma formatını değiştiren bir dosya yöneticisi, güne kötü başlamanıza neden olur.

Bu iş için küçük araçlar arasında en güçlüsüdür. İçerme ve hariç tutma kurallarıyla birden fazla kaynağı sunabilir, böylece tek bir örnek /srv/media ve /srv/docs dizinlerini farklı kapsamlarla dışarı açabilir. Paylaşımlar bir son kullanma süresi taşır ve anonim olabilir veya belirli bir kullanıcıyla sınırlandırılabilir. Kimlik doğrulama; OIDC (OpenID Connect), LDAP (hafif dizin erişim protokolü), iki faktörlü parola ve proxy başlık modunu kapsar. Bu proxy modu, ikinci bir kullanıcı listesi tutmak yerine kendi kendine barındırılan bir Authentik sunucusu üzerinden tek oturum açma (SSO) arkasında çalışmasına olanak tanır.

Filestash: halihazırda sahip olduğunuz depolama alanı için tek bir arayüz

Filestash farklı bir yapıya sahiptir. Bir arka uca bağlanan bir ön yüzdür ve arka uç listesi oldukça uzundur: FTP, SFTP (SSH file transfer protocol), S3, SMB, WebDAV, IPFS ve yaklaşık yirmi tane daha. Dosyalar arayüzü çalıştıran kutunun üzerinde olmadığında bu çözüm uygundur.

mkdir -p /srv/filestash && cd /srv/filestash
curl -O https://downloads.filestash.app/latest/docker-compose.yml
docker compose up -d

Kullanılacak imaj machines/filestash:latest şeklindedir. http://your_domain:8334 adresini açın; ilk ekran yönetici parolasını belirlemenizi ister. Bunu hemen yapın, çünkü siz yapana kadar yönetici konsolu portu bulan herkese açık durumdadır.

Üzerine bir yapı inşa etmeden önce kimlik modelini anlayın. Varsayılan olarak Filestash, alışılagelmiş anlamda bir kullanıcı veritabanı tutmaz. Kimlik bilgileri tarayıcınızda şifrelenmiş, doğrulanmış ve yalnızca HTTP (HTTP only) çerezleri aracılığıyla saklanır. Paylaşım özelliğini kullanmadığınız sürece sunucu tarafında hiçbir şey tutulmaz; paylaşım özelliğini kullandığınızda ise Filestash, kimlik bilgilerinizin kalıcı ve şifrelenmiş bir sürümünü saklar. Bu varsayılan kurulumda "kullanıcılar" depolama hesaplarıdır: kimlik, Filestash'te değil, arka uçta, yani SFTP hesabında veya S3 anahtarında yaşar. Bu tek seçenek değildir. Açık kaynak deposunda sunulan plg_authenticate_local eklentisi, Filestash'in kullanıcı yönetimi için bir ekran ile birlikte bizzat kimlik sağlayıcı olarak hareket etmesini sağlar.

Bu tasarım temizdir ancak bir maliyeti vardır. Fiyatlandırma sayfası, ücretsiz self-hosted katmanını 3 kullanıcıya kadar AGPL v3 (GNU Affero General Public License) olarak listeler ve SSO (SAML, OIDC ve LDAP) ile rol tabanlı erişim denetimini, Ekim 2026 itibarıyla aylık 50 dolardan başlayan ücretli self-hosted katmanına dahil eder. Eğer planınız "şirket SSO'sunun önünde ücretsiz Filestash" ise, tasarımınızı yapmadan önce bu sayfayı kontrol edin.

SFTPGo: Web arayüzüne sahip bir protokol sunucusu

SFTPGo, bu listedeki en yetenekli yazılımdır ve genellikle yanlış nedenlerle tavsiye edilir. Yerel dosya sistemi, şifreli yerel dosya sistemi, S3 uyumlu nesne depolama, Google Cloud Storage, Azure Blob Storage veya başka bir SFTP sunucusu üzerinde SFTP, HTTP/S, FTP/S ve WebDAV servisleri sunar.

İkili dosyalar, Debian ve Ubuntu paketleri ve bir container imajı yayınlanmaktadır; güncel APT depo satırı ve imza anahtarı SFTPGo dokümantasyonundaki kurulum sayfasında yer alır. Container yöntemi, tag kısmını istediğiniz sürümle değiştirerek en hızlı çalıştırma yoludur:

docker run --name some-sftpgo -p 8080:8080 -p 2022:2022 -d "drakkan/sftpgo:tag"

SFTP 2022 portunu, web arayüzleri ise 8080 portunu dinler. /srv/sftpgo yolunu bir volume olarak mount etmeniz gerekir; aksi takdirde kullanıcı ana dizinleri varsayılan olarak /srv/sftpgo/data/<username> konumunda olduğundan, container yeniden oluşturulduğunda hesaplar ve dosyalar silinir.

İki farklı web arayüzü bulunur ve çoğu incelemede bu ayrım örtük bırakılır. /web/admin adresindeki WebAdmin, yönetimsel arayüzdür; kullanıcıları, grupları, sanal klasörleri ve olay kurallarını burada oluşturur; kota, bant genişliği sınırı ve erişim zamanı kısıtlamalarını burada ayarlarsınız. /web/client adresindeki WebClient ise son kullanıcı görünümüdür; kullanıcılar burada dosyaları tarar, kendi kimlik bilgilerini değiştirir, iki faktörlü kimlik doğrulamayı yapılandırır ve paylaşımlar oluşturur.

Bu paylaşımlar, karşılaştırmadaki en iyi özelliklerden biridir. Bir kullanıcı, dosya ve klasörleri paylaşmak için HTTP/S bağlantıları oluşturabilir, indirme ve yükleme sayılarını sınırlayabilir, paylaşımı parola ile koruyabilir, erişimi kaynak IP adresine göre kısıtlayabilir ve otomatik bir son kullanma tarihi belirleyebilir.

Peki neden temkinli olunmalı? Sistemin ağırlık merkezi, tarama deneyimi değil, hesap modeli ve protokol sunucusudur. SFTPGo'yu; diğer kişilerin kotalı gerçek hesaplara ihtiyaç duyduğu, yüklemelerin kontrolünüz dışındaki bir sistemden SFTP veya FTPS üzerinden geldiği ya da tek bir bucket'ın birden fazla kullanıcının ana dizininde görünmesi gerektiği durumlarda tercih edin. Sanal klasörler bu sonuncusunu gerçekleştirir: yerel disk, S3, GCS, Azure Blob, SFTP veya HTTP destekli bir klasör, birden fazla hesaba mount edilebilir ve paylaşılan klasör üzerinde kullanıcı başına ayrı bir kota uygulanabilir. Eğer tek istediğiniz /srv/files üzerinden taranabilir bir sayfa ise, bu oldukça büyük bir altyapı yükü getirecektir.

Bilmeniz gereken iki gerçek daha var. Community sürümü, ticari lisanslı Enterprise sürümünün yanı sıra ek şartlar içeren AGPL-3.0 lisansına sahiptir. OIDC ile giriş özelliği açık kaynak sürümünde mevcuttur ve kimlik sağlayıcı kullanıcılarını her iki web arayüzü için SFTPGo yönetici ve kullanıcılarına eşler. Ayrıca, httpd yapılandırmasında enable_web_client ayarını kullanarak istemci arayüzünü genel olarak kapatabilir veya kullanıcı başına HTTP değerini o kullanıcının reddedilen protokollerine ekleyerek dosya yöneticisinin herkes için değil, sadece belirli kişiler için erişilebilir olmasını sağlayabilirsiniz.

Cloud Commander: iki panel ve bir konsol, tek kullanıcı için

Cloud Commander, yerleşik bir düzenleyici ve konsol içeren, iki panel tarzında, MIT lisanslı bir Node.js yöneticisidir. Bir terminal seçeneği mevcuttur ancak varsayılan olarak devre dışıdır ve yüklü gelmez: çalışması için ayrı bir gritty paketi (npm i gritty -g) ile --terminal ve --terminal-path seçeneklerine ihtiyaç duyar. Cloud Commander'ı global olarak npm i cloudcmd -g ile yükleyin veya yayınlanmış container'ı çalıştırın:

docker run -it --rm -v ~:/root -v /:/mnt/fs -w=/root -p 8000:8000 coderaiser/cloudcmd

Çalıştırmadan önce bu komutu okuyun. -v /:/mnt/fs, tüm ana bilgisayar dosya sistemini container içine bağlar ve örnek ~/.cloudcmd.json; "root": "/", "auth": false ve "console": true ile birlikte gelir. Bu kombinasyon, 8000 numaralı porta erişen herkesin tüm diskinize ve sunucu üzerindeki bir komut konsoluna erişebileceği anlamına gelir. Bu, bir dizüstü bilgisayar için mantıklı bir varsayılan olsa da bir VPS için kötü bir tercihtir.

Kapsamı daraltın. Container, yayınlanan komutun ev dizininizi bağlayarak sağladığı /root/.cloudcmd.json dosyasını okur; bu nedenle yapılandırma bağlamasını koruyun ve geri kalanını kaldırın:

docker run -d --name cloudcmd \
  -v ~/.cloudcmd.json:/root/.cloudcmd.json \
  -v /srv/files:/srv/files \
  -w=/srv/files \
  -p 127.0.0.1:8000:8000 \
  coderaiser/cloudcmd

Bu yapılandırma dosyasında "root" değerini /srv/files olarak, "auth" değerini ise bir "username" ve "password" ile true olarak ayarlayın (dosya parolayı düz metin olarak değil, hash olarak saklar). Tarayıcı üzerinden kabuk erişimi gerçekten istemiyorsanız "console" değerini false olarak ayarlayın. "terminal" değerini false olan varsayılanında bırakın ve aynı nedenden dolayı gritty kurulumunu atlayın. --root, --auth, --username, --password ve --prefix dahil olmak üzere komut satırı karşılıkları da mevcuttur.

Aracın ne olduğu konusunda dürüst olun. Tek bir kimlik bilgisi çifti vardır; kullanıcı bazlı kapsamlandırma, kota veya paylaşım bağlantıları bulunmaz. Bu kişisel bir araçtır, bu yüzden yukarıdaki gibi localhost'a bağlayın ve bir tünel üzerinden erişin:

ssh -L 8000:127.0.0.1:8000 you@your-vps

Ardından kendi makinenizde http://127.0.0.1:8000 adresini açın. Dosya yöneticisi hiçbir zaman herkese açık hale getirilmez ve internete açık olan tek şey, zaten VPS üzerinde güvenliğini sağladığınız SSH daemon'ıdır.

Neden Nextcloud bu iş için yanlış araçtır

Nextcloud iyi bir yazılımdır ancak bu iş için tasarlanmamıştır. Bir iş birliği platformudur: bir PHP uygulaması, veritabanı, arka plan işleri, masaüstü eşitleme istemcileri ve bir uygulama mağazasından oluşur. /srv/files içeriğinin web görünümünü elde etmek için bunu çalıştırmak, küçük bir iş için çok fazla hareketli parça demektir ve temel bir uyumsuzluk söz konusudur. Nextcloud, dosya meta verilerini her istekte dizini okumak yerine bir veritabanı tablosunda tutar; bu nedenle rsync veya bir cron işi tarafından yazılan dosyalar, sudo -u www-data php occ files:scan --all ile belirtilen tarama işlemi yetişene kadar arayüzde görünmeyebilir. Bir dosya yöneticisi ise sayfayı yüklediğinizde dizini listeler, dolayısıyla bu tür bir gecikme yaşanmaz.

Nextcloud'u iyi yaptığı işler için kullanın: takvimler, kişiler, eşitleme ve masaüstü istemcisi bekleyen kişilerle paylaşım. Docker, TLS ve yedeklemeler ile VPS üzerinde Nextcloud rehberi bu kurulumu kapsar. Eğer halihazırda Nextcloud çalıştırıyorsanız ve sadece mevcut bir dizini görmeniz gerekiyorsa, External Storage uygulamasını etkinleştirin ve başka bir işlem yapmayın. Aynı diske yazma erişimi olan ikinci bir web uygulaması, yamamanız gereken ikinci bir güvenlik açığı demektir.

Tüm sunucuyu riske atmadan bir servis çalıştırma

Asla / dizinini işaret etmeyin. Süreç, kullanıcı hesabının erişebildiği her şeyi okuyabilir ve yazabilir; bu nedenle çalınan bir oturum anahtarı, doğrudan dosya sistemine aynı miktarda erişim sağlar. Yalnızca /srv/files dizinini sunun ve bu amaçla özel bir dizin oluşturun.

Servisi root olmayan bir kullanıcı ile çalıştırın ve yalnızca sunduğu dizinleri bağlayın. Compose içinde bu işlem user: "1000:1000" ve dizin başına bir bind mount ile yapılır; yazma gereksinimi olmayan her şey için :ro bayrağı kullanılır:

    volumes:
      - /srv/files:/folder
      - /srv/media:/media:ro

Bu değişikliğin tipik sonucu, tarayıcının çalışması ancak yüklemelerin permission denied hatasıyla başarısız olmasıdır; bunun nedeni, container içindeki kullanıcı kimliğinin dışarıdaki dizinin sahibi olmamasıdır. İkisini karşılaştırın: docker exec filebrowser id container kullanıcısını, ls -ln /srv/files ise ana makinedeki sayısal sahibini yazdırır. Sorunu sudo chown -R 1000:1000 /srv/files ile düzeltin. Bu, Docker imajlarında PUID ve PGID kullanımının çözmeyi amaçladığı sahiplik sorunuyla aynıdır.

Yayınlanan portu 8080:80 yerine 127.0.0.1:8080:80 adresine bağlayın. Docker, kendi netfilter kurallarını ufw kurallarının önüne yazar; bu nedenle basitçe yayınlanan bir port, ufw deny 8080 aktif olsa bile internetten erişilebilir kalır. TLS için önüne bir reverse proxy yerleştirin. Düz HTTP üzerinden oturum çerezi ağda açık metin olarak iletilir ve bu çerez, dosya sistemine erişim demektir. Compose sizin için yeniyse, VPS üzerinde Docker Compose bu kod parçacıklarının varsaydığı dosya düzenini açıklar.

Uygulamanın kendi kimlik doğrulama mekanizması zayıfsa bir katman ekleyin. Tek kullanıcılı bir örnek için proxy üzerinde HTTP basic auth yeterlidir. Birden fazla kişi dahil olduğunda, bir hesabı devre dışı bıraktığınızda her yerden erişimi kesmek için OIDC veya bir kimlik sağlayıcıya karşı forward auth kullanın.

Ekstraları kapatın. Shell, komut çalıştırıcı veya tarayıcı içi terminal sunan herhangi bir dosya yöneticisi, geçerli bir oturuma sahip olan herkese uzaktan kod yürütme imkanı sunar. FileBrowser'ın kendi kılavuzu komut çalıştırıcının devre dışı bırakılmasını önerir; Cloud Commander'ın örnek yapılandırması ise konsolu etkinleştirir. Varsayılan ayarlara göre değil, bilinçli tercihlere göre hareket edin.

İlk olarak ne bozulur ve karşılaşacağınız hatalar

listen tcp :80: bind: permission denied. Linux, 1024 altındaki portları ayrıcalıklı kabul eder: bu portlara bağlanmak için root yetkisi, CAP_NET_BIND_SERVICE yeteneği veya düşürülmüş bir net.ipv4.ip_unprivileged_port_start gerekir. FileBrowser Quantum'un belgelenmiş yapılandırması 80 numaralı portu kullanır. Bu, standart root yetkisine sahip bir Docker motoru üzerinde çalışan bir container içinde genellikle çalışır çünkü container bu yeteneğe sahiptir. Ancak ikili dosya (binary) doğrudan ana makinede ayrıcalıksız bir kullanıcı tarafından çalıştırıldığında veya rootless Docker ya da daha katı bir yetenek profili altında işlem başarısız olur. config.yaml içerisinde 1024'ün üzerinde bir port belirleyin ve 443 numaralı portun yönetimini proxy'ye bırakın.

Gezinme çalışırken yüklemeler başarısız oluyor. Bir dizini listelemek r-x gerektirir, içine yazmak ise w gerektirir. Web arayüzü genel bir hata bildirir, bu nedenle uygulama günlüklerinden önce dosya sistemini kontrol edin.

413 Request Entity Too Large. Bu hata genellikle dosya yöneticisinin kendisinden değil, dosya yöneticisinin önündeki bir bileşenden kaynaklanır. Öncelikle nginx'i kontrol edin. Varsayılan client_max_body_size değeri 1 MB'tır, bu nedenle daha büyük bir yükleme, uygulama daha görmeden proxy katmanında reddedilir. server bloğunda client_max_body_size 4096m; değerini ayarlayın veya kontrolü devre dışı bırakmak için 0 kullanın. Eğer alan adı Cloudflare üzerinden proxy ediliyorsa, bir istek bölgenin maksimum yükleme boyutunu aştığında Cloudflare aynı 413 hatasını döndürür; bu sınır Ekim 2026 itibarıyla Free ve Pro planlarında 100 MB olarak listelenmektedir. Nginx limitini artırmak bu durumda işe yaramaz, bu nedenle büyük yüklemelerin Cloudflare proxy'sinden geçmeyen bir rota üzerinden yapılması gerekir.

Yüklenen dosyalar yanlış gruba sahip. Yeni dosyalar, çevreleyen dizin ne derse desin, süreç kullanıcısı tarafından sahiplenilir; bu durum aynı dizin ağacını okuyan ikinci bir servisin çalışmasını engeller. Her iki servise de ortak bir grup atayın ve dizin üzerinde sudo chmod g+s /srv/files ile setgid bitini ayarlayın; böylece yeni dosyalar dizinin grubunu devralır.

Her şey port üzerinde çalışıyor ancak proxy arkasında bozuluyor. Bir alt yol (subpath) altında sunulan uygulama, kendisine bildirilmesi gereken bir önekten bağlantılar oluşturur. Cloud Commander bunun için --prefix seçeneğine sahiptir. Böyle bir seçeneğin bulunmadığı durumlarda, uygulamaya kendi alt alan adını (subdomain) verin ve kök yolu proxy üzerinden yönlendirin.

Hangi self-hosted dosya yöneticisini çalıştırmalısınız?

• Tek bir VPS, bir veya iki dizin, son kullanma tarihli paylaşım bağlantıları ve belki ileride SSO: FileBrowser Quantum.
• Dosyalar başka bir yerdeyse, bir S3 bucket, SFTP sunucusu veya SMB üzerinden bir NAS kullanıyorsanız ve bunların hepsini tek bir web arayüzünden görmek istiyorsanız: Ücretsiz katman sınırları dahilinde Filestash.
• Başkalarının hesaplara, kotalara ihtiyacı varsa ve SFTP veya FTPS üzerinden yükleme yapacaklarsa: Web istemcisini birincil amaç değil, kullanışlı bir ek olarak gören SFTPGo.
• SSH tüneli üzerinden erişilen, asla dış dünyaya açılmayan, düzenleyici ve konsol içeren kişisel bir araç: Cloud Commander.
• Halihazırda çalışan bir Nextcloud ve dışa açılacak mevcut bir dizin varsa: External Storage uygulaması; yeni bir yazılıma gerek yoktur.

Seçiminiz ne olursa olsun, dağıtım yöntemi seçimin kendisinden daha önemlidir. Tek bir dizin, root olmayan bir kullanıcı, localhost'a bağlı bir port ve ön tarafta kimlik doğrulama. Bu şekilde yapılandırılmış bir dosya yöneticisi bir kolaylıktır. Aynı yazılımı / dizinine yönlendirip ortak bir şifre ile kullanmak ise, güzel bir arayüze sahip bir uzak kabuk (remote shell) oluşturmaktan farksızdır.

FAQ

FileBrowser 2026 yılında hala güvenli mi?

filebrowser/filebrowser projesinin README dosyasına göre File Browser, 01.09.2026 tarihi itibarıyla arşivlenmiştir; artık yeni sürüm, hata düzeltmesi veya güvenlik yaması yayınlanmamaktadır. Kod çalışmaya devam etse de, dosya sisteminize yazma erişimi olan yamalanmamış bir yazılım zamanla artan bir risk oluşturur. Kullanmaya devam edecekseniz projenin kendi tavsiyelerine uyun: internete doğrudan açmayın, TLS ve kimlik doğrulama işlemleri için bir reverse proxy kullanın, komut çalıştırıcıyı (command runner) devre dışı bırakın ve yalnızca ilgili dizinin mount edildiği, yetkisiz (unprivileged) bir container içinde çalıştırın. Ayrıca oturumların sunucu tarafındaki tanımlayıcılar yerine kendi kendine yeten JWT'ler olduğunu, bu nedenle iptal edilemediklerini ve şifre değişikliğinin halihazırda verilmiş bir token'ı geçersiz kılmadığını unutmayın. Yeni kurulumlar için geliştirmenin devam ettiği gtstef/filebrowser imajı olarak yayınlanan FileBrowser Quantum çatalını (fork) kullanın.

Self-hosted bir dosya yöneticisi mevcut SSO sistemimi kullanabilir mi?

FileBrowser Quantum; OIDC, LDAP ve proxy header modunu destekler, bu sayede ikinci bir kullanıcı listesine gerek kalmadan mevcut bir kimlik sağlayıcının arkasında çalışabilir. SFTPGo'nun OpenID Connect entegrasyonu açık kaynak sürümünde mevcuttur ve kimlik sağlayıcı kullanıcılarını hem WebAdmin hem de WebClient arayüzleri için SFTPGo yönetici ve kullanıcılarına eşler. Filestash bu konuda dikkat edilmesi gereken bir istisnadır: Ekim 2026 itibarıyla fiyatlandırma sayfası, SSO (SAML, OIDC ve LDAP) özelliklerini aylık 50 dolardan başlayan ücretli self-hosted katmanına dahil etmiştir; ücretsiz katman ise 3 kullanıcıya kadar AGPL v3 lisansıyla sunulmaktadır. Bir uygulamanın hiç SSO desteği yoksa, yedek çözüm reverse proxy üzerinde "forward authentication" kullanmaktır; bu yöntem giriş sayfasını korur ancak uygulamanın kendi iç izinlerine dokunmaz.

Hangisi süresi dolan paylaşım bağlantıları oluşturabilir?

SFTPGo en kapsamlı uygulamaya sahiptir. Bir kullanıcı WebClient üzerinden bir HTTP/S bağlantısı oluşturabilir; indirme ve yükleme sayısını sınırlayabilir, şifre koyabilir, kaynak IP adresine göre erişimi kısıtlayabilir ve otomatik bir son kullanma tarihi belirleyebilir. FileBrowser Quantum, anonim veya kullanıcıya özel erişim seçenekleriyle, son kullanma süresi olan paylaşımları destekler; ayrıca görüntüleme, düzenleme ve yükleme için paylaşım bazlı izinler sunar. Filestash'in de bir paylaşım özelliği vardır ve bu, sunucunun depolama kimlik bilgilerinin şifreli bir kopyasını kalıcı olarak tuttuğu tek durumdur; çünkü tarayıcı oturumunuz kapandığında da bağlantının çalışması gerekir. Cloud Commander'da ise paylaşım bağlantısı özelliği bulunmamaktadır.

Tek kullanıcı ben isem, bir dosya yöneticisini / dizinine yönlendirmek güvenli mi?

Hayır, risk kendinize güvenip güvenmemenizle ilgili değildir. Süreç, kullanıcı hesabının erişebildiği her şey üzerinde okuma ve yazma yetkisine sahiptir; bu nedenle oturuma sızılması, çalınan bir çerez, yükleme işleyicisindeki yamalanmamış bir hata veya yeniden kullanılan bir şifre; /etc dizinine, SSH anahtarlarınıza ve her servisin veri dizinine erişim anlamına gelir. Bunun yerine mount işlemini tek bir dizinle sınırlayın: / yerine /srv/files. Cloud Commander bu konuda en riskli olanıdır; çünkü yayınlanan Docker komutu ana makinenin kök dizinini /mnt/fs konumuna mount eder ve örnek yapılandırması "auth": false ile "root": "/" ayarını yapar. Container localhost dışında herhangi bir yerden dinleme yapmadan önce her ikisini de değiştirin.