버전 업그레이드 후 ownCloud "무결성 검사 실패" 오류 해결 방법

업그레이드 후 ownCloud에서 "무결성 검사 실패" 오류가 발생하는 경우, 파일을 변경하기 전에 무효 파일 보고서를 사용하여 실패 원인을 파악하십시오. 재검사는 단순히 검증을 반복하는 것이며, 누락된 파일을 복원하거나 사용자 지정 편집 내용을 되돌리거나 수정된 ​​앱 버전을 설치하지 않습니다. 핵심 파일의 경우, 업그레이드한 ownCloud 버전과 비교하십시오. 앱 서명 문제의 경우, 호환되고 올바르게 서명된 앱 업데이트를 찾거나 해당 앱 관리자에게 문의하십시오.

적절한 복구 방법은 경고의 범위에 따라 다릅니다. 부분 업그레이드 또는 혼합 버전 업그레이드 후에는 전체 설치를 교체하는 것이 더 안전할 수 있지만, 가동 중지 시간이 더 오래 걸리고 구성 및 사용자 데이터를 신중하게 보존해야 합니다. 확인된 핵심 파일 하나만 교체하는 것이 더 빠르지만, 해당 파일이 설치된 릴리스에 속하는지 확인할 수 있는 경우에만 가능합니다. 서명 유효성 검사를 비활성화하면 특정 앱을 사용할 수 있게 될 수 있지만, 보안이 저하되므로 일반적인 해결 방법이 아닌 문서화된 예외 사항으로 간주해야 합니다.

먼저, 무엇이 실패했는지 파악하십시오.

관리자 계정으로 로그인하여 관리자 페이지를 엽니다. 무결성 경고를 따라가면 유효하지 않은 파일 목록을 확인할 수 있습니다. 현재 ownCloud 문서에서는 보고서가 코어 파일이나 앱과 같은 구성 요소별로 문제를 그룹화하고 INVALID_HASH, FILE_MISSING, , EXTRA_FILE, 와 같은 레이블을 사용합니다 EXCEPTION. 이러한 레이블은 서로 다른 원인을 나타내므로 변경하기 전에 구성 요소, 경로 및 오류를 기록해 두십시오.

• INVALID_HASH이 오류는 파일의 현재 내용이 서명 데이터의 해시 값과 일치하지 않음을 의미합니다. 일반적인 원인으로는 부분적인 업그레이드, 이전 파일이 남아 있는 경우 또는 로컬 편집 등이 있습니다.
• FILE_MISSING이는 서명된 파일이 없음을 의미합니다. 불완전한 아카이브 압축 해제 또는 배포로 인해 이러한 문제가 발생할 수 있습니다.
• EXTRA_FILE이는 설치에 서명에 나열되지 않은 파일이 포함되어 있음을 의미합니다. 해당 파일은 실수로 남겨진 파일, 사용자 지정 파일 또는 검토가 필요한 합법적인 로컬 추가 파일일 수 있습니다.
• EXCEPTION이는 ownCloud에서 서명을 확인할 수 없음을 의미합니다. 보고서에는 서명 데이터가 누락되었거나, 인증서가 유효하지 않거나 취소되었거나, 확인을 완료할 수 없다는 내용이 포함될 수 있습니다.

추가 파일로 표시된다는 이유만으로 파일을 삭제하지 마십시오. 해당 파일의 기능과 추가한 사용자를 확인하십시오. 특히, signature.json경고 메시지를 없애기 위해 앱의 파일을 수정하지 마십시오. ownCloud의 코드 서명 지침에는 해당 파일을 수정하지 말라고 명시적으로 규정되어 있습니다.

증거에 근거하여 수리 방법을 선택하십시오.

ownCloud 11에서는 버전별 고려 사항이 추가되었습니다. 타사 앱을 설치, 업데이트 또는 활성화하려면 유효한 서명이 있어야 하며, 유효하지 않은 앱은 경고 표시만 되는 것이 아니라 차단될 수 있습니다. 2026년 10월 6일 기준으로 ownCloud 11.0 문서에 따르면 이전 서명 체계를 사용하는 앱은 2026년 12월 31일까지 경고와 함께 허용되며, 그 이후에는 새로운 PKI에 따른 서명만 신뢰할 수 있습니다. ownCloud 10.x 버전을 사용 중인 경우, 11.0의 적용 규칙이 적용된다고 가정하지 말고 사용 중인 정확한 버전의 문서를 참조하십시오.

