बेस्ट सेल्फ-होस्टेड फाइल मैनेजर: तुलना और गाइड

सेल्फ-होस्टेड फाइल मैनेजर क्या है, और क्या नहीं है

सेल्फ-होस्टेड फाइल मैनेजर आपके VPS (वर्चुअल प्राइवेट सर्वर) पर पहले से मौजूद डायरेक्टरी ट्री के ऊपर एक वेब पेज होता है। आप लॉग इन करते हैं, आपको /srv/files बिल्कुल वैसा ही दिखता है जैसा वह डिस्क पर है, और आप फाइल अपलोड, रीनेम, डाउनलोड कर सकते हैं या किसी को लिंक दे सकते हैं। किसी भी फाइल को दूसरे सिस्टम में कॉपी नहीं किया जाता है, इसलिए जो फाइल आप ब्राउज़र में डालते हैं, वह फाइल ls में एक सेकंड बाद ही दिखाई देने लगती है।

खोज परिणाम इसे उन सॉफ्टवेयर के साथ मिला देते हैं जो अन्य कार्य करते हैं। सिंक टूल हर डिवाइस पर हर फाइल की एक कॉपी रखते हैं, जिसके लिए सेल्फ-होस्टेड ड्रॉपबॉक्स विकल्प का उपयोग किया जाता है। ऑब्जेक्ट स्टोरेज में कोई डायरेक्टरी ट्री नहीं होता है, इसमें बकेट और API होते हैं, इसलिए S3 संगत ऑब्जेक्ट स्टोरेज के लिए MinIO चलाना एक अलग प्रश्न का उत्तर देता है। सर्वर एडमिन पैनल फाइलों के बजाय मशीन का प्रबंधन करते हैं, और यह कॉकपिट और वेबमिन तुलना का विषय है।

आपको फाइल मैनेजर की आवश्यकता तब होती है जब किसी सहकर्मी को सर्वर से 300 MB की आर्काइव फाइल चाहिए होती है, या जब आप फोन से किसी कॉन्फ़िगरेशन फाइल में टाइपिंग की गलती सुधारना चाहते हैं। यह काम छोटा है, और इसके टूल भी छोटे हैं।

पढ़ते समय एक तथ्य ध्यान में रखें। यह एक वेब एप्लिकेशन है जिसे आपके फाइलसिस्टम तक रीड और राइट एक्सेस प्राप्त है, और यह एक पोर्ट पर लिसन (listen) कर रहा है। नीचे दिया गया प्रत्येक विकल्प वास्तव में इस बारे में है कि वह प्रोसेस आपकी डिस्क के कितने हिस्से तक पहुँच सकती है।

FileBrowser को archive कर दिया गया है, इसलिए इसे install करने से पहले यह पढ़ें

FileBrowser, जो कि एक filebrowser/filebrowser project है, वह उत्तर है जो अधिकांश guides अभी भी देती हैं। इसके README की शुरुआत अब एक सूचना के साथ होती है:

File Browser को 2026-09-01 को archive कर दिया गया है। अंतिम नियोजित release पहले ही ship हो चुकी है। अब कोई और release, bug fix या security fix नहीं आएगा।

Apache 2.0 code काम करना जारी रखेगा। security fixes बंद हो गए हैं। इस category के लिए यह बात अधिकांश अन्य software की तुलना में अधिक महत्वपूर्ण है, क्योंकि इस software का पूरा उद्देश्य ही HTTP के माध्यम से filesystem तक write access प्रदान करना है।

Maintainers ने इसे चलाते रहने का तरीका लिखा है, और आप जो भी tool चुनें, यह सलाह मानने योग्य है: इसे सीधे internet पर expose न करें, इसे एक ऐसे reverse proxy के पीछे रखें जो TLS (transport layer security) को terminate करता हो और अपनी authentication करता हो, command runner को disabled रखें, और इसे एक container में unprivileged रूप से चलाएं जिसमें केवल वही directory mounted हो जिसे आप serve करना चाहते हैं।

उस README की एक पंक्ति बाकी सभी से अधिक महत्वपूर्ण है। Sessions server-side identifiers के बजाय self-contained JWTs (JSON web tokens) हैं, इसलिए उन्हें revoke नहीं किया जा सकता। एक बार leak हुआ session token तब तक valid रहता है जब तक वह expire न हो जाए, और password बदलने से वह invalid नहीं होता। यदि आप FileBrowser का उपयोग जारी रखते हैं, तो इसके सामने मौजूद authentication layer ही वास्तविक सुरक्षा का काम कर रही है।

