مقایسه بهترین مدیریت فایل‌های self-hosted برای سرور

مدیریت فایل self-hosted چیست و چه کاربردی ندارد

یک مدیریت فایل self-hosted، در واقع یک صفحه وب است که روی ساختار درختی دایرکتوری‌های موجود در VPS (سرور مجازی) شما قرار می‌گیرد. شما وارد سیستم می‌شوید، /srv/files را دقیقاً همان‌طور که روی دیسک قرار دارد می‌بینید و می‌توانید فایل‌ها را آپلود، تغییر نام یا دانلود کنید و یا لینکی از آن‌ها را در اختیار دیگران قرار دهید. هیچ فایلی در سیستم دومی کپی نمی‌شود؛ بنابراین فایلی که در مرورگر رها می‌کنید، همان فایلی است که ls یک ثانیه بعد نمایش می‌دهد.

نتایج جستجو اغلب این ابزارها را با نرم‌افزارهایی که وظایف متفاوتی دارند ترکیب می‌کنند. ابزارهای همگام‌سازی (Sync)، یک کپی از هر فایل را روی تمام دستگاه‌ها نگه می‌دارند که این دقیقاً همان کاری است که جایگزین self-hosted برای Dropbox انجام می‌دهد. فضای ذخیره‌سازی شیء‌گرا (Object storage) اصلاً ساختار درختی ندارد، بلکه از باکت‌ها و API استفاده می‌کند؛ بنابراین راه‌اندازی MinIO برای ذخیره‌سازی شیء‌گرای سازگار با S3 پاسخ به پرسش متفاوتی است. پنل‌های مدیریت سرور به جای فایل‌ها، خودِ ماشین را مدیریت می‌کنند و این موضوع در مقایسه Cockpit و Webmin بررسی شده است.

شما زمانی به یک مدیریت فایل نیاز دارید که همکارتان بخواهد یک آرشیو 300 MB را از روی سرور بردارد، یا زمانی که می‌خواهید یک غلط تایپی را در یک فایل پیکربندی از طریق گوشی موبایل اصلاح کنید. این کار کوچک است و ابزارهای آن نیز به همان اندازه سبک هستند.

هنگام مطالعه این مطلب، یک نکته را مد نظر داشته باشید: این یک اپلیکیشن وب با دسترسی خواندن و نوشتن به فایل‌سیستم شماست که روی یک پورت گوش می‌دهد. هر انتخابی که در ادامه می‌آید، در واقع تصمیمی است درباره اینکه آن پردازش تا چه حد به دیسک شما دسترسی داشته باشد.

پروژه FileBrowser آرشیو شده است؛ پیش از نصب این مطلب را بخوانید

FileBrowser، همان پروژه filebrowser/filebrowser، پاسخی است که اکثر راهنماها هنوز آن را پیشنهاد می‌دهند. فایل README این پروژه اکنون با این اطلاعیه آغاز می‌شود:

پروژه File Browser در تاریخ 2026-09-01 آرشیو شد. آخرین نسخه برنامه‌ریزی‌شده منتشر شده است. هیچ نسخه، رفع باگ یا وصله امنیتی دیگری برای آن ارائه نخواهد شد.

کد با مجوز Apache 2.0 همچنان کار می‌کند، اما وصله‌های امنیتی متوقف شده‌اند. این موضوع در این دسته‌بندی نرم‌افزاری اهمیت بیشتری نسبت به سایر موارد دارد، زیرا هدف اصلی این نرم‌افزار، فراهم کردن دسترسی نوشتن روی سیستم فایل از طریق HTTP است.

نگهدارندگان پروژه دستورالعملی برای نحوه ادامه استفاده از آن نوشته‌اند که توصیه‌هایش برای هر ابزاری که انتخاب می‌کنید ارزشمند است: آن را مستقیماً در معرض اینترنت قرار ندهید، آن را پشت یک reverse proxy قرار دهید که TLS (امنیت لایه انتقال) را مدیریت کرده و احراز هویت اختصاصی خود را انجام می‌دهد، قابلیت اجرای دستور (command runner) را غیرفعال کنید و آن را با دسترسی محدود (unprivileged) در یک container اجرا کنید که فقط دایرکتوری مورد نظر شما برای اشتراک‌گذاری در آن mount شده باشد.

