خود میزبانی والے file managers کا تقابلی جائزہ

خود میزبانی والے file manager کی نوعیت اور اس کی حدود

خود میزبانی والا file manager آپ کے VPS (virtual private server) پر پہلے سے موجود directory tree کے لیے ایک web page ہوتا ہے۔ آپ login کرتے ہیں، /srv/files کو disk پر موجود اصل حالت میں دیکھتے ہیں، اور files upload، rename یا download کرتے ہیں، یا کسی کو link بھیجتے ہیں۔ کوئی چیز دوسرے system میں copy نہیں ہوتی۔ اس لیے browser میں شامل کی گئی file وہی file ہوتی ہے جسے ls ایک second بعد دکھاتا ہے۔

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 manage کرتے ہیں، اور یہی Cockpit اور Webmin کا تقابل ہے۔

آپ کو file manager اس وقت چاہیے جب کسی colleague کو server سے 300 MB کا archive لینا ہو، یا آپ phone سے config file میں موجود typo درست کرنا چاہتے ہوں۔ کام محدود ہے، اس لیے tools بھی سادہ ہیں۔

پڑھتے وقت ایک بات ذہن میں رکھیں۔ یہ ایک web application ہے جسے آپ کے filesystem تک read اور write access حاصل ہے اور جو ایک port پر listening کر رہی ہے۔ ذیل میں ہر انتخاب دراصل اس بات کا انتخاب ہے کہ وہ process آپ کی disk کے کتنے حصے تک پہنچ سکتی ہے۔

FileBrowser کو archive کر دیا گیا ہے، اس لیے اسے install کرنے سے پہلے یہ پڑھیں

FileBrowser، یعنی filebrowser/filebrowser project، اب بھی زیادہ تر guides میں تجویز کیا جاتا ہے۔ اس کے README کے آغاز میں اب یہ notice موجود ہے:

File Browser کو 2026-09-01 کو archive کر دیا گیا ہے۔ آخری planned release جاری ہو چکی ہے۔ اس کے بعد کوئی نئی release، bug fix یا security fix نہیں آئے گی۔

Apache 2.0 code بدستور کام کرتا رہے گا، لیکن security fixes بند ہو جائیں گی۔ اس category کے لیے یہ بات زیادہ اہم ہے، کیونکہ اس software کا بنیادی مقصد HTTP کے ذریعے filesystem کو write access فراہم کرنا ہے۔

Maintainers نے اسے چلتا رکھنے کا طریقہ درج کیا ہے۔ آپ جو بھی tool منتخب کریں، یہ advice اختیار کرنا مفید ہے: اسے براہِ راست internet پر expose نہ کریں، اسے ایسے reverse proxy کے پیچھے رکھیں جو TLS (transport layer security) termination کرے اور اپنی authentication انجام دے، command runner کو disabled رکھیں، اور اسے container میں unprivileged طور پر چلائیں۔ Container میں صرف وہی directory mount کریں جسے آپ serve کرنا چاہتے ہیں۔

اس README کی ایک سطر باقی تمام باتوں سے زیادہ اہم ہے۔ Sessions server-side identifiers کے بجائے خود مختار JWTs (JSON web tokens) ہوتی ہیں، اس لیے انہیں revoke نہیں کیا جا سکتا۔ Leaked session token اپنی expiry تک valid رہتا ہے، اور password تبدیل کرنے سے بھی وہ ختم نہیں ہوتا۔ اگر آپ FileBrowser استعمال کرتے رہیں، تو اس کے سامنے موجود authentication layer ہی اصل security فراہم کر رہی ہوگی۔

FileBrowser Quantum: اب بھی فعال fork

فعال development ایک fork، FileBrowser Quantum (gtsteffaniak/filebrowser) میں منتقل ہو چکی ہے، جو gtstef/filebrowser image کے طور پر شائع کیا جاتا ہے۔ یہ configuration کو پرانے command line flags اور database settings کے امتزاج کے بجائے ایک واحد config.yaml کے گرد دوبارہ ترتیب دیتا ہے۔ دستاویزات میں درج فوری آزمائش:

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

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 حقیقتاً وہاں موجود نہیں ہوتی۔