FileBrowser Quantum: वह fork जो अभी भी सक्रिय है

सक्रिय विकास अब एक fork, FileBrowser Quantum (gtsteffaniak/filebrowser) पर स्थानांतरित हो गया है, जिसे gtstef/filebrowser image के रूप में प्रकाशित किया गया है। यह पुराने command line flags और database settings के मिश्रण के बजाय एक एकल config.yaml के इर्द-गिर्द configuration को फिर से बनाता है। दस्तावेज़ों में दिया गया त्वरित परीक्षण:

docker run -d \
  -v $(pwd):/srv \
  -p 80:80 \
  gtstef/filebrowser:beta

यह वर्तमान directory को http://localhost पर serve करता है, और पहला login admin / admin है। इसे तब बदलें जब container आपके अपने machine के अलावा कहीं और से पहुँच योग्य न हो।

एक स्थायी instance के लिए, Compose का उपयोग करें, एक एकल database file के बजाय data directory को mount करें, और port को localhost पर bind करें:

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

Config /home/filebrowser/data/config.yaml पर और database /home/filebrowser/data/filebrowser.sqlite पर स्थित होता है। Version 2.0.0 ने database format को बदल दिया है और एक बार का migration करता है, इसीलिए दस्तावेज़ directory mount करने के लिए कहते हैं: एक एकल file mount करने पर migration के पास नई file रखने के लिए जगह नहीं होती। config.yaml के अंदर के paths container paths हैं, इसलिए config में source /folder पढ़ा जाता है, न कि /srv/files। इसे उल्टा करने पर बिना किसी error के एक खाली file list मिलती है, क्योंकि वह directory वास्तव में वहाँ मौजूद नहीं होती।

यह project लगभग 60 MB पर latest और stable प्रकाशित करता है जिसमें video thumbnails के लिए FFmpeg शामिल है, और लगभग 15 MB पर stable-slim जिसमें केवल core शामिल है। अगस्त 2026 में install page पर ये आँकड़े दिए गए थे। अपने चुने हुए tag को pin करें। latest बिना बताए बदल जाता है, और एक file manager जो चलते हुए container के तहत अपना config format बदल दे, वह एक खराब सुबह का कारण बन सकता है।

इस कार्य के लिए यह छोटे tools में सबसे मजबूत है। यह include और exclude नियमों के साथ कई sources को serve करता है, इसलिए एक ही instance अलग-अलग scope के साथ /srv/media और /srv/docs को expose कर सकता है। Shares में expiration time होता है और वे anonymous हो सकते हैं या किसी user तक सीमित हो सकते हैं। Authentication में OIDC (OpenID Connect), LDAP (lightweight directory access protocol), two-factor के साथ password, और एक proxy header mode शामिल है। यह proxy mode ही है जो इसे एक self-hosted Authentik server से single sign on (SSO) के पीछे बैठने देता है, बजाय इसके कि users की दूसरी सूची रखी जाए।

Filestash: आपके मौजूदा स्टोरेज के लिए एक इंटरफ़ेस

Filestash एक अलग तरह का टूल है। यह एक फ्रंट-एंड है जो बैकएंड से जुड़ता है, और बैकएंड की सूची काफी लंबी है: FTP, SFTP (SSH file transfer protocol), S3, SMB, WebDAV, IPFS और लगभग बीस अन्य। यह तब उपयोगी होता है जब फाइलें उस बॉक्स पर नहीं होतीं जहाँ इंटरफ़ेस चल रहा है।

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

इसका इमेज machines/filestash:latest है। http://your_domain:8334 खोलें और पहली स्क्रीन पर एडमिन पासवर्ड सेट करें। इसे तुरंत सेट करें, क्योंकि जब तक आप ऐसा नहीं करते, एडमिन कंसोल उस व्यक्ति के लिए खुला रहता है जो पोर्ट तक पहुँच सकता है।

