셀프 호스팅 파일 관리자 추천 및 비교 (FileBrowser 등)

셀프 호스팅 파일 관리자의 정의와 역할

셀프 호스팅 파일 관리자는 VPS(가상 사설 서버)에 이미 존재하는 디렉터리 트리를 웹 페이지로 보여주는 도구입니다. 로그인하면 디스크에 저장된 상태 그대로 /srv/files를 확인할 수 있으며, 파일 업로드, 이름 변경, 다운로드 또는 타인에게 링크 공유가 가능합니다. 별도의 시스템으로 파일을 복사하지 않으므로, 브라우저에 파일을 올리면 1초 뒤 ls에서도 즉시 확인할 수 있습니다.

검색 결과에서는 이와 다른 기능을 수행하는 소프트웨어가 혼용되기도 합니다. 동기화 도구는 모든 기기에 파일 사본을 유지하며, 이는 셀프 호스팅 Dropbox 대안이 담당하는 영역입니다. 객체 스토리지는 디렉터리 트리 구조가 아닌 버킷과 API를 사용하므로, S3 호환 객체 스토리지를 위한 MinIO 운영은 다른 목적의 해결책입니다. 서버 관리 패널은 파일이 아닌 시스템 자체를 관리하며, 이는 Cockpit과 Webmin 비교에서 다룹니다.

파일 관리자가 필요한 경우는 동료에게 서버에 있는 300 MB 아카이브 파일을 전달해야 하거나, 스마트폰으로 설정 파일의 오타를 수정해야 할 때입니다. 작업 범위가 작고 도구 또한 가볍습니다.

이 글을 읽는 동안 한 가지 사실을 명심하십시오. 이는 파일 시스템에 대한 읽기 및 쓰기 권한을 가지고 특정 포트에서 대기하는 웹 애플리케이션입니다. 아래에서 선택하는 모든 도구는 결국 해당 프로세스가 디스크의 어느 범위까지 접근할 수 있는지를 결정하는 과정입니다.

FileBrowser는 아카이브되었으므로 설치 전 이 내용을 읽어보십시오

FileBrowser는 filebrowser/filebrowser 프로젝트로, 여전히 많은 가이드에서 추천하는 도구입니다. 하지만 현재 README는 다음과 같은 공지로 시작합니다.

File Browser는 2026-09-01부로 아카이브되었습니다. 마지막으로 계획된 릴리스는 이미 배포되었습니다. 향후 추가적인 릴리스, 버그 수정, 보안 패치는 제공되지 않습니다.

Apache 2.0 코드는 계속 작동하지만 보안 수정은 중단됩니다. 이 소프트웨어의 목적 자체가 HTTP를 통해 파일 시스템에 쓰기 권한을 제공하는 것이므로, 다른 분야보다 이 점이 훨씬 중요합니다.

유지보수 관리자는 계속 운영하는 방법을 명시했으며, 어떤 도구를 선택하든 다음 조언을 따르는 것이 좋습니다. 인터넷에 직접 노출하지 말고, TLS(Transport Layer Security)를 종료하고 자체 인증을 수행하는 리버스 프록시 뒤에 배치하십시오. 또한 명령 실행 기능을 비활성화하고, 서비스할 디렉터리만 마운트한 컨테이너에서 권한 없이 실행하십시오.

README의 한 문장이 무엇보다 중요합니다. 세션은 서버 측 식별자가 아닌 독립적인 JWT(JSON web tokens)이므로 취소할 수 없습니다. 유출된 세션 토큰은 만료될 때까지 유효하며, 비밀번호를 변경해도 세션은 종료되지 않습니다. 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를 사용하고, 단일 데이터베이스 파일이 아닌 데이터 디렉터리를 마운트하며, 포트를 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 버전부터 데이터베이스 형식이 변경되어 1회성 마이그레이션이 수행되므로, 문서에서는 디렉터리 마운트를 권장합니다. 단일 파일만 마운트하면 마이그레이션 과정에서 새 파일을 생성할 공간이 없기 때문입니다. config.yaml 내부의 경로는 컨테이너 내부 경로이므로, 설정 파일의 소스 경로는 /srv/files이 아닌 /folder으로 지정해야 합니다. 이를 반대로 설정하면 디렉터리가 실제로 존재하지 않음에도 오류 없이 빈 파일 목록만 표시됩니다.

