Self-hosted file manager तुलना: FileBrowser, Filestash

स्वतः होस्ट केलेला file manager म्हणजे काय आणि तो काय नाही

स्वतः होस्ट केलेला file manager म्हणजे तुमच्या VPS (virtual private server) वरील आधीपासून अस्तित्वात असलेल्या directory tree साठीचे एक web page होय. तुम्ही login करता आणि /srv/files disk वर जसे आहे तसेच पाहता. त्यानंतर तुम्ही file upload, rename किंवा download करू शकता किंवा एखाद्याला link देऊ शकता. कोणतीही file दुसऱ्या system मध्ये copy केली जात नाही. त्यामुळे तुम्ही browser मधून ठेवलेली file एक सेकंदानंतर ls मध्येही दिसते.

Search results मध्ये याच्यासोबत इतर कामे करणारे software एकत्र दाखवले जातात. Sync tools प्रत्येक device वर प्रत्येक file ची copy ठेवतात. स्वतः होस्ट केलेला Dropbox पर्याय यासाठी असतो. Object storage मध्ये directory tree नसते. त्यात buckets आणि API असतात. त्यामुळे S3 compatible object storage साठी MinIO चालवणे हा वेगळ्या गरजेचा उपाय आहे. Server admin panels files ऐवजी machine चे व्यवस्थापन करतात. त्यासाठी Cockpit आणि Webmin ची तुलना पहा.

एखाद्या सहकाऱ्याला server वरून 300 MB चे archive हवे असल्यास किंवा phone वरून config file मधील typo दुरुस्त करायचा असल्यास file manager वापरा. काम मर्यादित आहे आणि tools देखील तसेच लहान आहेत.

वाचताना एक महत्त्वाची गोष्ट लक्षात ठेवा. हा filesystem ला read आणि write access असलेला, एका port वर listening करणारा web application आहे. खालील प्रत्येक निवड म्हणजे त्या process ला तुमच्या disk पैकी किती भागापर्यंत पोहोचता येईल, याबाबतची निवड आहे.

FileBrowser संग्रहित झाले आहे; ते install करण्यापूर्वी हे वाचा

FileBrowser हा filebrowser/filebrowser project आहे आणि बहुतेक guides अजूनही हाच पर्याय सुचवतात. त्याच्या README ची सुरुवात आता या सूचनेने होते:

File Browser 2026-09-01 रोजी संग्रहित झाले आहे. नियोजित शेवटचे release आधीच जारी झाले आहे. यापुढे कोणतेही release, bug fixes किंवा security fixes मिळणार नाहीत.

Apache 2.0 code कार्यरत राहील. मात्र security fixes बंद होतील. या प्रकारच्या software साठी हे विशेष महत्त्वाचे आहे, कारण HTTP द्वारे filesystem वर write access देणे हाच त्याचा मुख्य उद्देश आहे.

ते सुरू ठेवण्यासाठी आवश्यक पद्धत maintainers ने लिहून ठेवली आहे. तुम्ही कोणतेही tool निवडले तरी हा सल्ला पाळणे योग्य आहे: ते थेट internet वर expose करू नका; TLS (transport layer security) termination करणाऱ्या आणि स्वतः authentication करणाऱ्या reverse proxy मागे ते ठेवा; command runner disabled ठेवा; तसेच फक्त serve करायची directory mount केलेल्या container मध्ये ते unprivileged user म्हणून चालवा.

README मधील एक ओळ इतर सर्व मजकुरापेक्षा अधिक महत्त्वाची आहे. Sessions हे server-side identifiers ऐवजी self-contained JWTs (JSON web tokens) असतात, त्यामुळे ते revoke करता येत नाहीत. Session token leak झाल्यास तो expire होईपर्यंत valid राहतो. Password बदलल्यानेही तो invalid होत नाही. FileBrowser वापरत राहिल्यास त्यासमोरील authentication layer प्रत्यक्ष सुरक्षा कार्य करते.

FileBrowser Quantum: अजूनही सक्रियपणे विकसित होत असलेला fork

सक्रिय विकास FileBrowser Quantum (gtsteffaniak/filebrowser) या fork कडे हलवण्यात आला आहे. ते gtstef/filebrowser image म्हणून प्रकाशित केले जाते. जुन्या command line flags आणि database settings यांच्या मिश्रणाऐवजी एकाच config.yaml भोवती त्याची configuration पुन्हा तयार करण्यात आली आहे. दस्तऐवजांमधील जलद चाचणी:

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