इस पर काम शुरू करने से पहले इसके आइडेंटिटी मॉडल को समझें। Filestash सामान्य अर्थों में यूजर डेटाबेस नहीं रखता है। क्रेडेंशियल्स आपके ब्राउज़र में कुकीज़ के माध्यम से स्टोर किए जाते हैं जो एन्क्रिप्टेड, ऑथेंटिकेटेड और HTTP-only होते हैं। सर्वर साइड पर कुछ भी नहीं रखा जाता है, सिवाय तब जब आप शेयर फीचर का उपयोग करते हैं; उस स्थिति में Filestash आपके क्रेडेंशियल्स का एक स्थायी एन्क्रिप्टेड संस्करण रखता है। यहाँ "यूजर्स" का अर्थ स्टोरेज अकाउंट्स है: आइडेंटिटी बैकएंड में रहती है, जैसे SFTP अकाउंट या S3 की (key) में, न कि Filestash में।

यह डिज़ाइन साफ-सुथरा है, लेकिन इसकी एक कीमत है। प्राइसिंग पेज पर फ्री सेल्फ-होस्टेड टियर को AGPL v3 (GNU Affero General Public License) के तहत 3 यूजर्स तक के लिए सूचीबद्ध किया गया है। इसमें SSO (SAML, OIDC और LDAP) के साथ रोल-बेस्ड एक्सेस कंट्रोल को अगस्त 2026 तक $50 प्रति माह वाले पेड सेल्फ-होस्टेड टियर में रखा गया है। यदि आपकी योजना "कंपनी SSO के सामने Filestash को मुफ्त में उपयोग करने" की थी, तो इसके लिए डिज़ाइन बनाने से पहले उस पेज को जरूर देख लें।

SFTPGo: एक protocol server जिसमें web interface भी है

SFTPGo इस सूची का सबसे सक्षम software है, और इसे अक्सर गलत कारणों से सुझाया जाता है। यह local filesystem, encrypted local filesystem, S3 compatible object storage, Google Cloud Storage, Azure Blob Storage, या किसी अन्य SFTP server के माध्यम से SFTP, HTTP/S, FTP/S और WebDAV की सुविधा देता है।

इसके binaries, Debian और Ubuntu packages तथा container image उपलब्ध हैं। वर्तमान APT repository line और उसकी signing key SFTPGo documentation के installation page पर दी गई है। इसे चलाने का सबसे तेज़ तरीका container का उपयोग करना है, जहाँ tag को आप अपने इच्छित version से बदल सकते हैं:

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

SFTP 2022 port पर और web interfaces 8080 port पर listen करते हैं। /srv/sftpgo को volume के रूप में mount करें, अन्यथा container के recreate होने पर accounts और उनकी files मिट जाएंगी, क्योंकि user home directories डिफ़ॉल्ट रूप से /srv/sftpgo/data/<username> पर होती हैं।

इसमें दो web interfaces हैं, और इनके बीच का अंतर वह हिस्सा है जिसे अधिकांश लेख स्पष्ट नहीं करते। WebAdmin, जो /web/admin पर उपलब्ध है, प्रशासनिक कार्यों के लिए है: यहाँ आप users, groups, virtual folders और event rules बनाते हैं, तथा quotas, bandwidth limits और access time restrictions सेट करते हैं। WebClient, जो /web/client पर है, end-user view है, जहाँ कोई व्यक्ति files browse कर सकता है, अपने credentials बदल सकता है, two-factor authentication सेट कर सकता है और shares बना सकता है।

ये shares इस तुलना में सबसे बेहतरीन हैं। एक user files और folders को share करने के लिए HTTP/S links बना सकता है, downloads और uploads की संख्या सीमित कर सकता है, share को password से सुरक्षित कर सकता है, source IP address द्वारा access सीमित कर सकता है, और automatic expiration date सेट कर सकता है।

तो सावधानी क्यों बरतें? इसका मुख्य केंद्र account model और protocol server है, न कि browsing अनुभव। SFTPGo को तब चुनें जब अन्य लोगों को quotas के साथ वास्तविक accounts की आवश्यकता हो, जब uploads किसी ऐसे system से SFTP या FTPS के माध्यम से आ रहे हों जिसे आप नियंत्रित नहीं करते, या जब एक ही bucket को कई users की home directories में दिखाना हो। Virtual folders अंतिम कार्य को पूरा करते हैं: एक folder जो local disk, S3, GCS, Azure Blob, SFTP या HTTP द्वारा समर्थित हो, उसे कई accounts में mount किया जा सकता है, जिसमें shared folder पर प्रति user अलग quota होता है। यदि आप केवल /srv/files पर एक browsable page चाहते हैं, तो यह उसके लिए बहुत बड़ा तंत्र है।