설치 변경 전에 준비하세요

1. 업그레이드 프로세스에서 표시되는 현재 서버 버전과 대상 버전을 확인하십시오. 지원되는 PHP 버전을 포함하여 해당 릴리스 노트 및 시스템 요구 사항을 확인하십시오.
2. 데이터베이스, 구성 및 데이터 디렉터리의 최신 백업을 생성하십시오. 배포 방식에서 지원하는 경우 현재 코드 트리 또는 파일 시스템 스냅샷을 보관하십시오.
3. 복구 작업 중 코드 교체를 하기 전에 서버를 유지 관리 모드로 전환하십시오. 설치 환경에 맞는 방법을 사용하고, 작업 중에는 사용자가 파일을 작성하지 않도록 하십시오.
4. ownCloud가 어떻게 설치되었는지 확인하십시오(아카이브/수동 설치, 운영 체제 패키지 또는 Docker). 해당 설치의 업그레이드 절차를 따르십시오. 패키지 관리 설치에 tarball의 파일을 혼합하여 사용하지 마십시오.
5. 원본 보고서를 보관하고 이동하거나 교체한 모든 파일을 기록해 두십시오. 이렇게 하면 롤백 및 추후 문제 진단이 훨씬 쉬워집니다.

이러한 예방 조치는 중요합니다. 무결성 경고는 실행 가능한 애플리케이션 코드와 관련이 있는 반면, 데이터베이스 및 사용자 파일은 설치의 별도 부분이기 때문입니다. 이전 코드 디렉터리를 최신 패키지 관리 파일 위에 복원하면 그 자체로 불일치가 발생할 수 있습니다. ownCloud의 업그레이드 지침에서는 업그레이드 전에 최신 백업을 생성하고, 릴리스 노트 및 요구 사항을 검토하고, 타사 앱 호환성을 확인하는 것을 권장합니다.

부분 업그레이드 후 핵심 파일 복구

보고서에 index.php, version.php, 또는 코어 트리 아래의 파일과 같은 공식 코어 경로가 명시되어 있는 경우, 현재 실행하려는 정확한 버전의 공식 아카이브를 구하십시오. 단순히 최신 아카이브가 있다는 이유만으로 사용하지 마십시오. 무결성 해시는 특정 릴리스에 해당합니다.

사소하고 명확한 불일치의 경우, 보고된 경로와 해당 아카이브의 동일한 경로를 비교하십시오. 수정되지 않은 공식 파일임을 확인한 후, 웹 서버에 필요한 소유권 및 권한을 유지하면서 해당 파일만 교체하십시오. 여러 파일이 누락되었거나 일치하지 않거나, 또는 어떤 버전에서 라이브 파일을 제공했는지 확인할 수 없는 경우, 새 릴리스 디렉터리에서 클린 업그레이드하는 것이 일반적으로 더 안정적인 옵션입니다.

수동 아카이브 설치의 경우, 안전한 방법은 릴리스를 별도로 스테이징하고, 해당 파일을 보존한 다음, 공식 업그레이드 단계를 따라 코드를 제자리에 옮기는 것입니다 config. data아카이브 내용으로 사용자 데이터 디렉터리를 덮어쓰지 마십시오. 패키지 및 컨테이너 배포에는 자체 업데이트 절차가 있으므로, 수동 아카이브 방식을 적용하는 대신 해당 절차를 따르십시오. FTP를 사용하여 개별 파일을 전송하는 경우, ownCloud의 무결성 관련 문서에서 바이너리 전송 모드를 권장합니다.

앱 경고는 별도로 처리하세요.

보고서에 코어가 아닌 앱 이름이 표시되는 경우, 먼저 해당 앱이 사용 중인 ownCloud 버전을 지원하는지 확인하십시오. 서버 버전과 일치하고 유효한 서명이 있는 공식 또는 관리자가 제공한 릴리스를 설치하세요. 호환되는 릴리스가 없는 경우, 해당 앱을 비활성화하고 비활성화로 인해 필수 워크플로가 중단되지 않는지 확인하십시오. 앱을 제거하는 것은 더 영구적인 해결책이며, 해당 앱의 제거 지침을 따라야 합니다.