यामुळे current directory http://localhost येथे serve होते आणि पहिला login admin / admin असा असतो. Container तुमच्या स्वतःच्या मशीनशिवाय इतर कुठूनही पोहोचण्यायोग्य होण्यापूर्वी तो बदला.

तुम्ही कायम ठेवणार असलेल्या 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

Configuration /home/filebrowser/data/config.yaml येथे आणि database /home/filebrowser/data/filebrowser.sqlite येथे असतो. Version 2.0.0 मध्ये database format बदलला आणि एकदाच migration केली जाते. म्हणूनच दस्तऐवजांमध्ये directory mount करण्यास सांगितले आहे: एकाच file च्या mount मध्ये नवीन file ठेवण्यासाठी migration कडे जागा राहत नाही. config.yaml मधील paths हे container paths आहेत. त्यामुळे configuration मधील source /folder वाचतो, /srv/files नाही. हे उलटे केल्यास कोणतीही error न दाखवता file list रिकामी दिसते, कारण ती directory प्रत्यक्षात उपलब्धच नसते.

प्रकल्प सुमारे 60 MB आकाराच्या latest आणि stable या images प्रकाशित करतो. Video thumbnails साठी त्यामध्ये FFmpeg समाविष्ट आहे. Core-only image stable-slim सुमारे 15 MB आकाराची आहे. हे August 2026 मधील install page वरील आकडे आहेत. तुम्ही निवडलेला tag pin करा. latest तुमची माहिती न देता बदलू शकते. Running container अंतर्गत configuration format बदलणारा file manager त्रासदायक ठरतो.

या कामासाठी लहान साधनांमध्ये हे सर्वात सक्षम आहे. हे include आणि exclude rules वापरून अनेक sources serve करते. त्यामुळे एकाच instance मधून /srv/media आणि /srv/docs वेगवेगळ्या scope सह expose करता येतात. Shares ला expiration time असतो आणि त्या anonymous किंवा एखाद्या user पुरत्या restricted असू शकतात. Authentication मध्ये OIDC (OpenID Connect), LDAP (lightweight directory access protocol), two factor असलेला password आणि proxy header mode यांचा समावेश आहे. हा proxy mode वापरल्यामुळे users ची दुसरी यादी ठेवण्याऐवजी self-hosted Authentik server कडून single sign on (SSO) मागे ते चालवता येते.

Filestash: तुमच्याकडे आधीपासून असलेल्या storage साठी एकच interface

Filestash ची रचना वेगळी आहे. हे backend शी जोडणारे front end आहे. उपलब्ध backend ची यादी मोठी आहे: FTP, SFTP (SSH file transfer protocol), S3, SMB, WebDAV, IPFS आणि आणखी सुमारे वीस पर्याय. Interface चालवणाऱ्या मशीनवर files नसतील, तेव्हा हे उपयुक्त ठरते.

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

Image machines/filestash:latest आहे. http://your_domain:8334 उघडा. पहिल्या screen वर admin password सेट करता येतो. ते लगेच सेट करा. तोपर्यंत port शोधणाऱ्या कोणत्याही व्यक्तीसाठी admin console उघडा असतो.

Filestash वर आधारित रचना करण्यापूर्वी त्याचे identity model समजून घ्या. नेहमीच्या अर्थाने Filestash user database ठेवत नाही. Credentials तुमच्या browser मध्ये encrypted, authenticated आणि HTTP only cookies द्वारे साठवले जातात. Share feature वापरल्याशिवाय server side वर काहीही साठवले जात नाही. Share feature वापरल्यास Filestash तुमच्या credentials ची persistent encrypted आवृत्ती ठेवतो. येथे "users" म्हणजे storage accounts आहेत. Identity Filestash मध्ये नसते. ती backend मध्ये, म्हणजे SFTP account किंवा S3 key मध्ये असते.

ही रचना सुटसुटीत आहे, पण तिची किंमत आहे. Pricing page नुसार free self-hosted tier AGPL v3 (GNU Affero General Public License) अंतर्गत असून त्यात 3 users पर्यंतची मर्यादा आहे. SSO (SAML, OIDC आणि LDAP) आणि role based access control हे paid self-hosted tier मध्ये दिले आहेत. August 2026 पर्यंत त्याची किंमत $50 per month पासून सुरू होते. "Filestash in front of company SSO, for free" अशी योजना असल्यास, तिच्या आधारे रचना करण्यापूर्वी ते page तपासा.

