เปรียบเทียบ Self-hosted File Manager ตัวไหนดีที่สุด

ไฟล์เมเนเจอร์แบบ self-hosted คืออะไร และไม่ใช่สิ่งใด

ไฟล์เมเนเจอร์แบบ self-hosted คือหน้าเว็บที่ครอบอยู่บนโครงสร้างไดเรกทอรีที่มีอยู่แล้วบน VPS (virtual private server) ของคุณ เมื่อคุณเข้าสู่ระบบ คุณจะเห็น /srv/files ตามที่ปรากฏอยู่บนดิสก์จริง คุณสามารถอัปโหลด เปลี่ยนชื่อ ดาวน์โหลด หรือส่งลิงก์ให้ผู้อื่นได้ โดยไม่มีการคัดลอกไฟล์ไปยังระบบที่สอง ดังนั้นไฟล์ที่คุณลากวางในเบราว์เซอร์จะเป็นไฟล์เดียวกับที่ ls แสดงให้เห็นในวินาทีถัดมา

ผลการค้นหามักทำให้สิ่งนี้สับสนกับซอฟต์แวร์ที่ทำหน้าที่อื่น เครื่องมือซิงค์ข้อมูลจะเก็บสำเนาของทุกไฟล์ไว้ในทุกอุปกรณ์ ซึ่งนั่นคือหน้าที่ของ ทางเลือก Dropbox แบบ self-hosted ส่วน object storage จะไม่มีโครงสร้างไดเรกทอรี แต่จะมี bucket และ API ดังนั้น การรัน MinIO สำหรับ object storage ที่รองรับ S3 จึงเป็นการตอบโจทย์ที่ต่างออกไป ส่วนแผงควบคุมเซิร์ฟเวอร์ (admin panel) จะจัดการที่ตัวเครื่องไม่ใช่ตัวไฟล์ ซึ่งนั่นเป็นเรื่องของ การเปรียบเทียบ Cockpit และ Webmin

คุณต้องการไฟล์เมเนเจอร์เมื่อเพื่อนร่วมงานต้องการไฟล์ archive ขนาด 300 MB ออกจากเซิร์ฟเวอร์ หรือเมื่อคุณต้องการแก้ไขคำผิดในไฟล์ config จากโทรศัพท์มือถือ งานเหล่านี้เป็นงานขนาดเล็ก และเครื่องมือเหล่านี้ก็เช่นกัน

โปรดจำข้อเท็จจริงหนึ่งประการขณะที่คุณอ่าน นี่คือเว็บแอปพลิเคชันที่มีสิทธิ์อ่านและเขียนบนระบบไฟล์ของคุณ โดยทำงานผ่านพอร์ต ตัวเลือกทั้งหมดด้านล่างนี้คือการตัดสินใจว่ากระบวนการนั้นจะสามารถเข้าถึงดิสก์ของคุณได้มากน้อยเพียงใด

FileBrowser ถูกยุติการพัฒนาแล้ว โปรดอ่านข้อมูลนี้ก่อนติดตั้ง

FileBrowser ซึ่งเป็นโปรเจกต์ filebrowser/filebrowser คือคำตอบที่คู่มือส่วนใหญ่ยังคงแนะนำ แต่ปัจจุบันไฟล์ README ของโปรเจกต์ได้เปิดหัวด้วยประกาศดังนี้:

File Browser ถูกยุติการพัฒนา (archived) เมื่อวันที่ 2026-09-01 โดย release สุดท้ายที่วางแผนไว้ได้ถูกปล่อยออกมาเรียบร้อยแล้ว จะไม่มีการออก release ใหม่ การแก้ไขบั๊ก หรือการแก้ไขช่องโหว่ด้านความปลอดภัยอีกต่อไป

โค้ดภายใต้สัญญาอนุญาต Apache 2.0 จะยังคงทำงานได้ตามปกติ แต่การแก้ไขด้านความปลอดภัยจะสิ้นสุดลง ซึ่งประเด็นนี้มีความสำคัญสำหรับซอฟต์แวร์ประเภทนี้มากกว่าซอฟต์แวร์ทั่วไป เนื่องจากวัตถุประสงค์หลักของซอฟต์แวร์คือการเข้าถึงระบบไฟล์เพื่อเขียนข้อมูลผ่าน HTTP

ผู้ดูแลโปรเจกต์ได้ระบุแนวทางในการใช้งานต่อ ซึ่งเป็นคำแนะนำที่ควรปฏิบัติตามไม่ว่าคุณจะเลือกใช้เครื่องมือใดก็ตาม ได้แก่ ห้ามเปิดใช้งานโดยตรงสู่สาธารณะบนอินเทอร์เน็ต, ให้วางไว้หลัง reverse proxy ที่ทำหน้าที่จัดการ TLS (transport layer security) และทำหน้าที่ตรวจสอบสิทธิ์ (authentication) ด้วยตนเอง, ปิดการใช้งานฟังก์ชันสั่งรันคำสั่ง (command runner) และรันซอฟต์แวร์ใน container โดยไม่ใช้สิทธิ์ root พร้อมกับ mount เฉพาะไดเรกทอรีที่ต้องการให้บริการเท่านั้น