یک خط در آن README از بقیه مهم‌تر است. نشست‌ها (Sessions) به صورت JWT (توکن‌های وب JSON) خودکفا هستند و نه شناسه‌های سمت سرور، بنابراین امکان ابطال آن‌ها وجود ندارد. توکن نشست لو رفته تا زمان انقضا معتبر باقی می‌ماند و تغییر رمز عبور نیز باعث ابطال آن نمی‌شود. اگر همچنان از FileBrowser استفاده می‌کنید، لایه احراز هویتی که در مقابل آن قرار داده‌اید، وظیفه اصلی امنیت را بر عهده دارد.

FileBrowser Quantum: فورکی که همچنان فعال است

توسعهٔ فعال به یک فورک به نام FileBrowser Quantum (gtsteffaniak/filebrowser) منتقل شده است که با ایمیج gtstef/filebrowser منتشر می‌شود. این نسخه پیکربندی را به‌جای ترکیب قدیمی فلگ‌های خط فرمان و تنظیمات دیتابیس، حول یک فایل config.yaml واحد بازسازی می‌کند. روش سریع پیشنهادی در مستندات به این صورت است:

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

این دستور دایرکتوری فعلی را روی http://localhost سرو می‌کند و اولین ورود با نام کاربری admin و رمز عبور admin انجام می‌شود. پیش از آنکه کانتینر از هر جایی به‌جز دستگاه خودتان در دسترس باشد، این اطلاعات را تغییر دهید.

برای نمونه‌ای که قصد نگهداری آن را دارید، از Compose استفاده کنید، به‌جای یک فایل دیتابیس تکی، کل دایرکتوری داده را mount کنید و پورت را روی localhost ببندید:

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

فایل پیکربندی در /home/filebrowser/data/config.yaml و دیتابیس در /home/filebrowser/data/filebrowser.sqlite قرار دارند. نسخه 2.0.0 فرمت دیتابیس را تغییر داده و یک مهاجرت یک‌باره انجام می‌دهد؛ به همین دلیل مستندات درخواست mount کردن دایرکتوری را دارند: در صورت mount کردن یک فایل تکی، مهاجرت جایی برای قرار دادن فایل جدید نخواهد داشت. مسیرهای داخل config.yaml مسیرهای داخل کانتینر هستند، بنابراین منبع در فایل پیکربندی باید به صورت /folder خوانده شود، نه /srv/files. اشتباه در این مورد باعث نمایش لیست فایل‌های خالی بدون هیچ خطایی می‌شود، زیرا آن دایرکتوری در واقع در آنجا وجود ندارد.

این پروژه ایمیج‌های latest و stable را با حجم حدود 60 مگابایت (شامل FFmpeg برای پیش‌نمایش ویدیوها) و ایمیج stable-slim را با حجم حدود 15 مگابایت (فقط هسته اصلی) منتشر می‌کند. این ارقام مربوط به صفحه نصب در اوت 2026 هستند. تگی که انتخاب کرده‌اید را ثابت (Pin) کنید. latest بدون اطلاع قبلی تغییر می‌کند و تغییر فرمت پیکربندی یک فایل‌منیجر در حالی که کانتینر در حال اجراست، می‌تواند صبح بدی را برای شما رقم بزند.

برای این کار، این ابزار قدرتمندترین گزینه در میان ابزارهای کوچک است. این ابزار چندین منبع را با قوانین include و exclude سرو می‌کند، بنابراین یک نمونه می‌تواند /srv/media و /srv/docs را با محدوده‌های دسترسی متفاوت ارائه دهد. اشتراک‌گذاری‌ها دارای زمان انقضا هستند و می‌توانند به‌صورت ناشناس یا محدود به یک کاربر خاص باشند. احراز هویت شامل OIDC (OpenID Connect)، LDAP (پروتکل سبک دسترسی به دایرکتوری)، رمز عبور با احراز هویت دو مرحله‌ای و حالت proxy header است. این حالت پروکسی همان چیزی است که اجازه می‌دهد این ابزار پشت یک سیستم ورود یکپارچه (SSO) از یک سرور Authentik خودمیزبان قرار بگیرد و نیازی به نگهداری لیست دوم کاربران نباشد.