이 프로젝트는 비디오 썸네일 생성을 위한 FFmpeg가 포함된 약 60 MB 크기의 latest 및 stable 이미지와, 핵심 기능만 포함된 약 15 MB 크기의 stable-slim 이미지를 배포합니다. 이는 2026년 8월 기준 설치 페이지의 수치입니다. 선택한 태그를 고정하십시오. latest는 예고 없이 변경될 수 있으며, 실행 중인 컨테이너에서 설정 형식이 바뀌는 파일 관리자는 운영에 큰 차질을 줄 수 있습니다.

이 작업에 있어 FileBrowser는 소형 도구 중 가장 강력한 성능을 제공합니다. 포함 및 제외 규칙을 통해 여러 소스를 서비스할 수 있으므로, 하나의 인스턴스로 /srv/media과 /srv/docs을 서로 다른 범위로 노출할 수 있습니다. 공유 기능에는 만료 시간을 설정할 수 있으며, 익명 공유 또는 특정 사용자 제한 공유가 가능합니다. 인증은 OIDC(OpenID Connect), LDAP(Lightweight Directory Access Protocol), 2단계 인증을 포함한 비밀번호 방식, 그리고 프록시 헤더 모드를 지원합니다. 프록시 모드를 사용하면 별도의 사용자 목록을 관리할 필요 없이 자체 호스팅된 Authentik 서버의 SSO(Single Sign-On) 뒤에 배치할 수 있습니다.

Filestash: 기존 스토리지 위에 구축하는 단일 인터페이스

Filestash는 기존과는 다른 형태를 띱니다. 이는 백엔드에 연결되는 프론트엔드이며, 지원하는 백엔드 목록은 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를 열면 첫 화면에서 관리자 비밀번호를 설정하게 됩니다. 이 포트를 발견한 누구라도 관리자 콘솔에 접근할 수 있으므로 즉시 설정하십시오.

구축하기 전에 식별 모델을 이해해야 합니다. Filestash는 일반적인 의미의 사용자 데이터베이스를 유지하지 않습니다. 자격 증명은 암호화되고 인증된 HTTP 전용 쿠키를 통해 브라우저에 저장됩니다. 공유 기능을 사용하지 않는 한 서버 측에는 아무것도 저장되지 않으며, 공유 기능을 사용할 경우에만 Filestash가 자격 증명의 영구적인 암호화 버전을 보관합니다. 여기서 "사용자"란 스토리지 계정을 의미합니다. 즉, 식별 정보는 Filestash 내부가 아니라 SFTP 계정이나 S3 키와 같은 백엔드에 존재합니다.

이러한 설계는 깔끔하지만 비용이 발생합니다. 가격 페이지에 따르면, 무료 셀프 호스팅 티어는 AGPL v3(GNU Affero General Public License) 라이선스를 따르며 최대 3명의 사용자까지 지원합니다. SSO(SAML, OIDC, LDAP) 및 역할 기반 접근 제어(RBAC) 기능은 2026년 8월 기준으로 월 50달러부터 시작하는 유료 셀프 호스팅 티어에서 제공됩니다. "기업용 SSO 앞에 Filestash를 무료로 배치"하려는 계획이라면, 설계를 시작하기 전에 해당 페이지를 먼저 확인하십시오.

SFTPGo: 웹 인터페이스를 포함한 프로토콜 서버

SFTPGo는 이 비교군에서 가장 뛰어난 기능을 갖춘 소프트웨어이며, 동시에 잘못된 이유로 가장 많이 추천되는 도구이기도 합니다. 이 소프트웨어는 로컬 파일 시스템, 암호화된 로컬 파일 시스템, S3 호환 객체 스토리지, Google Cloud Storage, Azure Blob Storage 또는 다른 SFTP 서버를 기반으로 SFTP, HTTP/S, FTP/S 및 WebDAV 서비스를 제공합니다.

바이너리, 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을 볼륨으로 마운트하지 않으면 컨테이너가 재생성될 때 계정과 파일이 모두 사라집니다. 사용자 홈 디렉터리의 기본값은 /srv/sftpgo/data/<username>이기 때문입니다.