Project latest اور stable تقریباً 60 MB حجم میں شائع کرتا ہے، جن میں video thumbnails کے لیے FFmpeg شامل ہے، جبکہ stable-slim تقریباً 15 MB حجم میں صرف core کے ساتھ آتا ہے۔ یہ اعداد August 2026 کے install page پر درج ہیں۔ اپنے منتخب کردہ tag کو pin کریں۔ latest آپ کو بتائے بغیر تبدیل ہو جاتا ہے، اور ایسا file manager جو چلتے ہوئے container کے اندر اپنا config format تبدیل کر دے، انتظامی مسئلہ پیدا کرتا ہے۔

اس کام کے لیے یہ چھوٹے tools میں سب سے مضبوط انتخاب ہے۔ یہ include اور exclude rules کے ذریعے متعدد 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: پہلے سے موجود storage کے لیے ایک interface

Filestash کا ڈھانچا مختلف ہے۔ یہ ایک front end ہے جو backend سے connect ہوتا ہے، اور اس کے backend اختیارات کی فہرست طویل ہے: FTP، SFTP (SSH file transfer protocol)، S3، SMB، WebDAV، IPFS اور تقریباً بیس مزید۔ یہ اس وقت موزوں ہے جب files اس machine پر موجود نہ ہوں جو interface چلا رہی ہو۔

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 set کیا جاتا ہے۔ اسے فوراً set کریں، کیونکہ اس کے بغیر port تلاش کرنے والا کوئی بھی شخص admin console تک رسائی حاصل کر سکتا ہے۔

اس پر build کرنے سے پہلے identity model سمجھیں۔ Filestash عام مفہوم میں user database نہیں رکھتا۔ Credentials آپ کے browser میں cookies کے ذریعے محفوظ ہوتے ہیں۔ یہ cookies encrypted، authenticated اور HTTP only ہوتی ہیں۔ جب تک آپ share feature استعمال نہ کریں، server side پر کچھ محفوظ نہیں ہوتا۔ share feature استعمال کرنے کی صورت میں Filestash آپ کے credentials کا ایک مستقل encrypted ورژن محفوظ رکھتا ہے۔ "users" دراصل storage accounts ہیں۔ Identity backend میں موجود ہوتی ہے، یعنی SFTP account یا S3 key میں، Filestash میں نہیں۔

یہ design صاف اور سادہ ہے، لیکن اس کی قیمت بھی ہے۔ 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 کو company SSO کے سامنے مفت چلایا جائے"، تو اس کے گرد design بنانے سے پہلے وہ page دیکھ لیں۔

SFTPGo: ایک protocol server جس میں web interface بھی شامل ہے

SFTPGo یہاں موجود سافٹ ویئر میں سب سے زیادہ صلاحیت رکھتا ہے، اور اسے عموماً غلط وجہ سے تجویز کیا جاتا ہے۔ یہ SFTP، HTTP/S، FTP/S اور WebDAV کو local filesystem، encrypted local filesystem، S3 compatible object storage، Google Cloud Storage، Azure Blob Storage یا کسی دوسرے SFTP server پر فراہم کرتا ہے۔

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 انتظامی interface ہے۔ یہاں users، groups، virtual folders اور event rules بنائے جاتے ہیں، اور quotas، bandwidth limits اور access time restrictions مقرر کی جاتی ہیں۔ /web/client پر موجود WebClient end user کا interface ہے۔ یہاں صارف files browse کرتا ہے، اپنی credentials تبدیل کرتا ہے، two factor authentication ترتیب دیتا ہے اور shares بناتا ہے۔

اس موازنے میں shares اس کی بہترین خصوصیت ہیں۔ صارف files اور folders share کرنے کے لیے HTTP/S links بنا سکتا ہے، downloads اور uploads کی تعداد محدود کر سکتا ہے، share کو password سے محفوظ کر سکتا ہے، source IP address کے لحاظ سے access محدود کر سکتا ہے، اور خودکار expiration date مقرر کر سکتا ہے۔