มีประโยคหนึ่งใน README ที่มีความสำคัญยิ่งกว่าส่วนอื่น คือ session ของโปรแกรมนี้เป็น JWT (JSON web tokens) ที่ทำงานแบบเบ็ดเสร็จในตัว ไม่ใช่ตัวระบุตัวตนที่ฝั่งเซิร์ฟเวอร์ ดังนั้นจึงไม่สามารถเพิกถอนสิทธิ์ได้ หาก token ของ session หลุดออกไป มันจะยังคงใช้งานได้จนกว่าจะหมดอายุ และการเปลี่ยนรหัสผ่านจะไม่สามารถยกเลิก session นั้นได้ หากคุณยังคงเลือกใช้ FileBrowser ชั้นการตรวจสอบสิทธิ์ที่อยู่หน้าโปรแกรมจะเป็นส่วนที่ทำหน้าที่รักษาความปลอดภัยที่แท้จริง

FileBrowser Quantum: ทางเลือกที่ยังคงมีการพัฒนาอย่างต่อเนื่อง

การพัฒนาหลักได้ย้ายไปยังโปรเจกต์แยก (fork) ที่ชื่อว่า FileBrowser Quantum (gtsteffaniak/filebrowser) ซึ่งเผยแพร่ในรูปแบบอิมเมจ gtstef/filebrowser โดยมีการปรับโครงสร้างการตั้งค่าใหม่ให้รวมอยู่ในไฟล์ config.yaml เพียงไฟล์เดียว แทนที่จะใช้การผสมผสานระหว่าง command line flags และการตั้งค่าในฐานข้อมูลแบบเดิม วิธีการทดลองใช้งานอย่างรวดเร็วตามเอกสารมีดังนี้:

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

คำสั่งดังกล่าวจะให้บริการไฟล์ในไดเรกทอรีปัจจุบันที่พอร์ต http://localhost และการเข้าสู่ระบบครั้งแรกคือ admin / admin โปรดเปลี่ยนรหัสผ่านก่อนที่จะเปิดให้เข้าถึงคอนเทนเนอร์จากภายนอกเครื่องของคุณ

สำหรับการใช้งานจริง ให้ใช้ Compose โดยทำการ mount ไดเรกทอรี ข้อมูลแทนการ 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 MB โดยรวม FFmpeg มาให้สำหรับสร้างภาพตัวอย่างวิดีโอ และอิมเมจ stable-slim ซึ่งมีขนาดประมาณ 15 MB ที่มีเฉพาะฟังก์ชันหลัก ข้อมูลเหล่านี้เป็นตัวเลขจากหน้าติดตั้งในเดือนสิงหาคม 2026 โปรดระบุ tag ที่คุณเลือกให้ชัดเจน เพราะ latest อาจมีการเปลี่ยนแปลงโดยไม่แจ้งให้ทราบล่วงหน้า และการที่โปรแกรมจัดการไฟล์เปลี่ยนรูปแบบการตั้งค่าในขณะที่คอนเทนเนอร์กำลังทำงานอยู่อาจทำให้เกิดปัญหาใหญ่ได้

สำหรับงานนี้ ถือเป็นเครื่องมือขนาดเล็กที่มีประสิทธิภาพสูงสุด โดยสามารถให้บริการจากแหล่งข้อมูลหลายแห่งด้วยกฎการรวม (include) และการยกเว้น (exclude) ทำให้หนึ่งอินสแตนซ์สามารถเปิดเผย /srv/media และ /srv/docs ด้วยขอบเขตที่แตกต่างกันได้ การแชร์ไฟล์สามารถกำหนดเวลาหมดอายุ และสามารถตั้งค่าให้เป็นแบบสาธารณะหรือจำกัดเฉพาะผู้ใช้ได้ ระบบยืนยันตัวตนรองรับ OIDC (OpenID Connect), LDAP (lightweight directory access protocol), รหัสผ่านพร้อมการยืนยันตัวตนสองชั้น (2FA) และโหมด proxy header ซึ่งโหมด proxy นี้เองที่ช่วยให้สามารถวางระบบไว้หลัง single sign on (SSO) จาก เซิร์ฟเวอร์ Authentik ที่โฮสต์เอง แทนการต้องดูแลรายชื่อผู้ใช้แยกอีกชุดหนึ่ง

Filestash: อินเทอร์เฟซเดียวสำหรับจัดการพื้นที่จัดเก็บข้อมูลที่คุณมีอยู่แล้ว