दो और तथ्य जो जानना उपयोगी हैं। Community edition केवल AGPL-3.0 और अतिरिक्त शर्तों के साथ आता है, जबकि एक व्यावसायिक रूप से licensed Enterprise edition भी उपलब्ध है। OIDC login open source build में शामिल है, और यह identity provider के users को दोनों web interfaces के लिए SFTPGo admins और users के रूप में map करता है। आप httpd configuration में enable_web_client का उपयोग करके client interface को globally बंद कर सकते हैं, या उस user के denied protocols में HTTP जोड़कर इसे प्रति-user आधार पर बंद कर सकते हैं, ताकि file manager किसी एक व्यक्ति के लिए मौजूद रहे और सभी के लिए नहीं।

Cloud Commander: दो पेन और एक टर्मिनल, एक व्यक्ति के लिए

Cloud Commander एक MIT लाइसेंस प्राप्त Node.js मैनेजर है जो दो-पेन (two-pane) शैली में आता है, जिसमें एक इन-बिल्ट एडिटर, कंसोल और टर्मिनल शामिल है। इसे npm i cloudcmd -g के साथ ग्लोबली इंस्टॉल करें, या पब्लिश किए गए कंटेनर को चलाएं:

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

इसे चलाने से पहले उस कमांड को ध्यान से पढ़ें। -v /:/mnt/fs पूरे होस्ट फाइलसिस्टम को कंटेनर में माउंट करता है, और सैंपल ~/.cloudcmd.json में "root": "/", "auth": false और "console": true शामिल होते हैं। इस संयोजन का मतलब है कि जो कोई भी पोर्ट 8000 तक पहुंचता है, उसे आपकी पूरी डिस्क और सर्वर पर कमांड कंसोल का एक्सेस मिल जाता है। यह लैपटॉप के लिए एक उचित डिफॉल्ट है, लेकिन VPS के लिए यह असुरक्षित है।

इसके स्कोप को सीमित करें। कंटेनर /root/.cloudcmd.json को पढ़ता है, जिसे पब्लिश की गई कमांड आपके होम डायरेक्टरी को माउंट करके प्रदान करती है, इसलिए कॉन्फ़िगरेशन माउंट को रखें और बाकी को हटा दें:

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

उस कॉन्फ़िगरेशन फाइल में "root" को /srv/files पर सेट करें, "auth" को "username" और "password" के साथ true पर सेट करें, और "console" तथा "terminal" को false पर सेट करें, जब तक कि आपको वास्तव में ब्राउज़र शेल एक्सेस की आवश्यकता न हो। कमांड लाइन विकल्प भी मौजूद हैं, जिनमें --root, --auth, --username, --password और --prefix शामिल हैं।

यह क्या है, इसके बारे में स्पष्ट रहें। इसमें केवल एक क्रेडेंशियल पेयर है, कोई प्रति-उपयोगकर्ता स्कोपिंग नहीं, कोई कोटा नहीं, और कोई शेयर लिंक नहीं है। यह एक व्यक्तिगत टूल है, इसलिए इसे ऊपर बताए अनुसार localhost पर बाइंड करें और एक टनल के माध्यम से एक्सेस करें:

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

फिर अपनी मशीन पर http://127.0.0.1:8000 खोलें। फाइल मैनेजर कभी भी सार्वजनिक रूप से एक्सपोज नहीं होता है, और इंटरनेट के सामने केवल वही SSH डेमन होता है जिसे आपने पहले ही अपने VPS पर सुरक्षित (harden) कर लिया है।

इस विशिष्ट कार्य के लिए Nextcloud गलत टूल क्यों है

Nextcloud एक अच्छा सॉफ्टवेयर है, लेकिन यह इस कार्य के लिए नहीं है। यह एक कोलैबोरेशन प्लेटफॉर्म है: इसमें एक PHP एप्लिकेशन, एक डेटाबेस, बैकग्राउंड जॉब्स, डेस्कटॉप सिंक क्लाइंट्स और एक ऐप स्टोर शामिल है। /srv/files का वेब व्यू प्राप्त करने के लिए इसे चलाना एक छोटे से काम के लिए बहुत अधिक जटिलता पैदा करता है, और यहाँ एक स्पष्ट बेमेल स्थिति है। Nextcloud फाइल मेटाडेटा को डेटाबेस टेबल में रखता है, न कि प्रत्येक रिक्वेस्ट पर डायरेक्टरी को पढ़ता है। इसलिए, rsync या cron job द्वारा लिखी गई फाइलें इंटरफेस में तब तक नहीं दिखतीं जब तक कि स्कैन पूरा न हो जाए, जिसके लिए sudo -u www-data php occ files:scan --all की आवश्यकता होती है। एक फाइल मैनेजर पेज लोड होने पर डायरेक्टरी को लिस्ट करता है, इसलिए वहां ऐसा कोई अंतराल नहीं होता।