تو احتیاط کی وجہ کیا ہے؟ اس کا بنیادی مرکز browsing experience نہیں بلکہ account model اور protocol server ہے۔ SFTPGo اس وقت منتخب کریں جب دوسرے لوگوں کو quotas کے ساتھ حقیقی accounts درکار ہوں، جب uploads ایسے system سے SFTP یا FTPS کے ذریعے آئیں جسے آپ control نہیں کرتے، یا جب ایک bucket متعدد users کی home directories کے اندر ظاہر کرنی ہو۔ Virtual folders یہی آخری کام کرتے ہیں: local disk، S3، GCS، Azure Blob، SFTP یا HTTP سے backed ایک folder متعدد accounts میں mount کیا جا سکتا ہے، اور shared folder پر ہر user کے لیے الگ quota مقرر کی جا سکتی ہے۔ اگر آپ کی ضرورت صرف /srv/files پر browse کی جانے والی page تھی، تو اس مقصد کے لیے یہ بہت زیادہ machinery ہے۔

دو مزید باتیں قابل ذکر ہیں۔ Community edition AGPL-3.0-only ہے اور اس کے ساتھ additional terms بھی ہیں، جبکہ Enterprise edition commercial license کے تحت دستیاب ہے۔ OIDC login open source build میں شامل ہے، اور یہ دونوں web interfaces کے لیے identity provider users کو SFTPGo admins اور users سے map کرتا ہے۔ آپ httpd configuration میں enable_web_client کے ذریعے client interface کو globally بھی بند کر سکتے ہیں، یا کسی user کے denied protocols میں HTTP شامل کر کے اسے صرف اس user کے لیے بند کر سکتے ہیں۔ اس طرح file manager ایک شخص کے لیے دستیاب رہ سکتا ہے اور باقی سب کے لیے بند ہو سکتا ہے۔

Cloud Commander: دو panes اور terminal، ایک فرد کے لیے

Cloud Commander، MIT لائسنس یافتہ Node.js manager ہے جو دو-pane طرز پر کام کرتا ہے۔ اس میں built-in editor، console اور terminal شامل ہیں۔ اسے npm i cloudcmd -g کے ذریعے globally install کریں، یا published 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 فراہم کرتا ہے۔ اس combination کا مطلب ہے کہ port 8000 تک پہنچنے والا ہر شخص server کی پوری disk اور command console تک رسائی حاصل کر لیتا ہے۔ یہ laptop کے لیے مناسب default ہے، لیکن VPS کے لیے نہیں۔

اس کا دائرہ محدود کریں۔ Container /root/.cloudcmd.json پڑھتا ہے۔ Published command اسے آپ کی home directory mount کرکے فراہم کرتی ہے، اس لیے config mount برقرار رکھیں اور باقی mounts ہٹا دیں:

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" کے ساتھ، اور "console" اور "terminal" کو false پر set کریں، جب تک کہ آپ کو واقعی browser shell access درکار نہ ہو۔ Command-line equivalents بھی موجود ہیں، جن میں --root، --auth، --username، --password اور --prefix شامل ہیں۔

اس کی صلاحیتوں کے بارے میں واضح رہیں۔ اس میں credentials کا صرف ایک pair ہوتا ہے، فی user scoping نہیں ہوتی، quotas نہیں ہوتیں، اور share links نہیں ہوتے۔ یہ ذاتی استعمال کا tool ہے، اس لیے اسے اوپر کی طرح localhost پر bind کریں اور tunnel کے ذریعے access کریں:

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

پھر اپنی machine پر http://127.0.0.1:8000 کھولیں۔ File manager کبھی public طور پر exposed نہیں ہوتا، اور internet کی طرف صرف وہی SSH daemon موجود ہوتا ہے جسے آپ نے اپنے VPS پر harden کیا ہے۔

اس ایک کام کے لیے Nextcloud غلط ٹول کیوں ہے

Nextcloud اچھا سافٹ ویئر ہے، لیکن یہ اس کام کے لیے موزوں نہیں۔ یہ ایک 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 صفحہ load کرتے وقت directory کی فہرست بناتا ہے، اس لیے یہ تاخیر موجود نہیں ہوتی۔

Nextcloud کو ان کاموں کے لیے رکھیں جن میں یہ اچھا ہے: calendars، contacts، sync، اور ان لوگوں کے ساتھ sharing جو desktop client استعمال کرتے ہیں۔ Docker، TLS اور backups کے ساتھ VPS پر Nextcloud میں اس setup کی وضاحت ہے۔ اگر آپ پہلے ہی اسے چلا رہے ہیں اور صرف موجودہ directory دیکھنا چاہتے ہیں تو External Storage app فعال کریں اور یہیں رک جائیں۔ اسی disk تک write access رکھنے والی دوسری web application ایک اور patch کرنے والا جزو ہے۔

