가이드

작성자 Matt Connor 2026-08-13

VPS에서 rootless Podman으로 Ollama 실행하기

Q: 루트리스(rootless) Podman 컨테이너가 로그아웃하면 왜 중단됩니까?

사용자의 마지막 세션이 종료되면 해당 사용자의 systemd 인스턴스와 /run/user/ 디렉터리가 정리되며, 모든 루트리스 컨테이너도 함께 종료됩니다. sudo loginctl enable-linger ollama를 실행하여 loginctl show-user ollama --property=Linger이 Linger=yes을 출력하는지 확인하십시오. Quadlet 유닛을 생성하기 전에 링거링(lingering)을 활성화해야 합니다. 유닛이 필요로 하는 런타임 디렉터리는 링거링이 켜져 있어야만 존재하기 때문입니다.

VPS 환경에서 rootless Podman을 사용하여 Ollama를 안전하게 실행하는 방법을 설명합니다. 전용 사용자 설정, lingering 활성화, Quadlet을 이용한 자동 재시작 구성, SELinux 레이블 지정 및 SSH 터널을 통한 보안 접근 방식을 단계별로 안내합니다.

VPS에서 rootless Podman으로 Ollama 실행하기

서버의 rootless Podman 환경에서 Ollama를 실행하려면 데스크톱 가이드에서는 생략되는 5가지 조건이 충족되어야 합니다. 전용 권한 없는(unprivileged) 사용자가 컨테이너를 소유해야 합니다. 해당 사용자에 대해 lingering이 활성화되어야 로그아웃 후에도 컨테이너가 계속 실행됩니다. Quadlet 파일을 통해 컨테이너를 systemd에 등록해야 재부팅 후에도 컨테이너가 자동으로 복구됩니다. SELinux를 강제하는 배포판에서는 모델 디렉터리에 올바른 SELinux 레이블을 지정해야 합니다. API는 루프백 인터페이스에서만 수신 대기하며, SSH(secure shell) 터널을 통해 접근해야 합니다.

Ollama는 거대 언어 모델(LLM)을 위한 서버입니다. 모델 가중치를 디스크에 저장하고 메모리에 로드한 뒤, 11434 포트에서 HTTP 요청을 처리합니다. 로그인, API 키, 사용자 계정 기능이 없으므로 네트워크가 유일한 접근 제어 수단입니다. Podman은 데몬 없이 root 권한 없이 컨테이너를 실행하므로, 컨테이너를 탈출하더라도 일반적인 권한 없는 사용자의 권한으로 시작됩니다. 런타임 비교를 먼저 확인하려면 VPS에서 Podman과 Docker의 차이점을 읽어보십시오. 컨테이너를 완전히 건너뛰고 싶다면 VPS에 Ollama 직접 설치하기가 더 빠른 경로입니다.

SSD Nodes는 이미지 중 하나로 Fedora를 제공하며, Fedora는 기본적으로 Podman과 SELinux(security-enhanced Linux)를 모두 포함합니다. 아래의 모든 명령어는 Podman 5 이상을 사용하는 모든 배포판에서 실행됩니다.

서버에서 노트북용 버전을 수정해야 하는 이유

Fedora Magazine은 2026년 8월 5일에 이 스택에 대한 명확한 가이드를 발행했습니다: Running Ollama Locally with Podman on Fedora Linux, 저자는 Yazan Monshed입니다. 이 도구들을 처음 한 시간 동안 다루기에 좋은 자료입니다. 다만 이 가이드는 노트북을 대상으로 작성되었으며, 그중 네 가지 선택 사항은 공인 IP 주소를 가진 서버에서 다르게 동작합니다.