웹 인터페이스는 두 가지가 있으며, 그 차이점은 대부분의 설명서에서 암묵적으로 다루는 부분입니다. /web/admin에 위치한 WebAdmin은 관리용 인터페이스로, 사용자, 그룹, 가상 폴더, 이벤트 규칙을 생성하고 할당량, 대역폭 제한, 접근 시간 제한을 설정하는 곳입니다. /web/client에 위치한 WebClient는 최종 사용자용 뷰로, 사용자가 파일을 탐색하고, 자신의 자격 증명을 변경하며, 2단계 인증을 설정하고, 공유를 생성하는 곳입니다.

이러한 공유 기능은 본 비교군에서 가장 우수합니다. 사용자는 HTTP/S 링크를 생성하여 파일과 폴더를 공유할 수 있으며, 다운로드 및 업로드 횟수 제한, 비밀번호를 통한 공유 보호, 소스 IP 주소별 접근 제한, 자동 만료 날짜 설정이 가능합니다.

그렇다면 왜 주의가 필요할까요? 이 도구의 핵심은 브라우징 경험이 아니라 계정 모델과 프로토콜 서버에 있기 때문입니다. 다른 사람들이 할당량이 포함된 실제 계정을 필요로 하거나, 제어할 수 없는 시스템에서 SFTP나 FTPS를 통해 업로드가 들어오거나, 하나의 버킷을 여러 사용자의 홈 디렉터리에 노출해야 할 때 SFTPGo를 선택하십시오. 가상 폴더 기능이 마지막 요구사항을 해결해 줍니다. 로컬 디스크, S3, GCS, Azure Blob, SFTP 또는 HTTP를 기반으로 하는 폴더를 여러 계정에 마운트할 수 있으며, 공유 폴더 내에서 사용자별로 별도의 할당량을 지정할 수 있습니다. 만약 단순히 /srv/files를 통해 파일을 탐색할 수 있는 페이지만 필요하다면, 이는 지나치게 거대한 시스템입니다.

알아두어야 할 두 가지 사실이 더 있습니다. 커뮤니티 에디션은 추가 조항이 포함된 AGPL-3.0 라이선스를 따르며, 상용 라이선스가 적용되는 엔터프라이즈 에디션도 존재합니다. OIDC 로그인은 오픈 소스 빌드에 포함되어 있으며, ID 공급자의 사용자를 SFTPGo의 관리자 및 사용자로 매핑하여 두 웹 인터페이스 모두에서 사용할 수 있게 합니다. 또한 httpd 설정 파일에서 enable_web_client을 사용하여 클라이언트 인터페이스를 전역적으로 비활성화하거나, 특정 사용자의 거부된 프로토콜에 HTTP을 추가하여 개별적으로 비활성화할 수 있습니다. 이를 통해 특정 사용자에게만 파일 관리자 기능을 제공하거나 제한할 수 있습니다.

Cloud Commander: 2개의 창과 터미널, 개인용 도구

Cloud Commander는 MIT 라이선스를 따르는 Node.js 기반의 2개 창 스타일 파일 관리자로, 내장 에디터와 콘솔, 터미널을 제공합니다. 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"을 true("username" 및 "password" 포함)로 설정하십시오. 브라우저를 통한 셸 접근이 반드시 필요한 경우가 아니라면 "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을 여십시오. 파일 관리자는 외부에 공개되지 않으며, 인터넷에 노출되는 유일한 접점은 이미 VPS에서 보안을 강화한 SSH 데몬뿐입니다.

왜 Nextcloud가 이 작업에 적합하지 않은 도구인가

Nextcloud는 훌륭한 소프트웨어이지만, 이 작업에는 맞지 않습니다. Nextcloud는 협업 플랫폼으로, PHP 애플리케이션, 데이터베이스, 백그라운드 작업, 데스크톱 동기화 클라이언트, 앱 스토어로 구성되어 있습니다. 단순히 /srv/files의 웹 뷰를 보기 위해 이를 실행하는 것은 작은 작업에 비해 너무 많은 구성 요소를 포함하며, 근본적인 불일치가 존재합니다. Nextcloud는 요청이 있을 때마다 디렉터리를 읽는 대신 파일 메타데이터를 데이터베이스 테이블에 보관합니다. 따라서 rsync나 cron 작업으로 작성된 파일은 sudo -u www-data php occ files:scan --all를 통해 스캔이 완료될 때까지 인터페이스에서 보이지 않을 수 있습니다. 반면 파일 관리자는 페이지를 로드할 때마다 디렉터리 목록을 나열하므로 이러한 간극이 발생하지 않습니다.