Filestash มีรูปแบบการทำงานที่แตกต่างออกไป โดยเป็นส่วนหน้า (front end) ที่เชื่อมต่อกับส่วนหลัง (backend) ซึ่งรองรับโปรโตคอลจำนวนมาก ได้แก่ FTP, SFTP (SSH file transfer protocol), 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 password) โปรดตั้งรหัสผ่านทันที เพราะหากยังไม่ได้ตั้ง คอนโซลผู้ดูแลระบบจะเปิดกว้างสำหรับทุกคนที่เข้าถึงพอร์ตดังกล่าวได้

โปรดทำความเข้าใจรูปแบบการระบุตัวตนก่อนเริ่มใช้งาน Filestash ไม่ได้เก็บฐานข้อมูลผู้ใช้ในรูปแบบทั่วไป ข้อมูลประจำตัวจะถูกเก็บไว้ในเบราว์เซอร์ของคุณผ่านคุกกี้ที่เข้ารหัส รับรองความถูกต้อง และเป็นแบบ HTTP only โดยไม่มีข้อมูลใดถูกเก็บไว้ที่ฝั่งเซิร์ฟเวอร์ เว้นแต่คุณจะใช้ฟีเจอร์การแชร์ ซึ่งในกรณีนั้น Filestash จะเก็บข้อมูลประจำตัวของคุณในรูปแบบที่เข้ารหัสแบบถาวร "ผู้ใช้" ในที่นี้คือบัญชีพื้นที่จัดเก็บข้อมูล โดยตัวตนจะอยู่ที่ฝั่ง backend เช่น ในบัญชี SFTP หรือคีย์ S3 ไม่ใช่ใน Filestash

การออกแบบนี้มีความเรียบง่ายแต่มีค่าใช้จ่าย หน้าเพจราคาแสดงให้เห็นว่าระดับการใช้งานแบบ self-hosted ฟรีนั้นเป็นสัญญาอนุญาตแบบ AGPL v3 (GNU Affero General Public License) โดยจำกัดผู้ใช้สูงสุด 3 ราย และการใช้งาน SSO (SAML, OIDC และ LDAP) พร้อมระบบควบคุมการเข้าถึงตามบทบาท (role based access control) จะอยู่ในระดับการใช้งานแบบ 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 repository และคีย์สำหรับยืนยันความถูกต้องได้ที่หน้าการติดตั้งในเอกสารประกอบของ SFTPGo การใช้งานผ่านคอนเทนเนอร์เป็นวิธีที่รวดเร็วที่สุดในการเริ่มใช้งาน โดยให้แทนที่ tag ด้วยเวอร์ชันที่คุณต้องการ:

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

SFTP จะฟังคำสั่งที่พอร์ต 2022 และอินเทอร์เฟซเว็บจะอยู่ที่พอร์ต 8080 คุณต้อง mount /srv/sftpgo เป็น volume มิฉะนั้นบัญชีผู้ใช้และไฟล์ต่างๆ จะหายไปเมื่อคอนเทนเนอร์ถูกสร้างใหม่ เนื่องจากไดเรกทอรีหลักของผู้ใช้ (home directory) จะถูกตั้งค่าเริ่มต้นไว้ที่ /srv/sftpgo/data/<username>

อินเทอร์เฟซเว็บมีอยู่สองส่วน ซึ่งความแตกต่างของทั้งสองส่วนนี้เป็นสิ่งที่บทความส่วนใหญ่มักไม่ได้อธิบายไว้อย่างชัดเจน WebAdmin ที่ /web/admin มีไว้สำหรับการดูแลระบบ ซึ่งเป็นจุดที่คุณใช้สร้างผู้ใช้, กลุ่ม, โฟลเดอร์เสมือน (virtual folder) และกฎของเหตุการณ์ รวมถึงตั้งค่าโควตา, ขีดจำกัดแบนด์วิดท์ และข้อจำกัดด้านเวลาในการเข้าถึง ส่วน WebClient ที่ /web/client เป็นมุมมองสำหรับผู้ใช้งานทั่วไป ซึ่งเป็นจุดที่ผู้ใช้สามารถเรียกดูไฟล์, เปลี่ยนข้อมูลประจำตัวของตนเอง, ตั้งค่าการยืนยันตัวตนแบบสองชั้น (2FA) และสร้างลิงก์แชร์ไฟล์

ลิงก์แชร์เหล่านี้ถือว่าดีที่สุดในการเปรียบเทียบนี้ ผู้ใช้สามารถสร้างลิงก์ HTTP/S เพื่อแชร์ไฟล์และโฟลเดอร์, จำกัดจำนวนครั้งในการดาวน์โหลดและอัปโหลด, ป้องกันการแชร์ด้วยรหัสผ่าน, จำกัดการเข้าถึงตาม IP address ต้นทาง และตั้งค่าวันหมดอายุอัตโนมัติได้