Nextcloud का उपयोग उसी के लिए करें जिसमें वह बेहतर है: कैलेंडर, कॉन्टैक्ट्स, सिंक और उन लोगों के साथ शेयरिंग जो डेस्कटॉप क्लाइंट की अपेक्षा रखते हैं। Docker, TLS और बैकअप के साथ VPS पर Nextcloud उस सेटअप को कवर करता है। यदि आप इसे पहले से चला रहे हैं और केवल एक मौजूदा डायरेक्टरी को देखना चाहते हैं, तो External Storage ऐप को इनेबल करें और वहीं रुक जाएं। उसी डिस्क पर राइट एक्सेस वाला दूसरा वेब एप्लिकेशन पैच करने के लिए एक अतिरिक्त चीज है।

पूरे सर्वर का एक्सेस दिए बिना इसे कैसे चलाएं

इसे कभी भी / पर पॉइंट न करें। यह प्रक्रिया उन सभी फाइलों को पढ़ और लिख सकती है जिन तक इसके यूजर अकाउंट की पहुंच है, इसलिए एक चोरी हुआ सेशन टोकन सीधे तौर पर उतने ही फाइलसिस्टम एक्सेस के बराबर होता है। केवल एक डायरेक्टरी, /srv/files, को सर्व करें और इसे विशेष रूप से इसी उद्देश्य के लिए बनाएं।

इसे एक non-root यूजर के रूप में चलाएं और केवल वही माउंट करें जिसे यह सर्व करता है। Compose में यह user: "1000:1000" है, साथ ही प्रत्येक डायरेक्टरी के लिए एक bind mount है, और उन चीजों पर :ro का उपयोग करें जिन्हें इसे कभी लिखने की आवश्यकता नहीं है:

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

इस बदलाव का सामान्य परिणाम यह होता है कि ब्राउजिंग तो काम करती है लेकिन अपलोड permission denied के साथ विफल हो जाते हैं, क्योंकि कंटेनर के अंदर का यूजर आईडी बाहर की डायरेक्टरी का मालिक नहीं होता है। दोनों की तुलना करें: docker exec filebrowser id कंटेनर यूजर को प्रिंट करता है, ls -ln /srv/files होस्ट पर न्यूमेरिक ओनर को प्रिंट करता है। इसे sudo chown -R 1000:1000 /srv/files के साथ ठीक करें। यह वही ओनेरशिप की समस्या है जिसे हल करने के लिए Docker images में PUID और PGID मौजूद हैं।

पब्लिश किए गए पोर्ट को 8080:80 के बजाय localhost, 127.0.0.1:8080:80 पर बाइंड करें। Docker अपने स्वयं के netfilter रूल्स को ufw से पहले लिखता है, इसलिए एक साधारण पब्लिश किया गया पोर्ट तब भी इंटरनेट से एक्सेस किया जा सकता है जब ufw deny 8080 सक्रिय हो। TLS के लिए सामने एक reverse proxy लगाएं। सादे HTTP पर सेशन कुकी नेटवर्क में स्पष्ट रूप से जाती है, और वह कुकी फाइलसिस्टम एक्सेस के समान है। यदि Compose आपके लिए नया है, तो VPS पर Docker Compose उन फाइल लेआउट को कवर करता है जिन्हें ये स्निपेट्स मानते हैं।

जब एप्लिकेशन का अपना ऑथेंटिकेशन लेयर कमजोर हो, तो एक अतिरिक्त लेयर जोड़ें। सिंगल यूजर इंस्टेंस के लिए प्रॉक्सी पर HTTP basic auth पर्याप्त है। एक बार जब एक से अधिक लोग शामिल हो जाते हैं, तो OIDC या identity provider के खिलाफ forward auth का उपयोग करें ताकि एक अकाउंट को रद्द करने से हर जगह एक्सेस रद्द हो जाए।