SFTPGo: web interface असलेला protocol server

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 वर ऐकते आणि web interfaces 8080 वर उपलब्ध असतात. /srv/sftpgo ला volume म्हणून mount करा. अन्यथा container पुन्हा तयार केल्यावर accounts आणि त्यांच्या files नाहीशा होतील, कारण user home directories चे default स्थान /srv/sftpgo/data/<username> आहे.

येथे दोन web interfaces आहेत. त्यांच्यातील फरक हा बहुतेक लेखांमध्ये स्पष्टपणे सांगितला जात नाही. /web/admin वरील WebAdmin हे administrative interface आहे. येथे users, groups, virtual folders आणि event rules तयार करता येतात. तसेच quotas, bandwidth limits आणि access time restrictions सेट करता येतात. /web/client वरील WebClient हे end user view आहे. येथे वापरकर्ता files browse करतो, स्वतःची credentials बदलतो, two factor authentication सेट करतो आणि shares तयार करतो.

या तुलनेत shares हे सर्वात उपयुक्त वैशिष्ट्य आहे. वापरकर्ता files आणि folders share करण्यासाठी HTTP/S links तयार करू शकतो. Downloads आणि uploads ची संख्या मर्यादित करता येते. Share ला password ने सुरक्षित करता येते. Source IP address नुसार access मर्यादित करता येतो. तसेच automatic expiration date सेट करता येते.

मग सावधगिरी का? याचा मुख्य भर browsing experience वर नसून account model आणि protocol server वर आहे. इतर लोकांना quotas असलेली वास्तविक accounts आवश्यक असतील, तुमच्या नियंत्रणाबाहेरील एखाद्या system कडून uploads SFTP किंवा FTPS वर येत असतील, किंवा एकाच bucket मधील सामग्री अनेक users' home directories मध्ये दाखवायची असेल, तर SFTPGo निवडा. Virtual folders हे शेवटचे काम करतात. Local disk, S3, GCS, Azure Blob, SFTP किंवा HTTP वर आधारित folder अनेक accounts मध्ये mount करता येतो आणि shared folder वर प्रत्येक user साठी स्वतंत्र quota ठेवता येते. तुम्हाला /srv/files वर फक्त browse करता येणारे page हवे असेल, तर त्यासाठी ही रचना गरजेपेक्षा मोठी आहे.

आणखी दोन बाबी लक्षात ठेवा. Community edition ही अतिरिक्त अटींसह AGPL-3.0-only license अंतर्गत उपलब्ध आहे. यासोबत commercial license असलेली Enterprise edition देखील आहे. OIDC login open source build मध्ये उपलब्ध आहे. तो identity provider मधील users ना दोन्ही web interfaces साठी SFTPGo admins आणि users शी map करतो. httpd configuration मध्ये enable_web_client वापरून client interface सर्व users साठी बंद करता येतो. किंवा त्या user च्या denied protocols मध्ये HTTP जोडून ते एका user साठी बंद करता येते. त्यामुळे file manager एका व्यक्तीसाठी उपलब्ध ठेवता येतो आणि इतरांसाठी बंद ठेवता येतो.

Cloud Commander: एका व्यक्तीसाठी दोन panes आणि terminal

Cloud Commander हे MIT परवानाधारित Node.js manager आहे. त्याची रचना दोन panes ची आहे. त्यामध्ये built-in editor, console आणि terminal आहेत. ते npm i cloudcmd -g ने globally install करा किंवा प्रकाशित container चालवा:

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

तो command चालवण्यापूर्वी वाचा. -v /:/mnt/fs संपूर्ण host filesystem container मध्ये mount करते. तसेच नमुना ~/.cloudcmd.json मध्ये "root": "/", "auth": false आणि "console": true समाविष्ट आहेत. या संयोजनामुळे port 8000 पर्यंत पोहोचणाऱ्या कोणालाही तुमची संपूर्ण disk आणि server वरील command console मिळते. Laptop साठी हा default योग्य आहे. VPS साठी तो अयोग्य आहे.

त्याचा scope कमी करा. Container /root/.cloudcmd.json वाचतो. प्रकाशित command तुमची home directory mount करून ही file पुरवतो. त्यामुळे config mount ठेवा आणि उर्वरित भाग काढून टाका:

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