Nextcloud는 본연의 기능인 캘린더, 연락처, 데스크톱 클라이언트를 사용하는 사람들과의 동기화 및 공유 용도로만 사용하십시오. Docker, TLS, 백업을 사용하는 VPS에서의 Nextcloud에서 해당 설정을 다룹니다. 이미 Nextcloud를 운영 중이고 기존 디렉터리만 확인하면 된다면, External Storage 앱을 활성화하는 선에서 마무리하십시오. 동일한 디스크에 쓰기 권한을 가진 두 번째 웹 애플리케이션을 추가하는 것은 보안 패치 대상만 늘리는 결과를 초래합니다.

전체 서버 권한을 노출하지 않고 실행하는 방법

절대로 /을(를) 가리키지 마십시오. 프로세스는 해당 사용자 계정이 접근할 수 있는 모든 파일을 읽고 쓸 수 있으므로, 세션 토큰이 탈취되면 그만큼의 파일 시스템 접근 권한이 넘어갑니다. 오직 하나의 디렉터리인 /srv/files만 서비스하고, 이 목적을 위해 해당 디렉터리를 새로 생성하십시오.

root가 아닌 사용자로 실행하고 서비스할 디렉터리만 마운트하십시오. Compose에서는 user: "1000:1000"와 함께 디렉터리당 하나의 bind mount를 사용하며, 쓰기 권한이 필요 없는 모든 항목에는 :ro을(를) 설정하십시오.

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

이 변경 후 브라우징은 정상 작동하지만 업로드는 permission denied 오류로 실패하는 경우가 많습니다. 컨테이너 내부의 사용자 ID가 외부 디렉터리의 소유자가 아니기 때문입니다. 두 값을 비교하십시오. docker exec filebrowser id은(는) 컨테이너 사용자를 출력하고, ls -ln /srv/files는(는) 호스트의 숫자 형태 소유자를 출력합니다. sudo chown -R 1000:1000 /srv/files을(를) 사용하여 수정하십시오. 이는 Docker 이미지의 PUID 및 PGID가 해결하고자 하는 것과 동일한 소유권 문제입니다.

공개 포트는 8080:80 대신 localhost인 127.0.0.1:8080:80에 바인딩하십시오. Docker는 ufw보다 앞서 자체 netfilter 규칙을 작성하므로, 단순히 포트를 공개하면 ufw deny 8080이(가) 활성화되어 있어도 인터넷에서 접근할 수 있습니다. TLS를 위해 앞에 리버스 프록시를 두십시오. 일반 HTTP를 사용하면 세션 쿠키가 네트워크를 통해 평문으로 전송되며, 해당 쿠키는 곧 파일 시스템 접근 권한과 같습니다. Compose 자체가 생소하다면 VPS에서의 Docker Compose에서 이 코드 조각들이 가정하는 파일 구조를 확인하십시오.

애플리케이션 자체 인증이 취약하다면 인증 계층을 추가하십시오. 단일 사용자 인스턴스라면 프록시에서의 HTTP basic auth만으로도 충분합니다. 사용자가 한 명 이상이라면 OIDC나 ID 공급자를 통한 forward auth를 사용하여, 계정 하나를 해지했을 때 모든 곳의 접근 권한이 즉시 회수되도록 하십시오.

부가 기능을 끄십시오. 셸, 명령 실행기 또는 브라우저 내 터미널을 제공하는 모든 파일 관리자는 유효한 세션을 가진 사람에게 원격 코드 실행(RCE) 권한을 제공하는 것과 같습니다. FileBrowser는 명령 실행기를 비활성화할 것을 권장하며, Cloud Commander의 샘플 설정은 콘솔을 활성화합니다. 기본값에 의존하지 말고 의도에 따라 결정하십시오.

가장 먼저 발생하는 문제와 오류 메시지