Filestash: یک رابط کاربری برای فضای ذخیره‌سازی موجود شما

Filestash رویکرد متفاوتی دارد. این ابزار یک رابط کاربری (front end) است که به یک backend متصل می‌شود و فهرست backendهای پشتیبانی‌شده طولانی است: FTP، SFTP (پروتکل انتقال فایل SSH)، S3، SMB، WebDAV، IPFS و حدود 20 مورد دیگر. این ابزار زمانی مناسب است که فایل‌ها روی سیستمی که رابط کاربری را اجرا می‌کند، قرار ندارند.

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 را باز کنید؛ اولین صفحه از شما می‌خواهد رمز عبور مدیر (admin) را تنظیم کنید. بلافاصله آن را تنظیم کنید، زیرا تا زمانی که این کار را انجام ندهید، کنسول مدیریت برای هر کسی که پورت را پیدا کند، باز خواهد بود.

پیش از آنکه بر اساس این مدل پیش بروید، مدل احراز هویت آن را درک کنید. Filestash پایگاه داده کاربران را به معنای معمول آن نگه نمی‌دارد. اعتبارنامه‌ها در مرورگر شما از طریق کوکی‌هایی ذخیره می‌شوند که رمزنگاری‌شده، احراز هویت‌شده و فقط HTTP هستند. هیچ چیزی در سمت سرور ذخیره نمی‌شود، مگر اینکه از قابلیت اشتراک‌گذاری (share) استفاده کنید که در آن صورت، Filestash یک نسخه رمزنگاری‌شده و پایدار از اعتبارنامه‌های شما را نگه می‌دارد. «کاربران» در واقع همان حساب‌های ذخیره‌سازی هستند: هویت در backend (در حساب SFTP یا کلید S3) نهفته است، نه در Filestash.

این طراحی تمیز است، اما هزینه خاص خود را دارد. صفحه قیمت‌گذاری، نسخه رایگان self-hosted را تحت مجوز AGPL v3 (مجوز عمومی همگانی آفرو گنو) با حداکثر 3 کاربر فهرست کرده است و قابلیت‌های SSO (شامل SAML، OIDC و LDAP) به همراه کنترل دسترسی مبتنی بر نقش (RBAC) را در نسخه پولی self-hosted با قیمت شروع از 50 دلار در ماه (تا تاریخ آگوست 2026) قرار داده است. اگر قصد داشتید «Filestash را به صورت رایگان جلوی SSO سازمانی قرار دهید»، پیش از طراحی معماری خود، آن صفحه را بررسی کنید.

SFTPGo: یک سرور پروتکل که رابط کاربری وب نیز دارد

SFTPGo توانمندترین نرم‌افزار در این لیست است و اغلب به دلایل اشتباه توصیه می‌شود. این نرم‌افزار سرویس‌های SFTP، HTTP/S، FTP/S و WebDAV را بر بستر فایل‌سیستم محلی، فایل‌سیستم محلی رمزنگاری‌شده، فضای ذخیره‌سازی شیء (Object Storage) سازگار با S3، Google Cloud Storage، Azure Blob Storage یا یک سرور SFTP دیگر ارائه می‌دهد.

فایل‌های باینری، بسته‌های Debian و Ubuntu و یک ایمیج کانتینر برای آن منتشر شده است. خط مخزن APT فعلی و کلید امضای آن در صفحه نصب در مستندات SFTPGo موجود است. روش کانتینر سریع‌ترین راه برای راه‌اندازی آن است؛ کافی است tag را با نسخه مورد نظر خود جایگزین کنید:

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

سرویس SFTP روی پورت 2022 و رابط‌های وب روی پورت 8080 گوش می‌دهند. مسیر /srv/sftpgo را به عنوان یک volume مانت کنید، در غیر این صورت با بازسازی کانتینر، حساب‌های کاربری و فایل‌های آن‌ها از بین می‌روند، زیرا دایرکتوری‌های خانگی کاربران به‌صورت پیش‌فرض در /srv/sftpgo/data/<username> قرار دارند.

