# 현장 상황별 대응

- 먼저 오류 코드를 읽습니다. 같은 APPLY를 반복하지 않습니다.
- 모르는 오류라도 데이터를 지우거나 인증 검증을 꺼서 통과시키지 않습니다.
- 아래 명령의 HOST 경로는 서버가 선택한 INSTALL_ROOT로 바꿉니다.
- secret/raw env/DB를 채팅이나 지원 archive에 직접 첨부하지 않습니다.

## 1. Docker 권한 없음

뜻: 일반 사용자에게 daemon 읽기 권한이 없습니다. 설치가 망가졌다는 뜻은 아닙니다.
`sudo /opt/contextra/deployctl doctor`로 같은 읽기 검사를 합니다. 그룹은 [Host 준비](HOST_BOOTSTRAP.ko.md).

## 2. /backup 폴더가 있는데 저장소 오류

```bash
findmnt -T /backup/contextra/artifacts
lsblk -f
sudo /opt/contextra/deployctl storage show
```

예상 HDD UUID와 다르면 물리 mount부터 담당자가 복구합니다. 임의 mkdir 또는 root 허용으로 우회하지 않습니다.

## 3. IP가 바뀜

`ip -br addr`로 NIC를 보고 Web이 접근할 주소를 담당자와 확인합니다.
configure에서 site를 재등록하고 private env/로그인 광고주소/인증서 정합성도 담당자가 갱신합니다.
**site의 ai_ip 수정만으로 인증·Web 주소 전체가 자동 변경되지는 않습니다.** OS netplan은 도구가 수정하지 않습니다.

## 4. Port 사용 중

`sudo ss -lntp`로 확인합니다. 다른 서비스를 죽이거나 자동 포트 변경하지 않습니다.
Web과 합의한 새 port를 private 설정에 반영한 뒤 다시 계획합니다.

## 5. 모델 deserialize / 준비 실패

원본 ONNX/engine/manifest를 보존합니다. 대상 GPU, builder/runtime TensorRT, 입력dtype를 확인합니다.
A6000 엔진을 Blackwell로 그냥 복사한 경우를 먼저 구분합니다. profile 값을 무작위로 바꾸며 재시도하지 않습니다.

## 6. update 중 연결 끊김 / APPLY 후 실패

[Rollback과 중단 대응](ROLLBACK.ko.md)을 봅니다. CLI 중단과 실제 container 중단은 다릅니다.
`recover`는 상태를 보여주며 자동 작업 재생을 하지 않습니다.

## 7. 로그를 보내고 싶음

```bash
sudo /opt/contextra/deployctl collect-support --output /tmp/contextra-support-new.tar.gz
```

마지막 archive 경로를 담당자에게 전달합니다. raw container logs/환경변수는 의도적으로 수집하지 않습니다.
추가 원문 로그가 필요하면 담당자가 민감정보를 별도 검토한 최소 구간만 공유합니다.
지원 archive에는 IP·경로 등 운영 정보는 있을 수 있으므로 회사 내부의 승인된 채널로 전달합니다.

## 8. 도구가 지나치게 안전하게 멈춤

BLOCKED는 성공을 거짓 표시하지 않기 위한 것입니다. [오류 사전](ERROR_CATALOG.ko.md)의 다음 행동을 확인합니다.
제한을 삭제해서 통과시키는 대신 검토된 입력/새 release로 해결합니다.