listen tcp :80: bind: permission denied. Linux는 1024 미만의 포트를 권한이 있는 프로세스를 위해 예약합니다. FileBrowser Quantum의 문서화된 설정은 80번 포트를 사용하는데, 이는 컨테이너 내부에서는 문제없지만 호스트에서 일반 사용자 권한으로 바이너리를 실행하는 즉시 실패합니다. config.yaml에서 1024 이상의 포트를 설정하고 443번 포트는 프록시가 담당하도록 하십시오.

브라우징은 되지만 업로드가 실패함. 디렉터리 목록을 보려면 r-x 권한이 필요하며, 디렉터리에 쓰기를 하려면 w 권한이 필요합니다. 웹 인터페이스는 일반적인 오류 메시지만 표시하므로 애플리케이션 로그보다 파일 시스템 권한을 먼저 확인하십시오.

413 Request Entity Too Large. 해당 오류는 파일 관리자가 아니라 nginx에서 발생합니다. 기본 client_max_body_size는 1 MB이므로, 이보다 큰 파일은 애플리케이션에 도달하기 전에 프록시 단계에서 거부됩니다. server 블록에 client_max_body_size 4096m;을 설정하거나, 0를 설정하여 제한을 해제하십시오.

업로드된 파일의 그룹이 잘못됨. 새로운 파일은 상위 디렉터리의 설정과 관계없이 프로세스를 실행한 사용자의 소유가 되며, 이로 인해 동일한 디렉터리를 읽는 다른 서비스에서 문제가 발생할 수 있습니다. 두 서비스에 공유 그룹을 부여하고 디렉터리에 sudo chmod g+s /srv/files으로 setgid 비트를 설정하면, 새로운 파일이 디렉터리의 그룹을 상속받게 됩니다.

포트 접속은 잘 되지만 프록시 뒤에서는 작동하지 않음. 하위 경로에서 서비스되는 애플리케이션은 자신이 위치한 경로 접두사를 알아야 링크를 올바르게 생성합니다. Cloud Commander는 이를 위해 --prefix 옵션을 제공합니다. 이러한 옵션이 없는 경우, 애플리케이션에 별도의 서브도메인을 할당하고 루트 경로를 프록시하도록 설정하십시오.

어떤 셀프 호스팅 파일 관리자를 선택해야 할까요?

• VPS 한 대, 디렉터리 한두 개, 만료 기한이 있는 공유 링크, 그리고 추후 SSO 도입을 고려한다면: FileBrowser Quantum을 선택하십시오.
• S3 버킷, SFTP 호스트, SMB를 통한 NAS 등 다른 곳에 파일이 저장되어 있고 이를 하나의 웹 뷰로 통합하고 싶다면: 무료 티어 제한 내에서 Filestash를 사용하십시오.
• 다른 사용자에게 계정을 부여하고, 할당량을 설정하며, SFTP나 FTPS를 통한 업로드가 필요하다면: SFTPGo를 선택하십시오. 이때 웹 클라이언트는 주된 목적이 아닌 유용한 부가 기능으로 활용하는 것이 좋습니다.
• SSH 터널을 통해서만 접근하며 외부에 공개하지 않는, 편집기와 터미널이 포함된 개인용 도구가 필요하다면: Cloud Commander를 선택하십시오.
• 이미 Nextcloud를 운영 중이고 특정 디렉터리를 노출해야 한다면: 새로운 소프트웨어를 설치할 필요 없이 External Storage 앱을 사용하십시오.

무엇을 선택하든 소프트웨어 자체보다 배포 방식이 더 중요합니다. 하나의 디렉터리, root가 아닌 사용자 계정, localhost에 바인딩된 포트, 그리고 앞단에 배치된 인증 체계가 필수입니다. 이러한 방식으로 설정된 파일 관리자는 편리한 도구가 됩니다. 반면 동일한 소프트웨어를 / 경로에 공유 비밀번호로 설정해 둔다면, 이는 그저 인터페이스가 좋은 원격 셸에 불과합니다.

FAQ

2026년에도 FileBrowser를 계속 사용하는 것이 안전합니까?