دو رابط وب وجود دارد و تفاوت آن‌ها بخشی است که اکثر راهنماها به آن اشاره نمی‌کنند. WebAdmin در آدرس /web/admin، بخش مدیریتی است: جایی که کاربران، گروه‌ها، پوشه‌های مجازی و قوانین رویدادها را ایجاد می‌کنید و سهمیه‌ها (Quotas)، محدودیت‌های پهنای باند و محدودیت‌های زمانی دسترسی را تنظیم می‌کنید. WebClient در آدرس /web/client، نمای کاربر نهایی است که در آن شخص فایل‌ها را مرور می‌کند، اعتبارنامه‌های خود را تغییر می‌دهد، احراز هویت دو مرحله‌ای را فعال می‌کند و اشتراک‌گذاری ایجاد می‌کند.

آن اشتراک‌گذاری‌ها بهترین نمونه در این مقایسه هستند. یک کاربر می‌تواند لینک‌های HTTP/S برای اشتراک‌گذاری فایل‌ها و پوشه‌ها ایجاد کند، تعداد دانلودها و آپلودها را محدود کند، اشتراک‌گذاری را با رمز عبور محافظت کند، دسترسی را بر اساس IP مبدأ محدود کند و تاریخ انقضای خودکار تعیین کند.

پس چرا باید محتاط بود؟ مرکز ثقل این نرم‌افزار، مدل حساب کاربری و سرور پروتکل است، نه تجربه مرور فایل‌ها. زمانی SFTPGo را انتخاب کنید که افراد دیگر نیاز به حساب‌های واقعی با سهمیه داشته باشند، زمانی که آپلودها از طریق SFTP یا FTPS از سیستمی که شما کنترل نمی‌کنید ارسال می‌شوند، یا زمانی که یک bucket باید در دایرکتوری خانگی چندین کاربر ظاهر شود. پوشه‌های مجازی (Virtual folders) مورد آخر را انجام می‌دهند: پوشه‌ای که توسط دیسک محلی، S3، GCS، Azure Blob، SFTP یا HTTP پشتیبانی می‌شود و در چندین حساب کاربری مانت می‌شود، با سهمیه جداگانه برای هر کاربر روی یک پوشه مشترک. اگر تنها چیزی که می‌خواستید یک صفحه قابل مرور روی /srv/files بود، این حجم از ابزارها برای آن کار بیش از حد است.

دو نکته دیگر که دانستن آن‌ها مفید است: نسخه Community فقط تحت مجوز AGPL-3.0 با شرایط اضافی است و در کنار آن یک نسخه Enterprise با مجوز تجاری وجود دارد. ورود با OIDC در نسخه متن‌باز موجود است و کاربران ارائه‌دهنده هویت را به مدیران و کاربران SFTPGo برای هر دو رابط وب نگاشت می‌کند. همچنین می‌توانید رابط کاربری کلاینت را به‌صورت سراسری با enable_web_client در فایل پیکربندی httpd غیرفعال کنید، یا برای هر کاربر با افزودن HTTP به پروتکل‌های مسدودشده آن کاربر، این کار را انجام دهید تا مدیریت فایل برای یک شخص فعال باشد و برای همه در دسترس نباشد.

Cloud Commander: دو پنل و یک ترمینال، برای استفاده شخصی

Cloud Commander یک مدیر فایل Node.js با مجوز MIT است که از سبک دو پنلی استفاده می‌کند و دارای ویرایشگر داخلی، کنسول و ترمینال است. آن را به‌صورت سراسری با npm i cloudcmd -g نصب کنید یا کانتینر منتشرشده را اجرا نمایید:

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

پیش از اجرای آن دستور، آن را مطالعه کنید. -v /:/mnt/fs کل فایل‌سیستم میزبان را در کانتینر mount می‌کند و نمونه ~/.cloudcmd.json شامل "root": "/"، "auth": false و "console": true است. این ترکیب به این معناست که هر کسی که به پورت 8000 دسترسی پیدا کند، به کل دیسک شما و یک کنسول فرمان روی سرور دسترسی خواهد داشت. این یک پیش‌فرض معقول برای لپ‌تاپ است، اما برای یک VPS انتخاب بدی محسوب می‌شود.

