마운트와 런타임 UID/GID를 먼저 확인한 다음, 근거가 있는 경우에만 소유권, 모드, ACL 또는 보안 레이블을 수정하여 이동된 Home Assistant 권한을 복구하세요.
데이터를 이동하면 파일 이름은 유지되더라도 숫자 식별자가 변경되거나, 숨김 파일이 누락되거나, 제한적인 ACL이 상속되거나, 잘못된 디렉터리가 컨테이너에 매핑될 수 있습니다. 재귀적 수정을 수행하기 전에 Home Assistant를 중지하고, 이동된 트리의 변경되지 않은 복사본을 보관하며, 이전 경로와 새 경로를 비교하세요. 처음부터 chmod 777을 사용하지 마세요. 진단 정보를 파괴하고 불필요한 접근 권한을 부여합니다.
쓰기 중지 및 이동된 트리 보존
Home Assistant 컨테이너와 동일한 데이터 디렉터리에 쓰는 모든 프로세스를 중지하세요. 현재 마운트 정의, 디렉터리 메타데이터, 컨테이너 식별 정보를 기록한 다음, 소유권이나 ACL을 변경하기 전에 스냅샷 또는 보호된 복사본을 만드세요. 물리적 또는 파일 시스템 수준의 복구는 되돌릴 수 있어야 합니다.
한 마이그레이션 계정은 Home Assistant 백업 데이터를 컨테이너 구성 디렉터리로 추출하는 과정을 설명하며, 복원된 구성 트리가 컨테이너의 영구 상태가 되므로 하나의 일관된 단위로 처리해야 함을 보여 줍니다.
PASS는 서비스가 중지되어 있고, 복구 대상 경로 외부에 변경되지 않은 롤백용 복사본이 존재한다는 뜻입니다. FAIL은 다른 컨테이너나 네트워크 클라이언트가 여전히 파일을 수정할 수 있다는 뜻입니다. 쓰기가 완전히 중단될 때까지 진행하지 마세요. 활성 데이터베이스나 레지스트리 업데이트 중에 소유권을 변경하면 두 번째 장애가 발생할 수 있습니다.
먼저 마운트와 전체 복사본 확인
새 호스트 경로 또는 볼륨이 Home Assistant에서 예상하는 정확한 컨테이너 경로에 매핑되는지 확인하세요. 소스와 파일 수, 주요 구성 파일, 숨겨진 저장소 데이터, 데이터베이스 존재 여부, 심볼릭 링크, 타임스탬프를 비교하세요. 비어 있거나 불완전한 디렉터리에 컨테이너가 마운트된 경우 권한으로는 복구할 수 없습니다.
Home Assistant 컨테이너 마이그레이션 관련 논의에서는 숨겨진 storage 디렉터리도 복사해야 하며, 모든 파일이 이동되었는지 확인한 후에만 권한을 점검할 것을 권장합니다. 이 전체 복사본 확인은 가장 비침습적인 첫 번째 판별 방법입니다.
마운트나 복사본이 잘못되었다면 모드를 변경하지 말고 이를 수정한 뒤 다시 비교하세요. 완전하다면 숫자 식별자를 확인하세요. 잘못 비어 있는 경로에서 Home Assistant를 시작하면 원래 트리를 가리는 새 파일이 생성될 수 있으므로, 잘못된 마운트에서 확인된 테스트 산출물만 삭제하세요.
숫자 UID와 GID 일치
이전 트리, 새 트리, 비어 있는 테스트 마운트에서 의도한 컨테이너 식별자로 생성한 임시 파일의 숫자 소유자와 그룹을 확인하세요. 호스트마다 사용자 이름은 다를 수 있지만 접근을 제어하는 것은 숫자 ID입니다. 문서화된 식별자로 컨테이너를 실행할지, 관리 대상 트리의 소유권을 변경할지 결정하세요.
Home Assistant와 HACS에 영향을 준 권한 문제는 쓰기 가능한 사용자 디렉터리를 일치시켜 해결되었으며, 해당 보고서는 소유권 불일치로 구성 변경이 차단된 과정을 기록합니다. 범위가 지정된 Home Assistant 소유권 사례는 시스템별 해결 방법을 보편적으로 복사하라는 뜻이 아니라, 숫자 식별자를 근거로 사용해야 함을 뒷받침합니다.
서비스가 중지된 상태에서 확인된 Home Assistant 관리 대상 트리에만 소유권을 변경하세요. 의도적으로 다른 서비스가 소유한 파일은 보존하고, 트리 외부의 심볼릭 링크를 따라가지 마세요. 계속하기 전에 루트, 숨겨진 저장소, 사용자 지정 구성 요소, 데이터베이스 경로에서 일부 항목을 다시 확인하세요.
모드, ACL, 보안 컨텍스트를 좁은 범위에서 복구
정상적으로 작동하는 소스 또는 플랫폼 기준과 디렉터리 실행 비트, 파일 읽기 및 쓰기 비트, 기본 ACL, 마운트의 읽기 전용 플래그, SELinux 또는 AppArmor 레이블을 비교하세요. 처음으로 불일치한 계층을 수정한 다음, 런타임 식별자로 격리된 생성–이름 변경–삭제 테스트를 다시 수행하세요.
배포 식별자를 이해하지 못한 채 일반 포럼 답변의 권한 완화 명령을 그대로 복사하지 마세요. 광범위한 재귀 접근 권한은 시작을 성공하게 만들 수 있지만, 비밀 정보를 노출하고 새로 생성되는 파일의 설정을 일관되지 않게 만들 수 있습니다. 필요한 런타임 작업을 허용하는 가장 제한적인 소유자 및 그룹 권한을 사용하세요.
PASS는 런타임 테스트가 성공하고 새 파일이 의도한 소유자, 그룹, 모드, ACL, 컨텍스트를 상속한다는 뜻입니다. 올바른 Unix 권한을 적용한 뒤에도 FAIL이면 읽기 전용 마운트 또는 필수 접근 제어 정책을 의심해야 합니다. 일반 모드를 더 넓히지 말고 해당 계층을 복구하세요.
한 번 시작하고 원래 작업 부하 검증
Home Assistant를 한 번 시작하고 가장 먼저 발생하는 권한 또는 경로 오류를 확인하세요. 구성 로드, 숨겨진 레지스트리, Recorder 쓰기, 가정에서 사용하는 사용자 지정 통합, 백업 또는 미디어 경로, 그리고 한 번의 재시작을 검증하세요. 부차적인 오류를 숨기기 위해 서비스 실행 중 레지스트리 파일을 편집하지 마세요.
ZimaSpace 백업 워크플로는 원시 파일 시스템 복사에서 쓰기를 중지하면 일관성이 향상되는 시점을 설명합니다. 이동 또는 권한 복구를 반복할 때는 서비스 중지 기준을 사용하세요.
PASS는 두 번 시작한 후에도 원래 기능이 읽기와 쓰기를 수행하고 새 객체가 예상한 식별자를 유지한다는 뜻입니다. 오류가 늘어나거나, 데이터베이스에서 손상이 보고되거나, 복구된 트리가 예상되는 런타임 파일을 넘어 보존된 복사본과 달라지면 롤백하세요. 파일 시스템 I/O 또는 보안 정책 거부는 정확한 경로와 컨텍스트를 포함하여 에스컬레이션하세요.
지원 및 팁
더 읽어보기

Home Assistant가 Wi-Fi에서는 작동하지만 이더넷이나 VPN에서는 작동하지 않음
각 네트워크 경로를 개별적으로 테스트하고, 인터페이스와 라우팅 상태를 확인한 다음, 직접 IP 연결과 검색 기능을 구분하여 실패한 계층만 복구하세요.

보호되지 않은 데이터를 남기지 않고 Home Assistant를 폐기하는 방법
교체 또는 보관을 입증하고, 모든 신뢰 경로를 폐기하며, 데이터를 저장하는 각 장치를 안전하게 삭제하고, 문서화된 보호 복구 사본만 보존하세요.

홈 서버에서 Home Assistant 자동 업데이트를 사용해야 할까요?
가정에 미치는 영향, 호환성 위험, 관찰 시간, 복구 준비 상태를 고려해 수동 업데이트, 알림만 제공, 또는 단계적 자동 업데이트를 선택하세요.