업스트림 filebrowser/filebrowser README에 따르면 File Browser는 2026-09-01부로 아카이브되었으며, 이후 릴리스, 버그 수정, 보안 패치가 제공되지 않습니다. 코드는 여전히 실행되지만, 파일 시스템에 대한 쓰기 권한을 가진 패치되지 않은 소프트웨어는 시간이 지날수록 위험이 커집니다. 계속 사용하려면 프로젝트의 권장 사항을 따라야 합니다. 인터넷에 직접 노출하지 말고, 리버스 프록시를 통해 TLS와 자체 인증을 수행하며, 명령 실행기(command runner)를 비활성화하고, 서비스할 디렉터리만 마운트한 비권한 컨테이너에서 실행하십시오. 또한 세션이 서버 측 식별자가 아닌 독립적인 JWT로 관리되므로 세션을 취소할 수 없으며, 비밀번호를 변경해도 이미 발급된 토큰은 무효화되지 않습니다. 신규 설치 시에는 개발이 계속 진행 중인 gtstef/filebrowser 이미지로 배포되는 FileBrowser Quantum 포크를 사용하십시오.

자체 호스팅 파일 관리자에서 기존 SSO를 사용할 수 있습니까?

FileBrowser Quantum은 OIDC, LDAP 및 프록시 헤더 모드를 지원하므로 별도의 사용자 목록 없이 기존 ID 공급자 뒤에 배치할 수 있습니다. SFTPGo의 OpenID Connect 통합은 오픈 소스 빌드에 포함되어 있으며, ID 공급자의 사용자를 WebAdmin 및 WebClient 인터페이스 모두를 위한 SFTPGo 관리자 및 사용자로 매핑합니다. Filestash는 주의가 필요한 예외 사례입니다. 2026년 8월 기준, Filestash의 가격 페이지는 SSO(SAML, OIDC, LDAP) 기능을 월 50달러부터 시작하는 유료 자체 호스팅 티어에 포함하고 있으며, 무료 티어는 AGPL v3 라이선스로 최대 3명까지의 사용자만 지원합니다. 애플리케이션이 SSO를 전혀 지원하지 않는 경우, 리버스 프록시에서 포워드 인증(forward authentication)을 수행하여 로그인 페이지를 보호할 수 있으나, 애플리케이션 내부 권한은 그대로 유지됩니다.

만료되는 공유 링크를 생성할 수 있는 도구는 무엇입니까?

SFTPGo가 가장 완벽한 구현을 제공합니다. 사용자는 WebClient에서 HTTP/S 링크를 생성할 때 다운로드 및 업로드 횟수 제한, 비밀번호 설정, 소스 IP 주소에 따른 접근 제한, 자동 만료 날짜 설정을 할 수 있습니다. FileBrowser Quantum은 만료 시간이 있는 공유를 지원하며, 익명 접근 또는 특정 사용자 접근으로 제한할 수 있고 공유별로 보기, 편집, 업로드 권한을 부여할 수 있습니다. Filestash도 공유 기능을 제공하는데, 브라우저 세션이 종료된 후에도 링크가 작동해야 하므로 서버가 스토리지 자격 증명의 암호화된 복사본을 영구적으로 보관하는 유일한 사례입니다. Cloud Commander는 공유 링크 기능을 제공하지 않습니다.

혼자 사용하는 경우 파일 관리자를 / 경로에 연결해도 안전합니까?

아니요, 이는 본인을 신뢰하는 문제와는 별개의 위험입니다. 해당 프로세스는 사용자 계정이 접근할 수 있는 모든 경로에 대한 읽기 및 쓰기 권한을 가집니다. 따라서 세션에 대한 경로 노출, 쿠키 탈취, 업로드 핸들러의 패치되지 않은 버그, 비밀번호 재사용 등이 발생하면 /etc, SSH 키, 모든 서비스의 데이터 디렉터리가 공격자에게 노출됩니다. 마운트 범위를 / 대신 /srv/files와 같이 하나의 디렉터리로 제한하십시오. Cloud Commander의 경우 배포된 Docker 명령어가 호스트 루트를 /mnt/fs에 마운트하고 샘플 설정에서 "auth": false을 사용하여 "root": "/"를 설정하므로 가장 위험합니다. 컨테이너가 localhost 이외의 곳에서 수신 대기하기 전에 이 설정을 모두 변경하십시오.