컨테이너를 단순한 podman run -d 명령으로 시작합니다. 수동으로 시작한 컨테이너는 재부팅 후 자동으로 다시 실행되지 않습니다. 시작하라는 지시가 없었기 때문입니다.
ollama/ollama와 같은 유동적인 태그를 사용합니다. 노트북에서는 동작이 바뀌는 날 바로 알아차릴 수 있지만, 서버에서는 밤사이에 스크립트가 작동을 멈추는 것으로 첫 징후가 나타납니다.
-p 11434:11434으로 포트를 게시하는데, 이는 모든 인터페이스에 바인딩됩니다. 가정용 라우터 뒤에서는 인터넷에서 접근할 수 없지만, VPS에서는 비밀번호가 없는 공개 추론 API가 됩니다.
로그인한 사용자 계정으로 실행합니다. 서버에서는 컨테이너를 소유한 계정이 다른 어떤 것도 소유하지 않아야 합니다. 그래야 컨테이너 탈출이 발생해도 빈 홈 디렉터리에 갇히게 됩니다.

이러한 설정들이 해당 가이드가 작성된 환경에서는 잘못된 것이 아닙니다. 다만 서버가 어디서든 접근 가능하고 앞에 아무도 앉아 있지 않은 환경이라면, 각 항목은 다시 검토해야 할 결정 사항들입니다.

권한이 없는 사용자를 생성하고 subuid 확인하기

Rootless Podman은 컨테이너 내부의 사용자 ID(UID)를 호스트의 사용되지 않는 ID 블록으로 매핑합니다. 해당 블록은 /etc/subuid 및 /etc/subgid에 선언되어 있습니다. 이 설정이 없으면 rootless 컨테이너는 전혀 시작할 수 없습니다.

sudo dnf install -y podman        # or: sudo apt install -y podman
sudo useradd --create-home --shell /bin/bash --comment "Ollama container owner" ollama
sudo passwd --lock ollama
grep ollama /etc/subuid /etc/subgid

grep 명령은 각 파일에서 한 줄씩, 총 두 줄을 출력해야 하며 각 줄은 65536개의 ID 범위를 지정해야 합니다.

/etc/subuid:ollama:100000:65536
/etc/subgid:ollama:100000:65536

시작 번호는 다를 수 있으며, 이는 정상입니다. 만약 grep 명령이 아무것도 출력하지 않는다면, useradd이 범위를 할당하지 않은 것이며 해당 사용자로 실행하는 첫 번째 podman 명령은 다음과 같이 실패합니다.

Error: cannot find UID/GID for user ollama: no subuid ranges found for user "ollama" in /etc/subuid

다른 사용자가 점유하지 않은 범위를 할당한 다음, Podman에게 기존 매핑이 유효하지 않음을 알립니다.

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 ollama
sudo -iu ollama podman system migrate

비밀번호를 잠그면 누구도 ollama 계정으로 직접 로그인할 수 없습니다. 관리자 사용자에서 sudo -iu ollama 명령을 사용하여 해당 계정에 접근하십시오.

로그아웃 후에도 서비스가 유지되도록 lingering 활성화

사용자의 systemd 인스턴스는 일반적으로 로그인 시 시작되고 로그아웃 시 종료되며, 이때 /run/user/<uid>도 함께 제거됩니다. 해당 사용자가 소유한 모든 rootless 컨테이너는 같은 시점에 종료됩니다. Lingering을 활성화하면 세션이 연결되어 있지 않아도 사용자 인스턴스가 계속 실행됩니다.

sudo loginctl enable-linger ollama
loginctl show-user ollama --property=Linger

위 명령을 실행하면 Linger=yes이 출력되어야 합니다. 유닛을 생성하기 전에 이 설정을 활성화하십시오. 유닛이 필요로 하는 디렉터리인 /run/user/<uid>는 lingering이 활성화된 후에만 생성되기 때문입니다.

아무도 예상하지 못하는 추가 단계가 하나 더 있습니다. sudo -iu ollama는 셸을 제공하지만 세션 버스는 제공하지 않으므로, systemctl --user은 즉시 실패합니다.

Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined

systemd는 $XDG_RUNTIME_DIR/bus에서 사용자 버스를 찾지만, sudo -i은 해당 변수를 설정하지 않습니다. 이 서비스를 관리하는 모든 관리자 셸에서 다음 변수를 수동으로 설정하십시오.

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user status