เหตุใดจึงต้องระมัดระวัง? จุดเน้นหลักของซอฟต์แวร์นี้อยู่ที่รูปแบบบัญชีผู้ใช้และเซิร์ฟเวอร์โปรโตคอล ไม่ใช่ประสบการณ์ในการเรียกดูไฟล์ เลือกใช้ SFTPGo เมื่อผู้อื่นต้องการบัญชีผู้ใช้จริงที่มีการกำหนดโควตา, เมื่อมีการอัปโหลดผ่าน SFTP หรือ FTPS จากระบบที่คุณไม่ได้เป็นผู้ควบคุม หรือเมื่อต้องการให้ bucket เดียวปรากฏอยู่ในไดเรกทอรีหลักของผู้ใช้หลายคน โฟลเดอร์เสมือนสามารถทำหน้าที่ดังกล่าวได้ โดยเป็นการนำโฟลเดอร์ที่เก็บข้อมูลบนดิสก์ในเครื่อง, S3, GCS, Azure Blob, SFTP หรือ HTTP มา mount เข้ากับบัญชีผู้ใช้หลายบัญชี พร้อมทั้งกำหนดโควตาแยกกันต่อผู้ใช้หนึ่งรายในโฟลเดอร์ที่แชร์ร่วมกัน หากสิ่งที่คุณต้องการมีเพียงหน้าเว็บสำหรับเรียกดูไฟล์ผ่าน /srv/files ซอฟต์แวร์นี้อาจถือว่ามีกลไกที่ซับซ้อนเกินความจำเป็น

มีอีกสองข้อเท็จจริงที่ควรทราบ: รุ่น Community เป็นลิขสิทธิ์แบบ AGPL-3.0 พร้อมเงื่อนไขเพิ่มเติม ควบคู่ไปกับรุ่น Enterprise ที่มีลิขสิทธิ์เชิงพาณิชย์ การล็อกอินผ่าน OIDC มีอยู่ในรุ่นโอเพนซอร์ส ซึ่งสามารถจับคู่ผู้ใช้จาก Identity Provider เข้ากับผู้ดูแลระบบและผู้ใช้ของ SFTPGo ได้ทั้งสองอินเทอร์เฟซ นอกจากนี้ คุณยังสามารถปิดอินเทอร์เฟซสำหรับผู้ใช้ได้ทั่วทั้งระบบด้วยการตั้งค่า enable_web_client ในไฟล์คอนฟิกูเรชัน httpd หรือปิดเป็นรายบุคคลโดยเพิ่ม HTTP เข้าไปในรายการโปรโตคอลที่ถูกปฏิเสธของผู้ใช้รายนั้น เพื่อให้ตัวจัดการไฟล์ใช้งานได้เฉพาะบางคนเท่านั้น ไม่ใช่ทุกคน

Cloud Commander: สองบานหน้าต่างและเทอร์มินัล สำหรับผู้ใช้งานคนเดียว

Cloud Commander เป็นตัวจัดการไฟล์ที่ใช้ Node.js ภายใต้สัญญาอนุญาต MIT ในรูปแบบสองบานหน้าต่าง พร้อมด้วยโปรแกรมแก้ไขข้อความ คอนโซล และเทอร์มินัลในตัว ติดตั้งแบบ global ด้วย npm i cloudcmd -g หรือรัน container ที่เผยแพร่ไว้ดังนี้:

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

โปรดอ่านคำสั่งดังกล่าวก่อนดำเนินการ -v /:/mnt/fs จะทำการ mount ระบบไฟล์ทั้งหมดของโฮสต์เข้าไปใน container และตัวอย่าง ~/.cloudcmd.json จะส่ง "root": "/", "auth": false และ "console": true มาด้วย การตั้งค่าเช่นนี้หมายความว่าใครก็ตามที่เข้าถึงพอร์ต 8000 จะสามารถเข้าถึงดิสก์ทั้งหมดและคอนโซลคำสั่งบนเซิร์ฟเวอร์ของคุณได้ ซึ่งเป็นการตั้งค่าเริ่มต้นที่เหมาะสมสำหรับแล็ปท็อป แต่เป็นตัวเลือกที่ไม่ดีสำหรับ VPS

จำกัดขอบเขตการเข้าถึงให้แคบลง Container จะอ่านค่าจาก /root/.cloudcmd.json ซึ่งคำสั่งที่เผยแพร่ไว้จะ mount ไดเรกทอรี home ของคุณเข้าไป ดังนั้นให้คงการ mount ไฟล์ config ไว้และตัดส่วนที่เหลือออก:

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 นั้น ให้ตั้งค่า "root" เป็น /srv/files, ตั้งค่า "auth" เป็น true โดยใช้ "username" และ "password" และตั้งค่า "console" และ "terminal" เป็น false เว้นแต่คุณต้องการสิทธิ์การเข้าถึง shell ผ่านเบราว์เซอร์จริงๆ นอกจากนี้ยังมีคำสั่งเทียบเท่าในบรรทัดคำสั่งให้ใช้งาน รวมถึง --root, --auth, --username, --password และ --prefix