پورا سرور ظاہر کیے بغیر اسے کیسے چلائیں

اسے کبھی بھی / کی طرف مت لگائیں۔ یہ عمل اپنے user account کی رسائی میں موجود ہر چیز پڑھ اور لکھ سکتا ہے، اس لیے چوری شدہ session token اتنی ہی filesystem access فراہم کرتا ہے۔ صرف ایک directory، /srv/files، serve کریں اور اسے اسی مقصد کے لیے بنائیں۔

اسے non-root user کے طور پر چلائیں اور صرف وہی چیزیں mount کریں جنہیں یہ serve کرتا ہے۔ Compose میں اس کا مطلب user: "1000:1000" اور ہر directory کے لیے ایک bind mount ہے، جبکہ جن چیزوں میں اسے کبھی لکھنے کی ضرورت نہیں، ان پر :ro لگائیں:

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

اس تبدیلی کا عام نتیجہ یہ ہوتا ہے کہ browsing کام کرتی ہے، لیکن uploads permission denied کے ساتھ ناکام ہو جاتے ہیں، کیونکہ container کے اندر موجود user id کو container سے باہر کی directory کی ملکیت حاصل نہیں ہوتی۔ دونوں کا موازنہ کریں: docker exec filebrowser id container user دکھاتا ہے، جبکہ ls -ln /srv/files host پر numeric owner دکھاتا ہے۔ اسے sudo chown -R 1000:1000 /srv/files کے ذریعے درست کریں۔ یہی ownership problem ہے جسے Docker images میں PUID اور PGID حل کرنے کے لیے موجود ہیں۔

Published port کو localhost، یعنی 127.0.0.1:8080:80، سے bind کریں، نہ کہ 8080:80 سے۔ Docker اپنے netfilter rules، ufw کے rules سے پہلے لکھتا ہے، اس لیے عام طور پر published port internet سے قابل رسائی رہتا ہے، چاہے ufw deny 8080 فعال ہو۔ TLS کے لیے سامنے reverse proxy رکھیں۔ Plain HTTP پر session cookie network میں غیر مشفر منتقل ہوتی ہے، اور یہی cookie filesystem access فراہم کرتی ہے۔ اگر Compose آپ کے لیے نیا ہے تو VPS پر Docker Compose اس file layout کی وضاحت کرتا ہے جسے یہ snippets فرض کرتے ہیں۔

جب application کی اپنی authentication محدود ہو تو اضافی authentication layer شامل کریں۔ ایک user instance کے لیے proxy پر HTTP basic auth کافی ہے۔ ایک سے زیادہ افراد شامل ہوں تو identity provider کے خلاف OIDC یا forward auth استعمال کریں، تاکہ ایک account کو revoke کرنے سے ہر جگہ اس کی access ختم ہو جائے۔

غیر ضروری اضافی features بند کریں۔ ایسا file manager جو shell، command runner یا in-browser terminal فراہم کرتا ہو، valid session رکھنے والے ہر شخص کو remote code execution دے رہا ہوتا ہے۔ FileBrowser کی اپنی guidance command runner کو disabled رکھنے کی ہے، جبکہ Cloud Commander's sample config console کو enabled کرتی ہے۔ فیصلہ default کے مطابق نہیں، واضح مقصد کے مطابق کریں۔

سب سے پہلے کیا خراب ہوتا ہے، اور آپ کو کون سی errors نظر آئیں گی

listen tcp :80: bind: permission denied۔ Linux مراعات یافتہ processes کے لیے 1024 سے کم ports محفوظ رکھتا ہے۔ FileBrowser Quantum کی دستاویزی configuration میں port 80 استعمال ہوتا ہے، جو container کے اندر درست ہے، لیکن host پر binary کو unprivileged user کے طور پر چلاتے ہی ناکام ہو جاتا ہے۔ config.yaml میں 1024 سے زیادہ port مقرر کریں اور 443 کی ذمہ داری proxy کو دیں۔