अतिरिक्त सुविधाओं को बंद कर दें। कोई भी फाइल मैनेजर जो शेल, कमांड रनर या इन-ब्राउजर टर्मिनल प्रदान करता है, वह वैध सेशन रखने वाले किसी भी व्यक्ति को रिमोट कोड एक्जीक्यूशन की सुविधा दे रहा है। FileBrowser का अपना मार्गदर्शन कमांड रनर को डिसेबल रखने का है, और Cloud Commander का सैंपल कॉन्फ़िगरेशन कंसोल को इनेबल करता है। डिफ़ॉल्ट के बजाय उद्देश्य के आधार पर निर्णय लें।

सबसे पहले क्या खराब होता है, और आपको कौन सी त्रुटियाँ दिखाई देंगी

listen tcp :80: bind: permission denied. Linux 1024 से नीचे के ports को privileged processes के लिए आरक्षित रखता है। FileBrowser Quantum की प्रलेखित config port 80 का उपयोग करती है, जो container के अंदर तो ठीक है, लेकिन host पर unprivileged user के रूप में binary चलाने पर तुरंत विफल हो जाती है। config.yaml में 1024 से ऊपर का port सेट करें और proxy को 443 संभालने दें।

ब्राउज़िंग काम करती है लेकिन अपलोड विफल हो जाते हैं। किसी directory को सूचीबद्ध करने के लिए r-x की आवश्यकता होती है, और उसमें लिखने के लिए w की। वेब इंटरफ़ेस एक सामान्य त्रुटि दिखाता है, इसलिए एप्लिकेशन लॉग के बजाय पहले filesystem की जाँच करें।

413 Request Entity Too Large. यह त्रुटि nginx से आती है, file manager से नहीं। डिफ़ॉल्ट client_max_body_size 1 MB है, इसलिए एप्लिकेशन के पास पहुँचने से पहले ही proxy पर बड़ा अपलोड अस्वीकार कर दिया जाता है। server ब्लॉक में client_max_body_size 4096m; सेट करें, या जाँच को अक्षम करने के लिए 0 का उपयोग करें।

अपलोड की गई फ़ाइलों का group गलत होता है। नई फ़ाइलें process user के स्वामित्व में होती हैं, चाहे आसपास की directory कुछ भी कहे, जो उसी tree को पढ़ने वाली दूसरी service को बाधित करता है। दोनों services को एक साझा group दें और directory पर sudo chmod g+s /srv/files के साथ setgid bit सेट करें, ताकि नई फ़ाइलें directory के group को विरासत में प्राप्त कर सकें।

सब कुछ port पर काम करता है लेकिन proxy के पीछे विफल हो जाता है। subpath के अंतर्गत परोसी जाने वाली एप्लिकेशन उन links को बनाती है जिनके prefix के बारे में उसे बताया जाना चाहिए। Cloud Commander में इसके लिए --prefix है। जहाँ ऐसा कोई विकल्प मौजूद नहीं है, वहाँ एप्लिकेशन को अपना subdomain दें और root path को proxy करें।

आपको कौन सा self-hosted file manager चलाना चाहिए?

• एक VPS, एक या दो directories, expiry के साथ share links, और शायद बाद में SSO: FileBrowser Quantum।
• ऐसी files जो कहीं और स्थित हैं, जैसे S3 bucket, SFTP host या SMB पर NAS, और आप उन सभी के लिए एक ही web view चाहते हैं: Filestash, free tier की सीमाओं के भीतर।
• अन्य लोगों को accounts, quotas, और SFTP या FTPS के माध्यम से uploads की आवश्यकता है: SFTPGo, जिसमें web client को मुख्य कारण के बजाय एक उपयोगी अतिरिक्त सुविधा के रूप में देखा जाता है।
• एक व्यक्तिगत tool जिसमें editor और terminal हो, जिसे SSH tunnel के माध्यम से एक्सेस किया जाता हो और कभी public न किया गया हो: Cloud Commander।
• यदि Nextcloud पहले से चल रहा है और कोई मौजूदा directory expose करनी है: External Storage app का उपयोग करें, किसी नए software की आवश्यकता नहीं है।

आप जो भी चुनें, deployment का तरीका चुनाव से अधिक महत्वपूर्ण है। एक directory, एक non-root user, localhost से bind port, और सामने authentication। इस तरह set up किया गया file manager एक सुविधा है। यदि उसी software को / पर point किया जाए और एक साझा password का उपयोग किया जाए, तो यह एक अच्छे interface वाला remote shell बन जाता है।