محدوده دسترسی آن را محدود کنید. این کانتینر فایل /root/.cloudcmd.json را می‌خواند که دستور منتشرشده با mount کردن دایرکتوری home شما آن را فراهم می‌کند؛ بنابراین 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

در آن فایل پیکربندی، "root" را روی /srv/files تنظیم کنید، "auth" را با استفاده از "username" و "password" روی true قرار دهید، و "console" و "terminal" را روی false تنظیم کنید، مگر اینکه واقعاً به دسترسی shell از طریق مرورگر نیاز داشته باشید. معادل‌های خط فرمان نیز وجود دارند، از جمله --root، --auth، --username، --password و --prefix.

در مورد ماهیت آن صادق باشید. این ابزار تنها یک جفت نام کاربری و رمز عبور دارد، محدودسازی بر اساس کاربر ندارد، سهمیه‌بندی (quota) ندارد و لینک اشتراک‌گذاری ارائه نمی‌دهد. این یک ابزار شخصی است، بنابراین آن را همان‌طور که در بالا گفته شد به localhost متصل کنید و از طریق یک تونل به آن دسترسی پیدا کنید:

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

سپس http://127.0.0.1:8000 را روی دستگاه خود باز کنید. مدیر فایل هرگز به‌صورت عمومی در معرض دید قرار نمی‌گیرد و تنها چیزی که رو به اینترنت است، همان سرویس SSH است که قبلاً روی VPS خود ایمن‌سازی کرده‌اید.

چرا Nextcloud ابزار اشتباهی برای این کار خاص است

Nextcloud نرم‌افزار خوبی است، اما برای این هدف طراحی نشده است. این یک پلتفرم همکاری است: یک برنامه PHP، یک پایگاه داده، کارهای پس‌زمینه (background jobs)، کلاینت‌های همگام‌سازی دسکتاپ و یک فروشگاه اپلیکیشن. اجرای آن صرفاً برای داشتن یک نمای وب از /srv/files، به دلیل اجزای متحرک زیاد، برای یک کار کوچک مناسب نیست و یک عدم تطابق مشخص وجود دارد. Nextcloud متادیتای فایل‌ها را در یک جدول پایگاه داده نگه می‌دارد، نه اینکه در هر درخواست دایرکتوری را بخواند؛ بنابراین فایل‌هایی که توسط rsync یا یک cron job نوشته می‌شوند، تا زمانی که اسکن بعدی انجام نشود، در رابط کاربری دیده نمی‌شوند، مگر با استفاده از sudo -u www-data php occ files:scan --all. یک مدیر فایل (file manager) در هر بار بارگذاری صفحه، دایرکتوری را لیست می‌کند، بنابراین چنین شکافی وجود ندارد.

Nextcloud را برای کارهایی که در آن‌ها عملکرد خوبی دارد حفظ کنید: تقویم‌ها، مخاطبین، همگام‌سازی و اشتراک‌گذاری با افرادی که انتظار کلاینت دسکتاپ دارند. Nextcloud روی یک VPS با Docker، TLS و پشتیبان‌گیری این پیکربندی را پوشش می‌دهد. اگر در حال حاضر آن را اجرا می‌کنید و فقط نیاز دارید یک دایرکتوری موجود را مشاهده کنید، اپلیکیشن External Storage را فعال کنید و کار را همان‌جا متوقف کنید. یک اپلیکیشن وب دوم با دسترسی نوشتن روی همان دیسک، یک مورد اضافه برای وصله‌کردن (patch) است.

نحوه اجرای یک سرویس بدون در معرض خطر قرار دادن کل سرور

هرگز آن را به / اشاره ندهید. این پردازش می‌تواند تمام فایل‌هایی که حساب کاربری‌اش به آن‌ها دسترسی دارد را بخواند و بنویسد؛ بنابراین، یک توکن نشست (session token) سرقت‌شده، دقیقاً به همان میزان دسترسی به فایل‌سیستم را برای مهاجم فراهم می‌کند. تنها یک دایرکتوری، یعنی /srv/files را سرو کنید و آن را صرفاً برای همین منظور ایجاد کنید.

سرویس را با یک کاربر غیر-root اجرا کنید و فقط آنچه را که باید سرو شود، mount کنید. در Compose، این کار با user: "1000:1000" و یک bind mount برای هر دایرکتوری انجام می‌شود؛ همچنین برای هر فایلی که نیازی به نوشتن در آن نیست، از :ro استفاده کنید:

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