Browsing کام کرتا ہے، لیکن uploads ناکام ہوتے ہیں۔ Directory کی listing کے لیے r-x درکار ہے، جبکہ اس میں لکھنے کے لیے w درکار ہے۔ Web interface ایک عمومی error دکھاتا ہے، اس لیے پہلے application logs کے بجائے filesystem چیک کریں۔

413 Request Entity Too Large۔ یہ error nginx کی طرف سے آتی ہے، file manager کی طرف سے نہیں۔ Default client_max_body_size مقدار 1 MB ہے، اس لیے بڑی upload کو proxy اسی وقت مسترد کر دیتا ہے، اس سے پہلے کہ application اسے دیکھ سکے۔ client_max_body_size 4096m; کو server block میں مقرر کریں، یا چیک غیر فعال کرنے کے لیے 0 استعمال کریں۔

Uploaded files کے ساتھ غلط group منسلک ہوتا ہے۔ نئی files کی ownership process user کے پاس ہوتی ہے، چاہے اردگرد کی directory میں کچھ بھی مقرر ہو۔ اس سے اسی tree کو پڑھنے والی دوسری service متاثر ہوتی ہے۔ دونوں services کے لیے مشترکہ group بنائیں اور sudo chmod g+s /srv/files کے ذریعے directory پر setgid bit مقرر کریں، تاکہ نئی files directory کا group inherit کریں۔

Port پر سب کچھ کام کرتا ہے، لیکن proxy کے پیچھے ناکام ہو جاتا ہے۔ Subpath کے تحت چلنے والی application links ایک ایسے prefix سے بناتی ہے جس کے بارے میں اسے آگاہ کرنا ضروری ہے۔ Cloud Commander میں اس مقصد کے لیے --prefix موجود ہے۔ جہاں ایسا option موجود نہ ہو، وہاں application کے لیے الگ subdomain بنائیں اور root path کو proxy کریں۔

کون سا self-hosted file manager چلانا چاہیے؟

• ایک VPS، ایک یا دو directories، expiry کے ساتھ share links، اور ممکنہ طور پر بعد میں SSO درکار ہو: FileBrowser Quantum۔
• فائلیں کسی دوسرے مقام، S3 bucket، SFTP host یا SMB کے ذریعے NAS پر موجود ہوں، اور آپ ان سب کے لیے ایک web view چاہتے ہوں: Filestash، مگر free tier کی حدود کے اندر۔
• دوسرے لوگوں کو accounts، quotas، اور SFTP یا FTPS کے ذریعے uploads درکار ہوں: SFTPGo۔ اس صورت میں web client کو مفید اضافی سہولت سمجھیں، انتخاب کی بنیادی وجہ نہیں۔
• editor اور terminal والا ذاتی tool، جس تک SSH tunnel کے ذریعے رسائی ہو اور جسے کبھی public نہ کیا جائے: Cloud Commander۔
• Nextcloud پہلے سے چل رہا ہو اور expose کرنے کے لیے موجودہ directory ہو: External Storage app استعمال کریں، اور کوئی نیا software بالکل نہ لگائیں۔

آپ جو بھی انتخاب کریں، deployment کی اہمیت انتخاب سے زیادہ ہے۔ ایک directory، non-root user، localhost پر bound port، اور سامنے authentication رکھیں۔ اس طرح configure کیا گیا file manager صرف سہولت ہے۔ یہی software / پر shared password کے ساتھ point کیا جائے تو یہ اچھے interface والا remote shell بن جاتا ہے۔

FAQ

کیا 2026 میں FileBrowser چلانا اب بھی محفوظ ہے؟