ownCloud 11에서 특정 앱에 대한 유효성 검사를 비활성화하는 것은 관리자가 제어하는 ​​예외 사항이며, 로그에 기록되지만 해당 앱의 무결성 및 권한 취소 보호 기능이 상실됩니다. 앱의 출처와 영향을 평가한 후에만 이 기능을 사용하고, 예외를 승인한 사람과 그 이유를 기록해 두십시오. 이는 손상되었거나 변조된 코어 설치를 복구하는 방법이 아닙니다. 이전 버전의 경우 적용 방식이 다를 수 있으므로 설치된 버전의 설명서를 참조하십시오.

새로운 검사를 실행하고 결과를 확인하십시오.

기본 파일을 수정한 후, 관리자 페이지에서 재검사 기능을 사용할 수 있다면 해당 기능을 사용하십시오. 문서에 설명된 occ검사를 실행할 수도 있습니다. Docker Compose의 경우, 현재 ownCloud 코드 서명 가이드에서 다음과 같은 예시를 제공합니다.

docker compose exec owncloud occ integrity:check-core
docker compose exec owncloud occ integrity:check-app calendar

calendar보고서에 명시된 앱 ID로 바꿔주세요 . 컨테이너 설치가 아닌 경우, occownCloud 디렉터리에서 웹 서버 사용자로 해당 파일을 실행하세요. 정확한 경로와 사용자 이름은 운영 체제 및 설치 방법에 따라 다릅니다. 문서화된 명령은 코어 또는 지정된 앱을 검사합니다. 현재 가이드에는 모든 앱을 수동으로 다시 검사하는 단일 명령은 없다고 나와 있습니다.

새 보고서에 수정된 파일 목록이 더 이상 표시되지 않고 관련 기능이 정상적으로 작동하면 복구가 완료된 것으로 간주합니다. 동일한 해시 오류가 다시 발생하는 경우, 자동 배포, 로컬 패치, 동기화 작업 또는 보안 사고로 인해 파일이 다시 변경되었는지 확인하십시오. 보고서에서 해지된 인증서, 누락된 앱 서명 또는 공식 릴리스에서 해결할 수 없는 버전 불일치를 지적하는 경우, 검사 반복을 중지하고 보고서와 정확한 서버 버전을 첨부하여 앱 관리자 또는 ownCloud 지원팀에 문의하십시오.

어떤 접근 방식을 사용해야 할까요?

보고서에서 공식 코어 파일이 하나만 식별되고 정확한 릴리스 버전을 알 수 있으며 해당 원본 파일을 구할 수 있는 경우, 특정 파일 교체를 선택하십시오. 여러 코어 파일에서 오류가 발생했거나, 업그레이드가 중단되었거나, 설치에 여러 릴리스의 파일이 포함된 경우, 클린 업그레이드를 다시 수행하십시오. 앱 관련 오류의 경우, 관리자 업데이트를 수행하거나 사용하지 않는 앱을 ​​비활성화하는 것이 좋습니다. 이렇게 하면 관련 없는 코어 파일을 교체하지 않고 영향을 받는 구성 요소만 해결할 수 있습니다. 서명된 대체 파일이 없고 운영상의 필요성이 무결성 보호 손실보다 중요한 경우, 특정 앱에 대한 유효성 검사 예외를 남겨두십시오.

다음 업그레이드를 진행하기 전에 먼저 릴리스 노트와 요구 사항을 검토하고, ownCloud에서 권장하는 대로 호환되지 않는 타사 앱을 비활성화하고, 최신 백업을 생성하십시오. 이러한 단계는 계획 시간이 필요하지만, 업그레이드 후 무결성 경고를 더 쉽게 진단하고 더 안전하게 복구할 수 있도록 해줍니다.

공식 참고 자료

• ownCloud 11.0: 코드 서명 및 잘못된 코드 무결성 메시지 수정
• ownCloud 10.15: 코드 서명 오류
• ownCloud 10.16: ownCloud Classic을 업그레이드하는 방법
• ownCloud 10.15: ownCloud 백업하기
• ownCloud 10.15: ownCloud 복원