त्या config file मध्ये "root" हे /srv/files वर सेट करा. "auth" हे true वर सेट करा आणि त्यासाठी "username" व "password" वापरा. तुम्हाला browser shell access खरोखर आवश्यक नसेल, तर "console" आणि "terminal" हे false वर सेट करा. यासाठी command line पर्यायही आहेत. त्यामध्ये --root, --auth, --username, --password आणि --prefix यांचा समावेश आहे.

ते नेमके काय आहे याबाबत स्पष्ट रहा. यात एकच credential pair आहे. Per-user scoping नाही. Quotas नाहीत. Share links नाहीत. हे personal tool आहे. त्यामुळे वर दिल्याप्रमाणे ते localhost ला bind करा आणि tunnel द्वारे वापरा:

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

त्यानंतर स्वतःच्या machine वर http://127.0.0.1:8000 उघडा. File manager सार्वजनिकरीत्या exposed नसतो. Internet-facing एकमेव सेवा म्हणजे तुमचा आधीच VPS वर harden केलेला SSH daemon असतो.

हे एक काम करण्यासाठी Nextcloud योग्य साधन का नाही

Nextcloud हे चांगले software आहे; पण हे काम त्यासाठी नाही. हे collaboration platform आहे: PHP application, database, background jobs, desktop sync clients आणि app store यांचा समावेश असलेली प्रणाली. /srv/files चे web view मिळवण्यासाठी ते चालवणे या लहान कामासाठी खूप घटक हाताळण्यास भाग पाडते आणि त्यात एक विशिष्ट विसंगती आहे. Nextcloud प्रत्येक request वेळी directory वाचण्याऐवजी file metadata database table मध्ये ठेवते. त्यामुळे rsync किंवा cron job ने लिहिलेल्या files interface मध्ये scan पूर्ण होईपर्यंत दिसणार नाहीत; यामुळे sudo -u www-data php occ files:scan --all. File manager page load करताना directory list करतो, त्यामुळे ही तफावत राहत नाही.

Nextcloud ज्या कामांसाठी चांगले आहे त्यासाठीच वापरा: calendars, contacts, sync आणि desktop client वापरण्याची अपेक्षा असलेल्या लोकांसोबत sharing. Docker, TLS आणि backups सह VPS वर Nextcloud या setup चे वर्णन करते. तुम्ही ते आधीपासून चालवत असाल आणि फक्त विद्यमान directory पाहायची असेल, तर External Storage app enable करून तिथेच थांबा. त्याच disk वर write access असलेले दुसरे web application म्हणजे patch करण्याची आणखी एक जबाबदारी.

संपूर्ण सर्व्हरचा प्रवेश न देता ते कसे चालवावे

ते कधीही / वर निर्देशित करू नका. प्रक्रिया तिच्या user account ला उपलब्ध असलेल्या सर्व गोष्टी वाचू आणि लिहू शकते. त्यामुळे चोरीला गेलेला session token तितक्याच filesystem access मध्ये रूपांतरित होतो. एकच directory, /srv/files, serve करा आणि हा उद्देश लक्षात घेऊन ती तयार करा.

ते non-root user म्हणून चालवा आणि ते serve करत असलेली सामग्री एवढीच mount करा. Compose मध्ये यासाठी user: "1000:1000" आणि प्रत्येक directory साठी एक bind mount वापरा. ज्या directory मध्ये त्याला लिहिण्याची गरज नाही, त्यावर :ro द्या:

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

या बदलाचा सामान्य परिणाम असा असतो की browsing सुरू राहते, पण uploads permission denied मुळे अयशस्वी होतात. याचे कारण असे की container मधील user id ला बाहेरील directoryची मालकी नसते. दोन्ही मूल्यांची तुलना करा: docker exec filebrowser id container मधील user दाखवते, तर ls -ln /srv/files host वरील numeric owner दाखवते. sudo chown -R 1000:1000 /srv/files वापरून ते दुरुस्त करा. Docker images मधील PUID आणि PGID हीच ownership समस्या सोडवण्यासाठी असतात.