نتیجه معمول این تغییر آن است که مرور فایل‌ها کار می‌کند اما آپلودها با خطای permission denied مواجه می‌شوند، زیرا شناسه کاربری (UID) داخل کانتینر مالک دایرکتوری در خارج از آن نیست. این دو را مقایسه کنید: docker exec filebrowser id کاربر کانتینر را چاپ می‌کند و ls -ln /srv/files مالک عددی فایل در میزبان (host) را نشان می‌دهد. مشکل را با sudo chown -R 1000:1000 /srv/files برطرف کنید. این همان مشکل مالکیتی است که PUID و PGID در ایمیج‌های Docker برای حل آن وجود دارند.

پورت منتشرشده را به localhost متصل کنید، یعنی 127.0.0.1:8080:80 به جای 8080:80. داکر قوانین netfilter خود را پیش از قوانین ufw اعمال می‌کند، بنابراین یک پورت که به سادگی منتشر شده باشد، حتی زمانی که ufw deny 8080 فعال است، از اینترنت قابل دسترسی باقی می‌ماند. برای TLS، یک reverse proxy در مقابل آن قرار دهید. در پروتکل HTTP ساده، کوکی نشست به‌صورت متن آشکار در شبکه جابه‌جا می‌شود و آن کوکی در واقع همان دسترسی به فایل‌سیستم است. اگر با Compose آشنا نیستید، Docker Compose روی VPS ساختار فایلی که این قطعه‌کدها فرض می‌کنند را توضیح می‌دهد.

زمانی که مکانیزم احراز هویت خودِ برنامه ضعیف است، یک لایه احراز هویت اضافه کنید. برای یک نمونه تک‌کاربره، HTTP basic auth در سطح پروکسی کافی است. هنگامی که بیش از یک نفر درگیر است، از OIDC یا forward auth در برابر یک identity provider استفاده کنید تا با ابطال یک حساب، دسترسی در همه جا لغو شود.

قابلیت‌های اضافی را غیرفعال کنید. هر مدیر فایلی که shell، اجرای دستور یا ترمینال درون‌مرورگری ارائه می‌دهد، در واقع امکان اجرای کد از راه دور (RCE) را برای هر کسی که یک نشست معتبر داشته باشد، فراهم می‌کند. توصیه خودِ FileBrowser این است که command runner را غیرفعال نگه دارید و نمونه پیکربندی Cloud Commander نیز کنسول را فعال می‌کند. آگاهانه تصمیم بگیرید، نه بر اساس تنظیمات پیش‌فرض.

چه چیزی زودتر از کار می‌افتد و خطاهایی که مشاهده خواهید کرد

listen tcp :80: bind: permission denied. لینوکس پورت‌های زیر 1024 را برای پردازش‌های دارای دسترسی ممتاز (privileged) رزرو می‌کند. پیکربندی مستندشده FileBrowser Quantum از پورت 80 استفاده می‌کند که داخل کانتینر مشکلی ندارد، اما به محض اجرای باینری توسط یک کاربر بدون دسترسی ممتاز روی هاست، با خطا مواجه می‌شود. در config.yaml پورتی بالاتر از 1024 تنظیم کنید و اجازه دهید پروکسی پورت 443 را در اختیار بگیرد.

آپلودها با خطا مواجه می‌شوند در حالی که مرور فایل‌ها کار می‌کند. لیست کردن محتویات یک دایرکتوری به r-x نیاز دارد، اما نوشتن در آن نیازمند w است. رابط کاربری وب یک خطای کلی گزارش می‌دهد، بنابراین پیش از بررسی لاگ‌های برنامه، سیستم فایل را کنترل کنید.

413 Request Entity Too Large. این خطا از سمت nginx است، نه از سمت مدیریت فایل. مقدار پیش‌فرض client_max_body_size برابر با 1 MB است، بنابراین آپلودهای بزرگ‌تر پیش از آنکه به برنامه برسند، توسط پروکسی رد می‌شوند. مقدار client_max_body_size 4096m; را در بلوک server تنظیم کنید، یا برای غیرفعال کردن این بررسی، از 0 استفاده نمایید.

