Windows 11에서 Docker와 Portainer를 이용해 ownCloud Infinite Scale(이하 OCIS)을 설치하는 과정을 정리했습니다.
처음에는 단순히 Docker Compose 파일을 작성하고 컨테이너를 실행하면 될 것으로 생각했지만, 실제로 진행해 보니 초기 설정, 인증서, 접속 주소 등 몇 가지 확인해야 할 부분이 있었습니다.
특히 HTTP와 HTTPS의 차이, ocis init 초기화 과정, 그리고 OCIS_URL 설정이 중요했습니다.
이번 글에서는 실제 설치에 사용한 Docker Compose YAML부터 Portainer 배포, 오류 해결, 최종 PowerShell 점검까지 순서대로 정리하겠습니다.
목차
- 설치 환경과 폴더 구조
- Docker Compose YAML 작성
- Portainer에서 Stack 배포하기
- 초기 설정과 인증서 문제 해결
- HTTP 접속 오류와 HTTPS 설정
- config.json 오류와 OCIS_URL 수정
- 최종 PowerShell 점검
- 자주 발생하는 오류 정리
1. 설치 환경과 폴더 구조
이번 설치는 Windows 11에서 Docker Desktop과 Portainer를 사용하는 환경입니다.
OCIS는 Docker 컨테이너로 실행하고, 설정 파일과 실제 데이터는 Windows의 별도 폴더에 저장하도록 구성했습니다.
Docker 내부 볼륨에 데이터를 저장하는 방식이 아니라 Windows에서 직접 폴더를 확인하고 관리할 수 있는 Bind Mount 방식을 선택했습니다.
설치 환경
| 구분 | 설정 |
|---|---|
| 운영체제 | Windows 11 |
| 컨테이너 관리 | Docker Desktop |
| Docker 관리 UI | Portainer |
| 설치 이미지 | owncloud/ocis:8.2.0 |
| 컨테이너 이름 | owncloud-ocis |
| 서비스 포트 | 9200 |
| 설치 경로 | C:\docker\oics |
| 설정 파일 경로 | C:\docker\oics\config |
| 데이터 저장 경로 | C:\docker\oics\data |
| 접속 주소 | https://192.168.0.1:9200 |
※ 192.168.0.1은 이번 설치에서 테스트를 진행하며 실제로 사용한 접속 주소입니다. 다른 서버에서 설치한다면 자신의 서버 IP로 변경해야 합니다.
폴더 구조
설치 전에 다음과 같은 폴더 구조를 준비합니다.
C:\docker\oics
│
├─ config
│ └─ ocis.yaml
│
└─ data
config에는 OCIS 설정 파일이 저장되고, data에는 실제 서비스 데이터가 저장됩니다.
이렇게 구성하면 Docker 컨테이너를 재생성하거나 업데이트하더라도 설정과 데이터를 별도로 보존할 수 있습니다.
2. Docker Compose YAML 작성
이제 Portainer에서 사용할 Docker Compose 파일을 작성합니다.
이번 구성에서 중요하게 생각한 부분은 다음과 같습니다.
- OCIS 버전을
8.2.0으로 고정합니다. - 설정 파일과 데이터 저장 경로를 Windows에서 직접 지정합니다.
- 컨테이너가 재시작되어도 자동으로 실행되도록 설정합니다.
- 초기 설정 시 인증서 확인 관련 질문이 반복되지 않도록 처리합니다.
- 테스트 환경에서는 포트 9200을 외부에 개방합니다.
최종 Docker Compose YAML
services:
ocis:
image: owncloud/ocis:8.2.0
container_name: owncloud-ocis
restart: unless-stopped
entrypoint: ["/bin/sh"]
command:
- "-c"
- "ocis init --insecure yes || true; exec ocis server"
environment:
OCIS_URL: "https://192.168.0.1:9200"
PROXY_HTTP_ADDR: "0.0.0.0:9200"
PROXY_TLS: "true"
OCIS_INSECURE: "true"
PROXY_FORCE_STRICT_TRANSPORT_SECURITY: "false"
IDM_CREATE_DEMO_USERS: "false"
OCIS_LOG_LEVEL: "info"
OCIS_LOG_COLOR: "false"
OCIS_CONFIG_DIR: "/etc/ocis"
OCIS_BASE_DATA_PATH: "/var/lib/ocis"
ports:
- "9200:9200"
volumes:
- "C:/docker/oics/config:/etc/ocis"
- "C:/docker/oics/data:/var/lib/ocis"
logging:
driver: "json-file"
options:
max-size: "10m"
max-file: "3"
stop_grace_period: 30s
주요 설정 설명
1. 이미지 버전 고정
image: owncloud/ocis:8.2.0
latest 대신 8.2.0을 지정했습니다.
이렇게 하면 이미지 업데이트로 인해 예기치 않게 동작이 달라지는 것을 줄일 수 있습니다.
2. 초기화 명령
entrypoint: ["/bin/sh"]
command:
- "-c"
- "ocis init --insecure yes || true; exec ocis server"
OCIS는 처음 실행할 때 ocis init을 통해 초기 설정 파일을 생성합니다.
여기서 --insecure yes는 자체 서명 인증서를 사용하는 테스트 환경에서 인증서 확인을 비활성화하는 초기 설정 옵션입니다.
|| true는 이미 설정 파일이 존재해서 초기화 명령이 실패하더라도 서버 실행으로 이어지도록 하는 역할입니다.
exec ocis server는 초기화 이후 실제 OCIS 서비스를 실행합니다.
참고로 공식 문서에서도 Docker Compose 환경에서 초기화 명령을 실행하고, 기존 설정 파일이 있으면 초기화를 건너뛰는 구성을 안내하고 있습니다.
3. OCIS_URL
OCIS_URL: "https://192.168.0.1:9200"
이번 설치 과정에서 가장 중요했던 설정입니다.
단순히 서버가 실행되는 것과 브라우저에서 웹 클라이언트가 정상적으로 작동하는 것은 별개의 문제였습니다.
실제 브라우저에서 접속하는 주소와 OCIS_URL이 일치하도록 설정해야 합니다.
4. 포트 설정
ports:
- "9200:9200"
처음에는 특정 내부 IP를 바인딩하는 방식도 고려했지만, Portainer에서 테스트하는 과정에서는 모든 인터페이스에 포트를 개방하는 형태로 구성했습니다.
5. 데이터 저장 경로
volumes:
- "C:/docker/oics/config:/etc/ocis"
- "C:/docker/oics/data:/var/lib/ocis"
Windows의 실제 폴더와 컨테이너 내부 폴더를 연결합니다.
따라서 OCIS 설정과 데이터를 Windows 탐색기에서도 직접 확인할 수 있습니다.
3. Portainer에서 Stack 배포하기
Compose 파일을 준비했다면 Portainer에서 배포합니다.
- Portainer 접속
- 왼쪽 메뉴에서 Stacks 선택
- Add stack 선택
- 이름을
ocis로 지정 - Web editor에 위 Docker Compose YAML 붙여넣기
- Deploy the stack 클릭
정상적으로 배포되면 컨테이너 목록에서 다음과 같이 확인할 수 있습니다.
NAME IMAGE STATUS
owncloud-ocis owncloud/ocis:8.2.0 Up
포트도 다음과 같이 표시됩니다.
0.0.0.0:9200->9200/tcp
이제 OCIS 컨테이너가 실행되는 상태입니다.
4. 초기 설정과 인증서 문제 해결
처음 설치할 때 가장 먼저 만났던 문제는 다음과 같은 질문이 반복되는 현상이었습니다.
This is not recommended for public instances!
Do you want to configure Infinite Scale
with certificate checking disabled?
[yes | no = default]
이 질문은 OCIS가 자체 서명 인증서를 사용하는 환경에서 인증서 확인을 비활성화할 것인지 묻는 내용입니다.
문제는 Portainer에서 Stack을 실행하는 경우 사용자가 직접 터미널에서 질문에 답할 수 없다는 점입니다.
해결 방법
초기화 명령에 다음 옵션을 추가했습니다.
ocis init --insecure yes
이렇게 하면 매번 직접 yes를 입력하지 않아도 됩니다.
초기 설정이 완료되면 Windows 폴더에 다음 파일이 생성됩니다.
C:\docker\oics\config\ocis.yaml
PowerShell에서 확인할 수도 있습니다.
Test-Path "C:\docker\oics\config\ocis.yaml"
정상적으로 생성되었다면 다음과 같이 표시됩니다.
True
이 파일이 존재한다면 초기 설정 파일 생성 단계는 완료된 것입니다.
5. HTTP 접속 오류와 HTTPS 설정
컨테이너가 정상 실행되었다고 해서 반드시 브라우저 접속까지 성공하는 것은 아닙니다.
처음에는 다음 주소로 접속했습니다.
http://192.168.0.1:9200/
그런데 브라우저에 다음 메시지가 나타났습니다.
Client sent an HTTP request to an HTTPS server.
이 오류는 서버가 HTTP 요청을 받았지만 HTTPS 통신을 기대하고 있다는 뜻입니다.
서버가 꺼진 것이 아니라 접속 프로토콜이 잘못된 것입니다.
해결 방법
주소 앞부분을 http://에서 https://로 변경하면 됩니다.
https://192.168.0.1:9200/
자체 서명 인증서를 사용하는 테스트 환경에서는 브라우저에 보안 경고가 나타날 수 있습니다.
테스트 환경에 한해 브라우저의 고급 설정에서 해당 사이트로 이동할 수 있습니다.
단, 이 설정은 인터넷에 공개하는 운영 환경을 위한 보안 구성이 아닙니다. 외부에 공개할 때는 정상적인 인증서와 도메인을 사용해야 합니다.
6. config.json 오류와 OCIS_URL 수정
HTTPS로 접속한 다음에는 또 다른 오류가 나타났습니다.
# 설정이 없거나 잘못됨
config.json 파일이 존재하고 올바른지 확인하십시오,
또한 자세한 내용은 브라우저 콘솔을 확인하십시오.
처음에는 config.json 파일이 실제로 없어서 발생하는 문제라고 생각했습니다.
하지만 확인 과정에서 다른 설정이 문제라는 것을 발견했습니다.
문제의 원인
PowerShell에서 컨테이너의 환경변수를 확인했습니다.
docker exec owncloud-ocis sh -c "env | sort | grep -E 'OCIS_URL|WEB_|PROXY_'"
실행 결과는 다음과 같았습니다.
OCIS_URL=https://localhost:9200
PROXY_FORCE_STRICT_TRANSPORT_SECURITY=false
PROXY_HTTP_ADDR=0.0.0.0:9200
PROXY_TLS=true
여기서 문제가 되는 부분은 다음입니다.
OCIS_URL=https://localhost:9200
실제 브라우저에서는 다음 주소로 접속하고 있었습니다.
https://192.168.0.1:9200
즉, 컨테이너는 localhost를 기준으로 서버 주소를 안내하고 있지만 실제 사용자는 192.168.0.1로 접속하고 있었던 것입니다.
해결 방법
Docker Compose의 환경변수를 수정했습니다.
기존 설정:
OCIS_URL: "https://localhost:9200"
수정한 설정:
OCIS_URL: "https://192.168.0.1:9200"
수정 후 Portainer에서 Stack을 다시 배포했습니다.
이후 브라우저에서 다시 접속하자 정상적으로 OCIS 웹 화면을 사용할 수 있었습니다.
여기서 중요한 점은 config.json을 직접 만들어 넣는 것이 아니라, OCIS가 사용하는 외부 접속 주소를 실제 접속 주소와 일치시키는 것입니다.
7. 최종 PowerShell 점검
설치가 완료되었다면 PowerShell에서 다음 명령을 이용해 상태를 확인할 수 있습니다.
① 컨테이너 실행 상태 확인
docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}"
정상적인 경우 다음과 비슷하게 표시됩니다.
NAMES IMAGE STATUS
owncloud-ocis owncloud/ocis:8.2.0 Up
포트는 다음과 같이 표시되어야 합니다.
0.0.0.0:9200->9200/tcp
② Docker Compose Stack 확인
docker compose ls
정상적으로 등록되어 있다면 다음과 같이 표시됩니다.
NAME STATUS
ocis running(1)
③ 초기 설정 파일 확인
Test-Path "C:\docker\oics\config\ocis.yaml"
정상 결과:
True
④ 컨테이너 로그 확인
docker logs --tail 100 owncloud-ocis
서버 시작 과정에서 발생한 오류나 서비스 관련 메시지를 확인할 수 있습니다.
⑤ 컨테이너 환경변수 확인
docker exec owncloud-ocis sh -c "env | sort | grep -E 'OCIS_URL|WEB_|PROXY_'"
최종적으로 다음과 같이 OCIS_URL이 실제 접속 주소와 일치하는지 확인합니다.
OCIS_URL=https://192.168.0.1:9200
PROXY_FORCE_STRICT_TRANSPORT_SECURITY=false
PROXY_HTTP_ADDR=0.0.0.0:9200
PROXY_TLS=true
⑥ 데이터 저장 경로 확인
docker inspect owncloud-ocis --format '{{json .Mounts}}'
이 명령으로 Windows 폴더가 컨테이너 내부에 올바르게 연결되었는지 확인할 수 있습니다.
확인해야 할 연결은 다음 두 가지입니다.
| Windows 경로 | 컨테이너 경로 |
|---|---|
| C:\docker\oics\config | /etc/ocis |
| C:\docker\oics\data | /var/lib/ocis |
⑦ 웹 접속 확인
최종 접속 주소는 다음과 같습니다.
https://192.168.0.1:9200
HTTP가 아닌 HTTPS로 접속해야 합니다.