모델 블롭이 저장되는 위치와 디스크 용량 계획

Ollama는 컨테이너 내부의 /root/.ollama/models 경로에 가중치를 기록합니다. 사용자의 홈 디렉터리에 있는 디렉터리를 해당 경로에 바인드 마운트하면, 파일이 /home/ollama/ollama-data/models 위치에 저장되어 용량을 측정할 수 있게 됩니다. 블롭은 콘텐츠 주소 지정 방식에 따라 models/blobs에 저장되며, models/manifests에는 이를 식별하는 작은 인덱스 파일이 위치합니다. Fedora Magazine 게시물에서처럼 명명된 볼륨(named volume)을 사용하는 경우, 동일한 트리 구조가 /home/ollama/.local/share/containers/storage/volumes/<volume>/_data 아래에 생성됩니다.

모델을 다운로드하기 전에 디스크 용량을 산정하십시오. 공개된 다운로드 크기는 최소 기준입니다.

ChartPublished download size per Ollama model tag, ollama.com/library, checked 13 August 2026

label

download_gb

gemma3:4b

3.3

mistral:7b

4.4

qwen3:8b

5.2

gemma3:12b

8.1

qwen3:14b

9.3

gemma3:27b

qwen3:30b

The data behind this chart

[
  {
    "label": "gemma3:4b",
    "download_gb": 3.3
  },
  {
    "label": "mistral:7b",
    "download_gb": 4.4
  },
  {
    "label": "qwen3:8b",
    "download_gb": 5.2
  },
  {
    "label": "gemma3:12b",
    "download_gb": 8.1
  },
  {
    "label": "qwen3:14b",
    "download_gb": 9.3
  },
  {
    "label": "gemma3:27b",
    "download_gb": 17
  },
  {
    "label": "qwen3:30b",
    "download_gb": 19
  }
]

7개의 모든 행은 ollama.com/library에 게시된 수치이며, 실제 디스크에서 측정한 크기가 아닙니다. 여기서 가장 작은 태그인 gemma3:4b은 3.3 GB를 다운로드합니다. 가장 큰 태그인 qwen3:30b은 19 GB를 다운로드합니다. 컨테이너 이미지 자체는 Podman의 자체 저장소에 별도로 위치하므로, podman system df와 df -h /home를 사용하여 두 수치를 함께 확인하십시오. 또한 모델은 로드되는 동안 파일 크기와 거의 동일한 RAM 용량이 필요하며, 컨텍스트 윈도우를 위한 추가 공간도 필요합니다. 따라서 16 GB RAM을 가진 VPS에서 19 GB 모델은 실행되지 않습니다.

이미지 태그를 고정하고 전체 레지스트리 이름을 사용하십시오

sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
mkdir -p ~/ollama-data ~/.config/containers/systemd
podman pull docker.io/ollama/ollama:0.32.9

2026년 8월 기준 0.32.9과 같은 릴리스된 버전 태그를 사용하고, latest은 사용하지 마십시오. 태그를 고정하면 04:00에 재시작하더라도 테스트했던 것과 동일한 바이너리가 실행되므로, 동작이 변경되었다면 그것은 사용자가 직접 변경한 결과입니다. Docker Hub는 동일한 버전에 대해 -rc 및 -rocm 태그도 게시합니다. AMD GPU를 사용하지 않는다면 일반 태그를 선택하십시오.

레지스트리 호스트도 함께 작성하십시오. Fedora의 systemd 유닛에서 짧은 이름을 사용하면 입력을 요구할 터미널이 없으므로, 유닛은 다음과 같은 오류와 함께 실패합니다.

Error: short-name "ollama/ollama" did not resolve to an alias and no unqualified-search registries are defined

수동으로 먼저 이미지를 내려받는 것은 선택 사항이지만, 수 기가바이트에 달하는 다운로드 과정을 유닛 시작 타임아웃 시간에서 제외할 수 있어 유용합니다.