فایل‌های آپلود شده گروه اشتباهی دارند. فایل‌های جدید متعلق به کاربری هستند که پردازش را اجرا کرده است، فارغ از اینکه دایرکتوری والد چه تنظیماتی دارد؛ این موضوع باعث اختلال در سرویس دومی می‌شود که همان مسیر را می‌خواند. به هر دو سرویس یک گروه مشترک اختصاص دهید و با استفاده از sudo chmod g+s /srv/files، بیت setgid را روی دایرکتوری تنظیم کنید تا فایل‌های جدید، گروه دایرکتوری را به ارث ببرند.

همه چیز روی پورت مستقیم کار می‌کند اما پشت پروکسی از کار می‌افتد. برنامه‌ای که در یک زیرمسیر (subpath) ارائه می‌شود، لینک‌ها را بر اساس پیشوندی می‌سازد که باید به آن معرفی شود. Cloud Commander برای این منظور --prefix را دارد. در مواردی که چنین گزینه‌ای وجود ندارد، به برنامه یک زیردامنه اختصاص دهید و مسیر ریشه (root) را پروکسی کنید.

کدام مدیر فایل self-hosted را باید اجرا کنید؟

• یک VPS، یک یا دو دایرکتوری، اشتراک‌گذاری لینک‌ها با تاریخ انقضا و شاید SSO در آینده: FileBrowser Quantum.
• فایل‌هایی که در جای دیگری قرار دارند، یک S3 bucket یا یک میزبان SFTP یا یک NAS از طریق SMB، و شما یک نمای وب واحد برای همه آن‌ها می‌خواهید: Filestash، در محدودیت‌های نسخه رایگان.
• افراد دیگر نیاز به حساب کاربری، سهمیه (quota) و آپلود از طریق SFTP یا FTPS دارند: SFTPGo، با در نظر گرفتن کلاینت وب به عنوان یک قابلیت جانبی مفید، نه دلیل اصلی انتخاب آن.
• یک ابزار شخصی با ویرایشگر و ترمینال، که از طریق SSH tunnel در دسترس است و هرگز منتشر نمی‌شود: Cloud Commander.
• Nextcloud از قبل در حال اجرا است و دایرکتوری موجودی برای ارائه دارید: برنامه External Storage، و بدون نیاز به هیچ نرم‌افزار جدیدی.

هر چه انتخاب کنید، نحوه استقرار (deployment) اهمیت بیشتری نسبت به خود انتخاب دارد. یک دایرکتوری، یک کاربر غیر root، پورتی که به localhost متصل شده و احراز هویت در لایه جلویی. مدیر فایلی که به این شکل تنظیم شده باشد، یک ابزار کاربردی است. همان نرم‌افزار اگر به / اشاره کند و رمز عبور مشترک داشته باشد، عملاً یک shell از راه دور با رابط کاربری زیباست.

FAQ

آیا اجرای FileBrowser در سال 2026 همچنان امن است؟

فایل README در مخزن بالادستی filebrowser/filebrowser اعلام می‌کند که پروژه File Browser در تاریخ 2026-09-01 آرشیو شده است و دیگر هیچ نسخه جدید، رفع باگ یا وصله امنیتی برای آن منتشر نخواهد شد. کد برنامه همچنان اجرا می‌شود، اما نرم‌افزاری که وصله نشده و به سیستم فایل شما دسترسی نوشتن دارد، ریسکی است که با گذشت زمان افزایش می‌یابد. اگر قصد دارید از آن استفاده کنید، توصیه‌های خود پروژه را دنبال کنید: آن را مستقیماً در معرض اینترنت قرار ندهید، از یک reverse proxy برای مدیریت TLS و احراز هویت استفاده کنید، قابلیت command runner را غیرفعال نگه دارید و آن را در یک container بدون دسترسی ریشه (unprivileged) اجرا کنید که فقط دایرکتوری مورد نظر در آن mount شده باشد. همچنین توجه داشته باشید که نشست‌های (sessions) این برنامه از نوع JWTهای مستقل هستند و نه شناسه‌های سمت سرور؛ بنابراین امکان ابطال آن‌ها وجود ندارد و تغییر رمز عبور، توکن‌های صادر شده قبلی را باطل نمی‌کند. برای نصب جدید، از فورک FileBrowser Quantum استفاده کنید که با ایمیج gtstef/filebrowser منتشر می‌شود و توسعه آن همچنان ادامه دارد.