จงตระหนักถึงลักษณะการทำงานของเครื่องมือนี้ ระบบรองรับข้อมูลรับรองเพียงชุดเดียว ไม่มีขอบเขตการเข้าถึงแยกตามผู้ใช้ ไม่มีโควตา และไม่มีลิงก์สำหรับแชร์ นี่เป็นเครื่องมือสำหรับใช้งานส่วนตัว ดังนั้นให้ bind ไว้ที่ localhost ตามที่ระบุข้างต้นและเข้าถึงผ่าน tunnel:

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

จากนั้นเปิด http://127.0.0.1:8000 บนเครื่องของคุณ ตัวจัดการไฟล์จะไม่ถูกเปิดเผยต่อสาธารณะ และสิ่งเดียวที่หันหน้าเข้าสู่อินเทอร์เน็ตคือ SSH daemon ที่คุณได้ เสริมความปลอดภัยบน VPS ของคุณ ไว้แล้ว

เหตุผลที่ Nextcloud ไม่ใช่เครื่องมือที่เหมาะสมสำหรับงานนี้

Nextcloud เป็นซอฟต์แวร์ที่ดี แต่ไม่ใช่สำหรับงานนี้ มันเป็นแพลตฟอร์มสำหรับการทำงานร่วมกัน ซึ่งประกอบด้วยแอปพลิเคชัน PHP, ฐานข้อมูล, งานเบื้องหลัง (background jobs), ไคลเอนต์สำหรับซิงค์ข้อมูลบนเดสก์ท็อป และแอปสโตร์ การรัน Nextcloud เพียงเพื่อต้องการดูไฟล์ผ่านเว็บของ /srv/files นั้นถือว่ามีส่วนประกอบที่ซับซ้อนเกินความจำเป็นสำหรับงานเล็กๆ และมีความไม่สอดคล้องกันในเชิงเทคนิค Nextcloud เก็บข้อมูล metadata ของไฟล์ไว้ในตารางฐานข้อมูลแทนที่จะอ่านจากไดเรกทอรีโดยตรงในทุกคำขอ ดังนั้นไฟล์ที่ถูกเขียนผ่าน rsync หรือ cron job อาจไม่ปรากฏในหน้าเว็บจนกว่าระบบจะทำการสแกนไฟล์ใหม่ด้วย sudo -u www-data php occ files:scan --all ในขณะที่โปรแกรมจัดการไฟล์ (file manager) จะแสดงรายการไฟล์จากไดเรกทอรีทันทีที่คุณโหลดหน้าเว็บ ทำให้ไม่มีปัญหาเรื่องความล่าช้าของข้อมูล

ควรใช้ Nextcloud สำหรับงานที่มันทำได้ดี เช่น ปฏิทิน, รายชื่อผู้ติดต่อ, การซิงค์ข้อมูล และการแชร์ไฟล์กับผู้ใช้ที่ต้องการไคลเอนต์บนเดสก์ท็อป บทความ Nextcloud บน VPS ด้วย Docker, TLS และการสำรองข้อมูล ได้อธิบายการตั้งค่าดังกล่าวไว้แล้ว หากคุณใช้งาน Nextcloud อยู่แล้วและเพียงแค่ต้องการดูไฟล์ในไดเรกทอรีที่มีอยู่ ให้เปิดใช้งานแอป External Storage ก็เพียงพอแล้ว การติดตั้งเว็บแอปพลิเคชันตัวที่สองที่สามารถเขียนข้อมูลลงในดิสก์เดียวกันได้ จะทำให้คุณต้องคอยดูแลแพตช์ความปลอดภัยเพิ่มขึ้นอีกหนึ่งรายการ

วิธีรันแอปพลิเคชันโดยไม่เปิดเผยสิทธิ์เข้าถึงทั้งเซิร์ฟเวอร์

ห้ามชี้ตำแหน่งไปยัง / โดยเด็ดขาด กระบวนการทำงานสามารถอ่านและเขียนไฟล์ทุกอย่างที่บัญชีผู้ใช้นั้นเข้าถึงได้ ดังนั้นหาก session token ถูกขโมยไป ผู้บุกรุกจะได้รับสิทธิ์เข้าถึงระบบไฟล์ในระดับเดียวกับบัญชีนั้น ให้บริการเฉพาะไดเรกทอรีที่กำหนดไว้ที่ /srv/files และสร้างไดเรกทอรีนั้นขึ้นมาเพื่อการนี้โดยเฉพาะ

ให้รันด้วยผู้ใช้ที่ไม่ใช่ root และ mount เฉพาะสิ่งที่จำเป็นต้องใช้เท่านั้น ใน Docker 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 นี่คือปัญหาเรื่องความเป็นเจ้าของไฟล์แบบเดียวกับที่ PUID และ PGID ใน Docker images มีไว้เพื่อแก้ไข