Published port localhost, म्हणजे 127.0.0.1:8080:80, वर bind करा; 8080:80 वर करू नका. Docker स्वतःचे netfilter rules ufw च्या rulesच्या आधी लिहिते. त्यामुळे ufw deny 8080 सक्रिय असतानाही स्पष्टपणे published केलेला port इंटरनेटवरून उपलब्ध राहतो. TLS साठी समोर reverse proxy ठेवा. Plain HTTP वापरल्यास session cookie network वर उघडपणे पाठवली जाते. ती cookie filesystem access देते. Compose तुमच्यासाठी नवीन असल्यास, VPS वर Docker Compose या मार्गदर्शकात या snippets गृहीत धरत असलेली file layout स्पष्ट केली आहे.

अॅप्लिकेशनचे स्वतःचे authentication अपुरे असल्यास स्वतंत्र authentication layer जोडा. एका user instance साठी proxy वरील HTTP basic auth पुरेसे आहे. एकापेक्षा अधिक व्यक्ती सहभागी असल्यास identity provider विरुद्ध OIDC किंवा forward auth वापरा. त्यामुळे एखादे account revoke केल्यावर सर्वत्र त्याचा access revoke करता येतो.

अनावश्यक सुविधा बंद करा. Shell, command runner किंवा in-browser terminal देणारा कोणताही file manager वैध session असलेल्या व्यक्तीला remote code execution देतो. FileBrowser च्या मार्गदर्शनानुसार command runner disabled ठेवावा. Cloud Commander च्या sample config मध्ये console enabled असते. हे default वर न सोडता जाणीवपूर्वक ठरवा.

प्रथम काय बिघडते आणि कोणत्या त्रुटी दिसतील

listen tcp :80: bind: permission denied. Linux privileged processes साठी 1024 पेक्षा कमी ports राखून ठेवते. FileBrowser Quantum च्या documented config मध्ये port 80 वापरला आहे. Container मध्ये हे योग्य आहे, पण host वर binary unprivileged user म्हणून चालवल्यावर ते लगेच fail होते. config.yaml मध्ये 1024 पेक्षा मोठा port सेट करा आणि 443 चे व्यवस्थापन proxy कडे द्या.

Uploads fail while browsing works. Directory ची listing करण्यासाठी r-x आवश्यक आहे. त्यात लिहिण्यासाठी w आवश्यक आहे. Web interface generic error दाखवते. त्यामुळे application logs आधी तपासण्याऐवजी filesystem तपासा.

413 Request Entity Too Large. ही error file manager कडून नाही, तर nginx कडून येते. Default client_max_body_size 1 MB आहे. त्यामुळे मोठा upload application पर्यंत पोहोचण्यापूर्वीच proxy कडून reject केला जातो. client_max_body_size 4096m; मध्ये server block अंतर्गत सेट करा किंवा तपासणी बंद करण्यासाठी 0 वापरा.

Uploaded files carry the wrong group. नवीन files process user च्या मालकीच्या होतात. आजूबाजूच्या directory मध्ये कोणता group सेट केला आहे, याचा त्यावर परिणाम होत नाही. त्यामुळे त्याच tree मधून वाचणारी दुसरी service fail होऊ शकते. दोन्ही services साठी shared group द्या आणि sudo chmod g+s /srv/files वापरून directory वर setgid bit सेट करा. त्यामुळे नवीन files ला directory चा group inherit होईल.

Everything works on the port and breaks behind the proxy. Subpath अंतर्गत चालणारे application links तयार करण्यासाठी prefix वापरते. हा prefix application ला सांगणे आवश्यक असते. Cloud Commander मध्ये यासाठी --prefix उपलब्ध आहे. अशी option उपलब्ध नसल्यास application साठी स्वतंत्र 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 हवे असल्यास: free tier च्या मर्यादांमध्ये Filestash.
• इतर लोकांना accounts, quotas आणि SFTP किंवा FTPS द्वारे uploads आवश्यक असल्यास: SFTPGo. येथे web client हा उपयुक्त अतिरिक्त भाग मानावा; तो निवडीचे मुख्य कारण नसावे.
• editor आणि terminal असलेले personal tool, SSH tunnel द्वारे वापरायचे आणि कधीही publicly publish करायचे नसल्यास: Cloud Commander.
• Nextcloud आधीच चालू असेल आणि expose करण्यासाठी existing directory असेल: External Storage app वापरा; नवीन software अजिबात नको.