재부팅 후에도 유지되는 Quadlet 유닛

Quadlet은 Podman의 systemd 생성기입니다. .container 파일을 작성하면 systemd가 부팅 시 이를 서비스로 변환하며, podman generate systemd은 더 이상 필요하지 않습니다. 이 파일을 ollama 사용자가 소유하도록 하여 /home/ollama/.config/containers/systemd/ollama.container 경로에 저장하십시오.

[Unit]
Description=Ollama API (rootless)
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/ollama/ollama:0.32.9
ContainerName=ollama
PublishPort=127.0.0.1:11434:11434
Volume=/home/ollama/ollama-data:/root/.ollama:Z
Environment=OLLAMA_KEEP_ALIVE=30m
Environment=OLLAMA_MAX_LOADED_MODELS=1

[Service]
Restart=always
TimeoutStartSec=900

[Install]
WantedBy=default.target

파일 이름이 서비스 이름을 결정하므로 ollama.container는 ollama.service가 됩니다.

systemctl --user daemon-reload
systemctl --user start ollama.service
systemctl --user status ollama.service

status을 실행하면 active (running)이 표시되어야 합니다. systemctl --user enable ollama.service은 실행하지 마십시오. 해당 유닛은 디스크에 파일로 존재하지 않으므로 systemd가 거부합니다.

Failed to enable unit: Unit file /run/user/1001/systemd/generator/ollama.service is transient or generated.

[Install] 섹션이 이미 해당 역할을 수행합니다. Quadlet은 daemon-reload 과정에서 부팅 시 시작되도록 하는 링크를 직접 생성하므로, 이 명령은 선택 사항이 아닙니다. TimeoutStartSec=900은 이미지를 가져오는 데 시간이 걸리는 첫 시작을 고려한 설정입니다. 기본값인 90초는 2GB 용량의 다운로드를 완료하기에 부족하여 systemd가 시작을 실패로 간주하고 종료할 수 있기 때문입니다. OLLAMA_KEEP_ALIVE=30m는 5분 후 모델을 메모리에서 해제하는 대신 요청 간에 모델을 메모리에 유지합니다. 이에 따른 장단점은 Ollama 모델을 메모리에 유지하기에서 확인할 수 있습니다. 여기서 사용된 systemd 용어가 생소하다면 VPS에서 systemd 서비스와 타이머가 작동하는 방식을 통해 유닛 자체에 대한 내용을 참조하십시오.

SELinux 환경에서 모델 디렉터리에 접근 거부(permission denied)가 발생하는 이유

Fedora, RHEL, Rocky 및 AlmaLinux에서는 SELinux가 기본적으로 강제(enforcing) 모드로 동작합니다. 컨테이너 프로세스는 container_t 도메인에서 실행되지만, 사용자의 홈 디렉터리는 user_home_t로 레이블이 지정되어 있습니다. 정책상 두 영역은 서로 상호작용할 수 없으므로, Ollama는 모델 트리를 생성하지 못하고 컨테이너가 종료됩니다. 이러한 시스템에서 getenforce를 실행하면 Enforcing 메시지가 출력되며, 접근 거부 기록은 다음과 같이 남습니다.

sudo ausearch -m avc -ts recent

로그에서 도메인과 대상 레이블을 명시하는 줄을 확인할 수 있습니다.

avc:  denied  { write } for  pid=1842 comm="ollama" name="models" dev="vda1" ino=131077 scontext=system_u:system_r:container_t:s0:c214,c827 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=dir permlisted=0

Volume= 줄 끝에 있는 :Z이 해결책입니다. 이는 호스트 디렉터리를 container_file_t로 재레이블링하고, 해당 컨테이너만 보유한 전용 MCS(multi-category security) 카테고리를 부여합니다. 소문자 :z은 공유 레이블을 사용하며, 두 컨테이너가 동일한 디렉터리를 읽어야 할 때 적합합니다.