FAQ

क्या 2026 में FileBrowser चलाना अभी भी सुरक्षित है?

अपस्ट्रीम filebrowser/filebrowser README बताता है कि File Browser को 2026-09-01 को आर्काइव कर दिया गया है, और अब इसमें कोई नया release, bug fix या security fix नहीं आएगा। कोड अभी भी चलता है, लेकिन आपके filesystem तक write access रखने वाला unpatched software समय के साथ बढ़ता हुआ जोखिम है। यदि आप इसे जारी रखना चाहते हैं, तो प्रोजेक्ट की अपनी सलाह का पालन करें: इसे सीधे इंटरनेट पर expose न करें, TLS और authentication के लिए reverse proxy का उपयोग करें, command runner को disabled रखें, और केवल आवश्यक directory को mount करके एक unprivileged container में चलाएं। यह भी ध्यान रखें कि इसके sessions server-side identifiers के बजाय self-contained JWTs होते हैं, इसलिए उन्हें revoke नहीं किया जा सकता, और पासवर्ड बदलने से जारी किया गया token अमान्य नहीं होता। नए इंस्टॉलेशन के लिए, FileBrowser Quantum fork का उपयोग करें, जो gtstef/filebrowser image के रूप में उपलब्ध है, जहाँ विकास जारी है।

क्या कोई self-hosted file manager मेरे मौजूदा SSO का उपयोग कर सकता है?

FileBrowser Quantum OIDC, LDAP और proxy header mode को सपोर्ट करता है, इसलिए यह बिना किसी दूसरी user list के मौजूदा identity provider के पीछे काम कर सकता है। SFTPGo का OpenID Connect integration open source build में उपलब्ध है और यह identity provider के users को WebAdmin और WebClient interfaces के लिए SFTPGo admins और users के साथ map करता है। Filestash इस मामले में अलग है: इसके pricing page के अनुसार, अगस्त 2026 तक SSO (SAML, OIDC और LDAP) इसके $50 प्रति माह वाले paid self-hosted tier में आता है, जबकि free tier AGPL v3 के तहत 3 users तक सीमित है। जब किसी application में SSO सपोर्ट न हो, तो reverse proxy पर forward authentication का उपयोग करें, जो login page को सुरक्षित करता है लेकिन application की internal permissions को प्रभावित नहीं करता।

इनमें से कौन share links को expire करने की सुविधा देता है?

SFTPGo का implementation सबसे पूर्ण है। एक user WebClient से HTTP/S link बना सकता है और downloads/uploads की संख्या सीमित कर सकता है, पासवर्ड सेट कर सकता है, source IP address द्वारा access प्रतिबंधित कर सकता है, और automatic expiration date निर्धारित कर सकता है। FileBrowser Quantum expiration time के साथ shares को सपोर्ट करता है, जिसमें access anonymous हो सकता है या किसी user तक सीमित, साथ ही viewing, editing और uploading के लिए per-share permissions भी उपलब्ध हैं। Filestash में भी share feature है, और यह एकमात्र ऐसा मामला है जहाँ सर्वर storage credentials की एक persistent encrypted copy रखता है, क्योंकि आपके browser session के बंद होने पर भी link को काम करना होता है। Cloud Commander में share links की कोई सुविधा नहीं है।

यदि मैं अकेला user हूँ, तो क्या file manager को / पर पॉइंट करना सुरक्षित है?

नहीं, और यह जोखिम खुद पर भरोसा करने के बारे में नहीं है। यह process उन सभी फाइलों तक read और write access रखती है जहाँ तक इसका user account पहुँच सकता है, इसलिए उस session में कोई भी सेंध, चोरी हुई cookie, upload handler में कोई unpatched bug, या दोबारा इस्तेमाल किया गया पासवर्ड, /etc, आपकी SSH keys और हर service की data directory तक पहुँच प्रदान कर सकता है। इसके बजाय mount को केवल एक directory तक सीमित रखें: / के बजाय /srv/files। Cloud Commander में यह सबसे अधिक जोखिम भरा है, क्योंकि इसका प्रकाशित Docker command host root को /mnt/fs पर mount करता है और इसका sample config "auth": false के साथ "root": "/" सेट करता है। कंटेनर को localhost के अलावा कहीं भी listen करने से पहले इन दोनों को बदलें।