तुम्ही कोणताही पर्याय निवडला, तरी निवडीपेक्षा deployment अधिक महत्त्वाचे आहे. एक directory, non-root user, localhost ला bind केलेला port आणि समोर authentication असावे. अशा प्रकारे setup केलेला file manager ही सुविधा ठरते. तेच software / कडे point करून shared password वापरल्यास, चांगल्या interface असलेला remote shell तयार होतो.

FAQ

2026 मध्ये FileBrowser चालवणे अजून सुरक्षित आहे का?

Upstream filebrowser/filebrowser README नुसार File Browser हे 2026-09-01 रोजी archived झाले असून त्यानंतर कोणतेही releases, bug fixes किंवा security fixes मिळणार नाहीत. Code अजूनही चालतो; परंतु filesystem वर write access असलेले unpatched software कालांतराने वाढणारा धोका ठरते. ते वापरत राहिल्यास प्रकल्पाच्या स्वतःच्या सूचनांचे पालन करा: इंटरनेटवर थेट exposure ठेवू नका, TLS आणि स्वतंत्र authentication करणारा reverse proxy वापरा, command runner disabled ठेवा आणि फक्त सेवा दिली जाणारी directory mounted असलेला unprivileged container वापरा. हेही लक्षात ठेवा की त्याची sessions server-side identifiers ऐवजी self-contained JWTs असतात. त्यामुळे त्या revoke करता येत नाहीत आणि password बदलल्याने issued token invalidate होत नाही. नवीन install साठी FileBrowser Quantum fork वापरा. तो gtstef/filebrowser image म्हणून प्रकाशित केला जातो आणि त्याचा development सुरू आहे.

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 बाबत मात्र काळजी घ्या: August 2026 पर्यंतच्या त्याच्या pricing page नुसार SSO (SAML, OIDC आणि LDAP) हे $50 per month पासून सुरू होणाऱ्या paid self-hosted tier मध्ये आहे. Free tier मध्ये AGPL v3 आणि कमाल 3 users दिले आहेत. एखाद्या application मध्ये SSO support अजिबात नसल्यास reverse proxy वरील forward authentication हा पर्याय आहे. तो login page सुरक्षित करतो; परंतु application च्या internal permissions मध्ये बदल करत नाही.

यापैकी कोणत्यामध्ये कालबाह्य होणाऱ्या share links मिळतात?

SFTPGo मध्ये सर्वांत पूर्ण implementation आहे. User WebClient मधून HTTP/S link तयार करू शकतो. Downloads आणि uploads ची संख्या मर्यादित करता येते, password सेट करता येतो, source IP address नुसार access प्रतिबंधित करता येतो आणि automatic expiration date सेट करता येते. FileBrowser Quantum मध्ये expiration time असलेले shares समर्थित आहेत. त्यांचा access anonymous ठेवता येतो किंवा एखाद्या user पुरता मर्यादित करता येतो. प्रत्येक share साठी viewing, editing आणि uploading permissions स्वतंत्रपणे सेट करता येतात. Filestash मध्येही share feature आहे. Browser session संपल्यानंतरही link कार्यरत राहणे आवश्यक असल्यामुळे server storage credentials ची persistent encrypted copy ठेवतो, हे यातील विशेष प्रकरण आहे. Cloud Commander मध्ये share links अजिबात नाहीत.

मी एकटाच user असल्यास file manager ला / कडे निर्देशित करणे सुरक्षित आहे का?

नाही. हा धोका स्वतःवर विश्वास ठेवण्याशी संबंधित नाही. Process ला त्याच्या user account ला उपलब्ध असलेल्या प्रत्येक गोष्टीवर read आणि write access असतो. त्यामुळे त्या session मध्ये जाणारा कोणताही path, चोरीला गेलेला cookie, upload handler मधील unpatched bug किंवा पुन्हा वापरलेला password यामुळे /etc, तुमच्या SSH keys आणि प्रत्येक service च्या data directory ला access मिळू शकतो. त्याऐवजी mount ची व्याप्ती एका directory पुरती मर्यादित ठेवा: /srv/files, / ऐवजी. Cloud Commander मध्ये हा धोका सर्वाधिक आहे, कारण त्याच्या प्रकाशित Docker command मध्ये host root /mnt/fs येथे mount केला आहे आणि sample config मध्ये "root": "/" हे "auth": false सह सेट केले आहे. हा container localhost शिवाय इतर कोणत्याही interface वर listen करण्यापूर्वी दोन्ही बदला.