:Z 사용 시 주의할 점은 이 작업이 파괴적이며 별도의 확인 절차 없이 수행된다는 것입니다. 재레이블링은 하위 디렉터리까지 재귀적으로 적용됩니다. 만약 /home/ollama를 대상으로 지정하면 해당 홈 디렉터리의 모든 파일이 재레이블링되어, 사용자의 SSH 키 접근이 차단될 수 있습니다. 항상 :Z에는 다른 데이터가 없는 전용 하위 디렉터리를 지정하십시오. 명명된 볼륨(named volume)은 Podman이 생성 시점에 올바르게 레이블을 지정하므로 별도의 작업이 필요하지 않습니다. 더 자세한 내용은 서버를 위한 SELinux 기초에서 컨텍스트와 불리언(boolean)에 대해 확인할 수 있습니다. Ubuntu와 Debian은 대신 AppArmor를 사용하므로, 해당 환경에서 :Z는 아무런 동작을 하지 않으며 유닛 파일에 그대로 두어도 무방합니다.

포트 11434를 닫고 SSH를 통해 API에 접근하기

PublishPort=127.0.0.1:11434:11434는 호스트 측을 루프백에 바인딩합니다. 다음 명령으로 확인하십시오:

ss -ltnp | grep 11434
curl http://127.0.0.1:11434

ss의 출력 결과는 반드시 127.0.0.1:11434이어야 합니다. 0.0.0.0:11434 또는 *:11434가 출력된다면 해당 포트가 인터넷에 개방된 상태이며, curl은 Ollama is running을 반환해야 합니다.

어느 쪽을 바인딩하는지 명확히 구분해야 합니다. PublishPort에 지정된 주소는 호스트 주소입니다. 컨테이너 내부에서 Ollama는 모든 인터페이스에서 수신 대기 상태를 유지해야 하며, 이는 이미지의 기본 설정입니다. Environment=OLLAMA_HOST=127.0.0.1을 설정하면 Ollama가 컨테이너 자체의 루프백에 바인딩됩니다. 이 경우 Podman은 게시된 트래픽을 컨테이너의 네트워크 주소로 전달하므로, 호스트에서 보내는 요청조차 모두 거부됩니다.

포트 11434를 개방하면 두 가지 문제가 발생합니다. Ollama에는 인증 기능이 없으므로, 포트에 접근할 수 있는 누구나 /api/tags를 통해 모델 목록을 확인하고, /api/generate를 사용하여 사용자의 CPU와 대역폭을 점유해 추론을 실행하며, 새로운 모델을 디스크에 내려받거나 기존 모델을 삭제할 수 있습니다. 둘째, 원격 포트로 전송되는 일반 HTTP는 프롬프트와 응답을 평문으로 전송하므로 경로상의 모든 장비가 이를 가로챌 수 있습니다. 포트가 서버 외부로 노출되지 않으면 이 두 가지 문제는 모두 사라집니다.

워크스테이션에서 SSH를 통해 포트를 포워딩하십시오:

ssh -N -L 11434:127.0.0.1:11434 you@vps.example.com

이제 노트북의 http://127.0.0.1:11434은 SSH 세션의 암호화 터널을 통과하여 서버의 Ollama로 연결됩니다. 노트북에서 이미 Ollama를 실행 중이라면 로컬 바인딩이 bind [127.0.0.1]:11434: Address already in use 오류로 실패할 수 있습니다. 이때는 -L 11435:127.0.0.1:11434을 사용하고 클라이언트가 11435를 가리키도록 설정하십시오.

브라우저 클라이언트에서 접근해야 한다면, 앞에 비밀번호가 설정된 리버스 프록시를 두십시오. Caddy 사이트 블록은 4줄이면 충분하며, caddy hash-password는 필요한 bcrypt 해시를 출력합니다:

ollama.example.com {
  basic_auth {
    you $2a$14$replace_with_the_generated_hash
  }
  reverse_proxy 127.0.0.1:11434
}