ให้ bind พอร์ตที่เปิดใช้งานไว้กับ localhost ที่ 127.0.0.1:8080:80 แทนที่จะเป็น 8080:80 เนื่องจาก Docker จะเขียนกฎ netfilter ของตนเองก่อนกฎของ ufw ดังนั้นพอร์ตที่เปิดใช้งานแบบปกติจะยังคงเข้าถึงได้จากอินเทอร์เน็ตแม้ว่า ufw deny 8080 จะเปิดใช้งานอยู่ก็ตาม ให้วาง reverse proxy ไว้ด้านหน้าเพื่อจัดการ TLS หากใช้งานผ่าน HTTP ปกติ session cookie จะถูกส่งผ่านเครือข่ายโดยไม่มีการเข้ารหัส และ cookie นั้นก็คือสิทธิ์ในการเข้าถึงระบบไฟล์ หากคุณยังใหม่กับ Compose สามารถดู Docker Compose บน VPS ซึ่งครอบคลุมโครงสร้างไฟล์ที่ตัวอย่างเหล่านี้อ้างอิงถึง

เพิ่มชั้นการยืนยันตัวตนเมื่อแอปพลิเคชันมีระบบความปลอดภัยไม่เพียงพอ การใช้ HTTP basic auth ที่ตัว proxy ก็เพียงพอสำหรับการใช้งานคนเดียว แต่เมื่อมีผู้ใช้มากกว่าหนึ่งคน ให้ใช้ OIDC หรือ forward auth ร่วมกับ identity provider เพื่อให้การเพิกถอนบัญชีเดียวสามารถตัดสิทธิ์การเข้าถึงได้ทั้งหมด

ปิดฟีเจอร์ที่ไม่จำเป็น โปรแกรมจัดการไฟล์ใดก็ตามที่มี shell, ตัวรันคำสั่ง หรือ terminal ในเบราว์เซอร์ ถือเป็นการเปิดช่องทาง remote code execution ให้กับใครก็ตามที่มี session ที่ถูกต้อง คำแนะนำของ FileBrowser คือให้ปิดการใช้งานตัวรันคำสั่ง ส่วนตัวอย่าง config ของ Cloud Commander มักจะเปิดใช้งาน console ไว้ ให้ตัดสินใจเลือกตามวัตถุประสงค์การใช้งานแทนที่จะใช้ค่าเริ่มต้นของโปรแกรม

สิ่งที่มักจะพังก่อนและข้อผิดพลาดที่คุณจะพบ

listen tcp :80: bind: permission denied. Linux สงวนพอร์ตที่ต่ำกว่า 1024 ไว้สำหรับกระบวนการที่มีสิทธิ์ระดับสูง (privileged processes) การตั้งค่าตามเอกสารของ FileBrowser Quantum ใช้พอร์ต 80 ซึ่งใช้งานได้ปกติภายในคอนเทนเนอร์ แต่จะล้มเหลวทันทีหากคุณรันไฟล์ binary ในฐานะผู้ใช้ทั่วไปบนโฮสต์ ให้ตั้งค่าพอร์ตที่สูงกว่า 1024 ใน config.yaml และปล่อยให้ proxy เป็นผู้ดูแลพอร์ต 443 แทน

อัปโหลดไม่สำเร็จในขณะที่การเรียกดูไฟล์ทำงานได้ปกติ. การแสดงรายการไดเรกทอรีต้องใช้สิทธิ์ r-x ส่วนการเขียนไฟล์ลงในไดเรกทอรีต้องใช้สิทธิ์ w อินเทอร์เฟซบนเว็บจะรายงานข้อผิดพลาดทั่วไป ดังนั้นให้ตรวจสอบระบบไฟล์ก่อนที่จะไปดู log ของแอปพลิเคชัน

413 Request Entity Too Large. ข้อผิดพลาดนั้นมาจาก Nginx ไม่ใช่จากตัวจัดการไฟล์ ค่าเริ่มต้นของ client_max_body_size คือ 1 MB ดังนั้นการอัปโหลดไฟล์ที่มีขนาดใหญ่กว่าจะถูกปฏิเสธที่ proxy ก่อนที่แอปพลิเคชันจะได้รับคำขอเสียอีก ให้ตั้งค่า client_max_body_size 4096m; ในบล็อก server หรือตั้งค่าเป็น 0 เพื่อปิดการตรวจสอบนี้

ไฟล์ที่อัปโหลดมีกลุ่ม (group) ไม่ถูกต้อง. ไฟล์ใหม่จะเป็นกรรมสิทธิ์ของผู้ใช้ที่รันกระบวนการนั้น ไม่ว่าไดเรกทอรีโดยรอบจะมีสิทธิ์อย่างไร ซึ่งจะทำให้บริการที่สองที่อ่านข้อมูลในโครงสร้างเดียวกันทำงานไม่ได้ ให้กำหนดกลุ่มที่ใช้ร่วมกันให้กับทั้งสองบริการและตั้งค่า setgid bit บนไดเรกทอรีด้วยคำสั่ง sudo chmod g+s /srv/files เพื่อให้ไฟล์ใหม่สืบทอดกลุ่มของไดเรกทอรีนั้นมา