8. 설치 과정에서 발생한 오류 정리
이번 설치에서 실제로 확인했던 오류와 해결 방법을 정리하면 다음과 같습니다.
| 발생한 문제 | 원인 | 해결 방법 |
|---|---|---|
| 인증서 확인 질문 반복 | 초기화 명령이 대화형으로 실행됨 | ocis init --insecure yes 사용 |
| HTTP 요청을 HTTPS 서버로 보냈다는 메시지 | HTTP로 접속 | HTTPS 주소로 접속 |
| config.json 설정 오류 | 실제 접속 주소와 OCIS_URL 불일치 | OCIS_URL을 서버 IP로 수정 |
| No such container | 지정한 이름의 컨테이너가 조회되지 않음 | docker ps -a로 실제 컨테이너 확인 |
| 설정 파일이 생성되지 않았는지 확인 필요 | 초기화 또는 볼륨 마운트 확인 필요 | Test-Path와 Mounts 확인 |
특히 No such container 메시지가 나왔을 때는 컨테이너가 실제로 없다고 단정하지 말고 다음 명령으로 전체 목록을 확인하는 것이 좋습니다.
docker ps -a
이번에도 최종적으로 컨테이너가 정상 실행 중인 것을 확인할 수 있었습니다.

마무리
이번 설치에서 가장 중요한 것은 단순히 컨테이너를 실행하는 것이 아니라, OCIS가 사용하는 서버 주소와 실제 브라우저에서 접속하는 주소를 일치시키는 것이었습니다.
특히 OCIS_URL을 localhost로 설정한 상태에서 다른 내부 IP로 접속하면 웹 클라이언트 설정 오류가 발생할 수 있다는 점을 확인했습니다.
최종적으로 다음 세 가지를 기억하면 됩니다.
- Windows 폴더를 Bind Mount로 연결해 설정과 데이터를 직접 관리합니다.
- 자체 서명 인증서를 사용하는 테스트 환경에서는 HTTPS로 접속합니다.
OCIS_URL은 브라우저에서 실제로 접속하는 서버 주소와 일치시킵니다.
이렇게 설정하면 Windows Docker 환경에서도 Portainer를 이용해 ownCloud Infinite Scale을 관리할 수 있습니다.
다만 이번 구성은 내부 네트워크에서 설치와 기능을 확인하기 위한 테스트용 설정입니다. 외부 인터넷에 공개할 때는 도메인, 정식 TLS 인증서, 방화벽 및 보안 설정을 별도로 구성해야 합니다.
owncloud 는 종종 사용하는 분들이 계시기는 하지만, OICS가 아직까지 국내에서는 대중적이라는 이미지가 없어서 뭔가 어렵게? 해결했습니다만. 하. 그런데 Nextcloud에 너무 길들여져 있어서 그런가 막상 사용하지는 않을거 같습니다.
이미지는 immich 를 사용해서 공유하고 있습니다만. 파일을 공유해야 한다- 싶은 상황이 생긴다면, 당분간은 Psitransfer 를 더 자주 사용하게 될 거같습니다.