آیا یک مدیریت فایل self-hosted می‌تواند از SSO موجود من استفاده کند؟

برنامه FileBrowser Quantum از OIDC، LDAP و حالت proxy header پشتیبانی می‌کند، بنابراین می‌تواند پشت یک ارائه‌دهنده هویت (identity provider) قرار بگیرد بدون اینکه نیاز به مدیریت لیست کاربران جداگانه باشد. یکپارچه‌سازی OpenID Connect در نسخه متن‌باز SFTPGo موجود است و کاربران ارائه‌دهنده هویت را به مدیران و کاربران SFTPGo برای رابط‌های WebAdmin و WebClient نگاشت می‌کند. Filestash یک استثنا است که باید به آن توجه کرد: صفحه قیمت‌گذاری آن، قابلیت SSO (شامل SAML، OIDC و LDAP) را در نسخه پولی self-hosted با هزینه شروع از 50 دلار در ماه (از اوت 2026) قرار داده است، در حالی که نسخه رایگان آن تحت مجوز AGPL v3 و با محدودیت حداکثر 3 کاربر ارائه می‌شود. زمانی که یک برنامه هیچ پشتیبانی از SSO ندارد، راهکار جایگزین استفاده از forward authentication در reverse proxy است که صفحه ورود را محافظت می‌کند، اما دسترسی‌های داخلی خود برنامه را تغییر نمی‌دهد.

کدام‌یک از این ابزارها لینک‌های اشتراک‌گذاری با قابلیت انقضا ارائه می‌دهند؟

برنامه SFTPGo کامل‌ترین پیاده‌سازی را دارد. کاربر می‌تواند از طریق WebClient یک لینک HTTP/S ایجاد کند و تعداد دانلودها و آپلودها را محدود کرده، رمز عبور تعیین کند، دسترسی را بر اساس IP مبدأ محدود نماید و تاریخ انقضای خودکار تنظیم کند. FileBrowser Quantum از اشتراک‌گذاری با زمان انقضا پشتیبانی می‌کند که دسترسی آن می‌تواند به صورت ناشناس یا محدود به یک کاربر خاص باشد؛ همچنین امکان تعیین مجوزهای مشاهده، ویرایش و آپلود برای هر لینک اشتراک‌گذاری وجود دارد. Filestash نیز قابلیت اشتراک‌گذاری دارد و تنها موردی است که سرور یک کپی رمزنگاری‌شده و دائمی از اعتبارنامه‌های ذخیره‌سازی را نگه می‌دارد، زیرا لینک باید زمانی که نشست مرورگر شما بسته شده است نیز کار کند. برنامه Cloud Commander هیچ قابلیتی برای ایجاد لینک اشتراک‌گذاری ندارد.

آیا اشاره دادن یک مدیریت فایل به مسیر / در صورتی که تنها کاربر هستم، امن است؟

خیر، و این ریسک در واقع به اعتماد شما به خودتان مربوط نمی‌شود. این پردازش دارای دسترسی خواندن و نوشتن به تمام نقاطی است که حساب کاربری آن به آن‌ها دسترسی دارد؛ بنابراین هر راه نفوذی به آن نشست، سرقت کوکی، یک باگ وصله‌نشده در مدیریت آپلود یا استفاده مجدد از رمز عبور، به معنای دسترسی به /etc، کلیدهای SSH و دایرکتوری داده‌های تمام سرویس‌های شما خواهد بود. محدوده mount را به جای /، تنها به یک دایرکتوری خاص مانند /srv/files محدود کنید. این موضوع در Cloud Commander بیشترین آسیب را می‌زند، زیرا دستور Docker منتشر شده برای آن، ریشه میزبان را در /mnt/fs mount می‌کند و فایل پیکربندی نمونه آن، "root": "/" را با "auth": false تنظیم کرده است. پیش از آنکه این container روی هر چیزی به جز localhost گوش دهد، هر دو مورد را تغییر دهید.