ทุกอย่างทำงานได้เมื่อเข้าผ่านพอร์ตโดยตรง แต่พังเมื่ออยู่หลัง proxy. แอปพลิเคชันที่ให้บริการภายใต้ subpath จะสร้างลิงก์โดยอ้างอิงจาก prefix ที่ต้องระบุให้แอปพลิเคชันทราบ Cloud Commander มีตัวเลือก --prefix สำหรับกรณีนี้ ในกรณีที่ไม่มีตัวเลือกดังกล่าว ให้กำหนด subdomain แยกต่างหากให้กับแอปพลิเคชันและทำ proxy ไปยัง root path แทน

คุณควรเลือกใช้โปรแกรมจัดการไฟล์แบบ self-hosted ตัวไหน?

• หากคุณมี VPS หนึ่งเครื่อง, มีไดเรกทอรีเพียงหนึ่งหรือสองแห่ง, ต้องการแชร์ลิงก์แบบกำหนดวันหมดอายุ และอาจต้องการรองรับ SSO ในอนาคต: ให้เลือก FileBrowser Quantum
• หากไฟล์ของคุณถูกจัดเก็บไว้ที่อื่น เช่น S3 bucket, SFTP host หรือ NAS ผ่านโปรโตคอล SMB และคุณต้องการหน้าเว็บเดียวที่รวมทุกอย่างเข้าด้วยกัน: ให้เลือก Filestash โดยใช้งานภายในขีดจำกัดของระดับบริการฟรี
• หากคุณต้องการให้ผู้อื่นมีบัญชีผู้ใช้, กำหนดโควตาพื้นที่ และรองรับการอัปโหลดผ่าน SFTP หรือ FTPS: ให้เลือก SFTPGo โดยมองว่าเว็บไคลเอนต์เป็นเพียงฟีเจอร์เสริมที่มีประโยชน์ ไม่ใช่เหตุผลหลักในการเลือกใช้งาน
• หากเป็นเครื่องมือส่วนตัวที่มีโปรแกรมแก้ไขข้อความและเทอร์มินัล โดยเข้าถึงผ่าน SSH tunnel และไม่เปิดเผยสู่สาธารณะ: ให้เลือก Cloud Commander
• หากคุณใช้งาน Nextcloud อยู่แล้วและมีไดเรกทอรีที่ต้องการเปิดใช้งาน: ให้ใช้แอป External Storage โดยไม่ต้องติดตั้งซอฟต์แวร์ใหม่เพิ่มเติม

ไม่ว่าคุณจะเลือกตัวเลือกใด การปรับใช้ (deployment) มีความสำคัญมากกว่าตัวซอฟต์แวร์เอง ควรตั้งค่าโดยใช้ไดเรกทอรีเดียว, ใช้ผู้ใช้ที่ไม่ใช่ root, ผูกพอร์ตไว้กับ localhost และมีการยืนยันตัวตนอยู่เบื้องหน้า โปรแกรมจัดการไฟล์ที่ตั้งค่าในลักษณะนี้จะเป็นเครื่องมือที่อำนวยความสะดวก แต่หากใช้ซอฟต์แวร์ตัวเดียวกันชี้ไปยัง / โดยใช้รหัสผ่านที่ใช้ร่วมกัน มันจะกลายเป็น remote shell ที่มีหน้าตาการใช้งานสวยงามเท่านั้น

FAQ

FileBrowser ยังปลอดภัยที่จะใช้งานในปี 2026 หรือไม่?

README ของ filebrowser/filebrowser ระบุว่า File Browser ถูกเก็บถาวร (archived) ตั้งแต่วันที่ 2026-09-01 โดยจะไม่มีการออก release, การแก้ไขบั๊ก หรือการแก้ไขช่องโหว่ด้านความปลอดภัยอีกต่อไป แม้ซอฟต์แวร์จะยังทำงานได้ แต่ซอฟต์แวร์ที่ไม่ได้รับการอัปเดตและมีสิทธิ์เขียนไฟล์ในระบบถือเป็นความเสี่ยงที่เพิ่มขึ้นตามกาลเวลา หากคุณยังคงใช้งานอยู่ ให้ปฏิบัติตามคำแนะนำของโครงการ: ห้ามเปิดใช้งานโดยตรงสู่สาธารณะ, ใช้ reverse proxy เพื่อทำ TLS และจัดการการยืนยันตัวตน, ปิดการใช้งาน command runner และรันใน container ที่ไม่มีสิทธิ์ (unprivileged) โดย mount เฉพาะไดเรกทอรีที่ต้องการใช้งานเท่านั้น โปรดทราบว่า session ของโปรแกรมเป็น JWT ที่ทำงานแยกส่วน ไม่ใช่ตัวระบุฝั่งเซิร์ฟเวอร์ ดังนั้นจึงไม่สามารถเพิกถอนได้ และการเปลี่ยนรหัสผ่านจะไม่ทำให้ token ที่ออกไปแล้วหมดอายุ สำหรับการติดตั้งใหม่ ให้ใช้ FileBrowser Quantum ซึ่งเป็น fork ที่เผยแพร่ในชื่อ image gtstef/filebrowser ซึ่งยังมีการพัฒนาอย่างต่อเนื่อง