upstream filebrowser/filebrowser README کے مطابق File Browser کو 2026-09-01 کو archive کر دیا جائے گا، اور اس کے بعد کوئی نئی release، bug fix یا security fix جاری نہیں ہوگی۔ code اب بھی چلتا ہے، لیکن ایسا unpatched software جسے filesystem تک write access حاصل ہو، وقت کے ساتھ بڑھتا ہوا خطرہ بن جاتا ہے۔ اگر آپ اسے برقرار رکھتے ہیں تو project کی اپنی ہدایات پر عمل کریں: اسے internet پر براہ راست expose نہ کریں، TLS اور اپنی authentication کے لیے reverse proxy استعمال کریں، command runner کو disabled رکھیں، اور صرف served directory mount کے ساتھ unprivileged container چلائیں۔ یہ بھی یاد رکھیں کہ اس کے sessions server-side identifiers کے بجائے self-contained JWTs ہوتے ہیں، اس لیے انہیں revoke نہیں کیا جا سکتا، اور password تبدیل کرنے سے جاری شدہ token invalid نہیں ہوتا۔ نئی installation کے لیے FileBrowser Quantum استعمال کریں، جو gtstef/filebrowser image کے طور پر published ہے اور جس کی development جاری ہے۔

کیا self-hosted file manager میری موجودہ SSO استعمال کر سکتا ہے؟

FileBrowser Quantum OIDC، LDAP اور proxy header mode کو support کرتا ہے، اس لیے اسے دوسری user list کے بغیر موجودہ identity provider کے پیچھے چلایا جا سکتا ہے۔ SFTPGo کا OpenID Connect integration open source build میں شامل ہے اور identity provider کے users کو WebAdmin اور WebClient دونوں interfaces کے لیے SFTPGo admins اور users سے map کرتا ہے۔ Filestash وہ exception ہے جس پر توجہ دینی چاہیے: اگست 2026 تک اس کے pricing page پر SSO (SAML، OIDC اور LDAP) کو $50 فی ماہ سے paid self-hosted tier میں رکھا گیا ہے، جبکہ free tier کو زیادہ سے زیادہ 3 users کے ساتھ AGPL v3 کے طور پر درج کیا گیا ہے۔ جب کسی application میں SSO support بالکل نہ ہو تو متبادل کے طور پر reverse proxy پر forward authentication استعمال کی جا سکتی ہے۔ یہ login page کو محفوظ کرتی ہے، لیکن application کی داخلی permissions میں کوئی تبدیلی نہیں کرتی۔

ان میں سے کون سا ایسے share links فراہم کرتا ہے جو expire ہو جائیں؟

SFTPGo کا implementation سب سے مکمل ہے۔ user WebClient سے HTTP/S link بناتا ہے اور downloads اور uploads کی تعداد محدود کر سکتا ہے، password مقرر کر سکتا ہے، source IP address کے ذریعے access محدود کر سکتا ہے، اور automatic expiration date مقرر کر سکتا ہے۔ FileBrowser Quantum expiration time کے ساتھ shares support کرتا ہے۔ access anonymous ہو سکتا ہے یا کسی user تک محدود کیا جا سکتا ہے، اور ہر share کے لیے viewing، editing اور uploading کی permissions الگ مقرر کی جا سکتی ہیں۔ Filestash میں بھی share feature موجود ہے۔ یہ وہ واحد صورت ہے جس میں server storage credentials کی persistent encrypted copy محفوظ رکھتا ہے، کیونکہ browser session ختم ہونے کے بعد بھی link کو کام کرنا ہوتا ہے۔ Cloud Commander میں share links بالکل نہیں ہیں۔

اگر میں واحد user ہوں تو کیا file manager کو / پر point کرنا محفوظ ہے؟

نہیں، اور خطرہ دراصل خود پر اعتماد کرنے سے متعلق نہیں ہے۔ process کو ہر اس چیز تک read اور write access حاصل ہوتی ہے جہاں اس کا user account پہنچ سکتا ہے۔ اس لیے اس session تک پہنچنے والا کوئی بھی راستہ، چوری شدہ cookie، upload handler میں unpatched bug، یا دوبارہ استعمال کیا گیا password، /etc، آپ کی SSH keys اور ہر service کی data directory تک access بن جاتا ہے۔ اس کے بجائے mount کو ایک directory تک محدود کریں: /srv/files، نہ کہ /۔ Cloud Commander میں یہ خطرہ سب سے زیادہ نمایاں ہے، کیونکہ اس کی published Docker command host root کو /mnt/fs پر mount کرتی ہے اور اس کی sample config "root": "/" کو "auth": false کے ساتھ set کرتی ہے۔ اس container کے localhost کے علاوہ کسی اور interface پر listen کرنے سے پہلے دونوں settings تبدیل کریں۔