Caddy는 자동으로 TLS(전송 계층 보안) 인증서를 발급받으므로 트래픽이 암호화됩니다. 먼저 클라이언트를 테스트하십시오. Ollama와 통신하는 많은 도구에는 Authorization 헤더를 입력하는 필드가 없으며, 이 경우 기본 인증(basic auth) 환경에서 401 Unauthorized 오류로 실패하게 됩니다. SSH 터널은 이러한 문제가 없으므로, 본 문서에서는 SSH 터널을 기본 권장 사항으로 제시합니다.

모델을 가져와 전체 경로 확인하기

podman exec -it ollama ollama pull gemma3:4b
curl -s http://127.0.0.1:11434/api/tags
curl -s http://127.0.0.1:11434/api/generate -d '{"model":"gemma3:4b","prompt":"Reply with the single word: ready","stream":false}'
du -sh ~/ollama-data/models

/api/tags는 gemma3:4b 목록이 포함된 JSON을 반환합니다. /api/generate는 디스크에서 가중치를 불러오는 동안 잠시 대기한 후 response 필드가 포함된 JSON 객체를 반환합니다. du은 게시된 다운로드 크기와 유사한 숫자를 보고해야 합니다. 그런 다음 이 가이드의 핵심인 부분을 증명합니다.

sudo reboot
# reconnect, then:
sudo -iu ollama
export XDG_RUNTIME_DIR=/run/user/$(id -u)
systemctl --user is-active ollama.service

active은 프로세스가 유지되고 있음을 의미하며, [Install] 섹션과 daemon-reload가 모두 정상적으로 작동했음을 뜻합니다. inactive은 세 가지 중 하나가 누락되었음을 의미합니다.

실패 유형 및 확인 가능한 메시지

재부팅 후 컨테이너가 사라짐. loginctl show-user ollama --property=Linger을 먼저 확인하십시오. Linger=yes가 없으면 사용자의 systemd 인스턴스가 부팅 시 시작되지 않습니다. Lingering이 활성화되어 있는데도 .container 파일에 [Install] 섹션이 없거나, 파일을 수정한 후 systemctl --user daemon-reload를 실행하지 않은 경우입니다.

Error: statfs /home/ollama/ollama-data: no such file or directory. 컨테이너가 시작되기 전에 바인드 마운트의 원본 경로가 존재해야 합니다. Podman은 호스트 디렉터리를 자동으로 생성하지 않습니다. ollama 사용자로 mkdir -p ~/ollama-data을 실행하십시오.

시작 시 90초 후 실패. 이미지 풀(pull) 작업이 진행 중이어서 journalctl --user -u ollama.service에 Start operation timed out. Terminating.이 표시됩니다. 수동으로 풀을 완료하거나 TimeoutStartSec=900을 유지하십시오.

컨테이너가 시작된 후 즉시 종료됨. podman logs ollama와 sudo ausearch -m avc -ts recent을 함께 확인하면 SELinux 레이블 문제인지 알 수 있습니다. container_t와 user_home_t가 언급된 AVC 메시지는 :Z이 누락되었음을 의미합니다.

호스트에서 요청이 거부됨. 서비스 active에 대한 curl: (7) Failed to connect to 127.0.0.1 port 11434: Connection refused은 보통 컨테이너 내부의 OLLAMA_HOST가 루프백 주소로 설정되었음을 의미합니다. 해당 줄을 제거하십시오.

생성 속도가 매우 느리거나 컨테이너가 강제 종료됨. GPU가 없으면 추론은 CPU에서 실행되므로 대형 모델은 본래 느립니다. 로그에 signal: killed이 기록되면서 요청 도중 컨테이너가 죽는다면 커널의 OOM(Out-of-Memory) 킬러가 작동한 것이므로, 위의 차트에서 더 작은 태그를 선택하십시오.

고정된 이미지 업데이트

이미지를 고정한다는 것은 업데이트가 자동으로 일어나는 것이 아니라 사용자가 직접 수행하는 작업임을 의미합니다. ollama.container 파일에서 Image=을 수정한 뒤, 설정을 다시 불러오고 서비스를 재시작하십시오:

systemctl --user daemon-reload
systemctl --user restart ollama.service
podman exec ollama ollama --version

모델은 바인드 마운트 경로에 저장되므로 이미지 변경 시에도 영향을 받지 않고 유지됩니다. [Container] 섹션의 AutoUpdate=registry은 유동적인 태그를 사용하는 사용자를 위한 설정입니다. 고정된 버전 태그를 사용할 때는 태그의 내용이 변경되지 않으므로 이 설정은 아무런 역할을 하지 않습니다. /home/ollama/ollama-data/models/manifests와 .container 파일을 백업하십시오. blobs 디렉터리는 용량이 크고 새로운 서버에서 ollama pull이 다시 내려받으므로 백업에서 제외해도 됩니다.

FAQ

루트리스(rootless) Podman 컨테이너가 로그아웃하면 왜 중단됩니까?

사용자의 마지막 세션이 종료되면 해당 사용자의 systemd 인스턴스와 /run/user/<uid> 디렉터리가 정리되며, 모든 루트리스 컨테이너도 함께 종료됩니다. sudo loginctl enable-linger ollama를 실행하여 loginctl show-user ollama --property=Linger이 Linger=yes을 출력하는지 확인하십시오. Quadlet 유닛을 생성하기 전에 링거링(lingering)을 활성화해야 합니다. 유닛이 필요로 하는 런타임 디렉터리는 링거링이 켜져 있어야만 존재하기 때문입니다.

Ollama 모델 디렉터리에 SELinux 레이블이 필요합니까?

Fedora, RHEL, Rocky 및 AlmaLinux에서 호스트 디렉터리를 바인드 마운트하는 경우, 그렇습니다. 컨테이너는 container_t 도메인에서 실행되는데 홈 폴더의 디렉터리는 user_home_t으로 레이블이 지정되어 있어 쓰기가 거부되고 Ollama가 종료됩니다. Volume= 라인에 :Z를 추가하고 전용 하위 디렉터리를 지정하십시오. 레이블 재지정은 재귀적으로 수행되므로 :Z을 홈 디렉터리 전체로 지정하면 해당 사용자의 SSH 키 접근이 차단됩니다. 명명된 볼륨(Named volumes)은 Podman이 올바르게 레이블을 지정하므로 추가 설정이 필요 없습니다.

Ollama 모델에는 어느 정도의 디스크 공간이 필요합니까?

ollama.com/library에 게시된 다운로드 크기를 기준으로 시작하십시오. gemma3:4b의 3.3 GB부터 qwen3:30b의 19 GB까지 다양합니다. 여기에 Podman 이미지 크기를 더하고 여유 공간을 확보하십시오. 두 번째 모델을 다운로드해도 첫 번째 모델이 디스크에서 자동으로 삭제되지 않기 때문입니다. 이미지를 가져오기 전에 df -h /home을 확인하고, 가져온 후에 du -sh ~/ollama-data/models을 확인하십시오. RAM도 동일한 방식으로 계획하십시오. 모델은 로드되는 동안 파일 크기만큼의 메모리와 컨텍스트 윈도우를 필요로 합니다.

VPS에서 11434 포트를 노출해도 안전합니까?

아니요. Ollama는 어떠한 인증 기능도 제공하지 않습니다. 따라서 해당 포트에 접근할 수 있는 사람은 누구나 모델 목록을 확인하고, 삭제하고, 새로운 모델을 디스크에 다운로드하며, 사용자의 CPU와 대역폭을 사용하여 추론을 실행할 수 있습니다. 또한 인터넷을 통한 일반 HTTP 통신은 모든 프롬프트와 응답을 평문으로 전송합니다. 호스트 측 포트를 127.0.0.1에 PublishPort=127.0.0.1:11434:11434으로 바인딩하고 ss -ltnp | grep 11434로 확인하십시오. 이후 SSH 터널이나 비밀번호 인증이 필요한 리버스 프록시를 통해서만 접근하도록 하십시오.

#ollama #podman #rootless#quadlet#selinux #systemd