โปรแกรมจัดการไฟล์แบบ self-hosted สามารถใช้ SSO ที่มีอยู่ได้หรือไม่?

FileBrowser Quantum รองรับ OIDC, LDAP และโหมด proxy header จึงสามารถวางไว้หลัง identity provider ที่มีอยู่ได้โดยไม่ต้องจัดการรายชื่อผู้ใช้ซ้ำ การรวมระบบ OpenID Connect ของ SFTPGo มีอยู่ในรุ่น open source ซึ่งจะแมปผู้ใช้จาก identity provider ไปยังผู้ดูแลระบบและผู้ใช้ของ SFTPGo ทั้งในอินเทอร์เฟซ WebAdmin และ WebClient สำหรับ Filestash มีข้อควรระวังคือ หน้าแสดงราคาของบริการระบุว่า SSO (SAML, OIDC และ LDAP) อยู่ในระดับการใช้งานแบบเสียค่าใช้จ่ายสำหรับ self-hosted เริ่มต้นที่ 50 ดอลลาร์ต่อเดือน ณ เดือนสิงหาคม 2026 ในขณะที่รุ่นฟรีระบุว่าเป็น AGPL v3 สำหรับผู้ใช้สูงสุด 3 คน หากแอปพลิเคชันไม่มีการรองรับ SSO วิธีสำรองคือการใช้ forward authentication ที่ reverse proxy ซึ่งจะช่วยป้องกันหน้าล็อกอิน แต่จะไม่ส่งผลต่อสิทธิ์การเข้าถึงภายในของแอปพลิเคชัน

โปรแกรมใดบ้างที่สามารถสร้างลิงก์แชร์แบบมีวันหมดอายุได้?

SFTPGo มีการใช้งานที่สมบูรณ์ที่สุด ผู้ใช้สามารถสร้างลิงก์ HTTP/S จาก WebClient และจำกัดจำนวนการดาวน์โหลดหรืออัปโหลด, ตั้งรหัสผ่าน, จำกัดการเข้าถึงตาม IP address ต้นทาง และตั้งวันหมดอายุอัตโนมัติได้ FileBrowser Quantum รองรับการแชร์แบบมีเวลาหมดอายุ โดยสามารถเลือกให้เข้าถึงแบบไม่ระบุตัวตนหรือจำกัดเฉพาะผู้ใช้ พร้อมกำหนดสิทธิ์การดู, แก้ไข และอัปโหลดต่อลิงก์ได้ Filestash ก็มีฟีเจอร์แชร์เช่นกัน และเป็นกรณีที่เซิร์ฟเวอร์จะเก็บสำเนาข้อมูลรับรองการจัดเก็บข้อมูลแบบเข้ารหัสไว้ เนื่องจากลิงก์ต้องทำงานได้แม้ในขณะที่ session ของเบราว์เซอร์ของคุณสิ้นสุดลงแล้ว ส่วน Cloud Commander ไม่มีฟีเจอร์ลิงก์แชร์

การชี้โปรแกรมจัดการไฟล์ไปที่ / ปลอดภัยหรือไม่หากฉันเป็นผู้ใช้เพียงคนเดียว?

ไม่ปลอดภัย และความเสี่ยงไม่ได้เกิดจากการที่คุณไม่ไว้ใจตัวเอง แต่กระบวนการของโปรแกรมจะถือสิทธิ์การอ่านและเขียนทุกอย่างที่บัญชีผู้ใช้ของโปรแกรมนั้นเข้าถึงได้ ดังนั้นหากมีช่องทางเข้าถึง session นั้นได้ ไม่ว่าจะเป็น cookie ที่ถูกขโมย, บั๊กในตัวจัดการการอัปโหลดที่ยังไม่ได้แก้ไข หรือการใช้รหัสผ่านซ้ำ จะกลายเป็นการเข้าถึง /etc, SSH keys ของคุณ และไดเรกทอรีข้อมูลของทุกบริการ ให้จำกัดขอบเขตการ mount ไว้ที่ไดเรกทอรีเดียวแทน เช่น /srv/files แทนที่จะเป็น / ปัญหานี้ส่งผลกระทบมากที่สุดกับ Cloud Commander เนื่องจากคำสั่ง Docker ที่เผยแพร่จะ mount root ของ host ไว้ที่ /mnt/fs และค่าคอนฟิกตัวอย่างจะตั้งค่า "root": "/" ไว้ที่ "auth": false ให้แก้ไขทั้งสองค่าก่อนที่จะอนุญาตให้ container นั้นรับการเชื่อมต่อจากที่อื่นที่ไม่ใช่ localhost