ownCloud에서 "WebDAV 인터페이스가 손상되었습니다" 오류를 해결하는 방법

ownCloud가 브라우저에서 로드되었지만 관리자 페이지에 "WebDAV 인터페이스가 작동하지 않습니다"라는 메시지가 표시되는 경우 파일 업로드, 데스크톱 동기화 및 파일 앱도 제대로 작동하지 않을 수 있습니다. 이 경고는 문제의 증상일 뿐 진단은 아닙니다. DAV 엔드포인트에 연결할 수 없거나, 잘못 재작성되었거나, 프록시 또는 보안 규칙에 의해 차단되었거나, ownCloud가 자체 공개 URL을 호출할 때 액세스할 수 없는 상태일 수 있습니다.

이 가이드는 ownCloud Classic Server 설치에 적용됩니다. ownCloud Infinite Scale은 아키텍처 및 배포 모델이 다르므로 Classic Server의 Apache 설정을 Infinite Scale 배포에 적용하지 마십시오. 아래 링크된 공식 페이지는 ownCloud Server 10.15 및 10.16, 그리고 Classic Server 11.0을 다루고 있으며, 해당 페이지에서는 문서화된 WebDAV 경로 및 Apache 요구 사항을 사용합니다. 다만, 정확한 관리자 경고 메시지는 버전에 따라 다를 수 있습니다.

참고: 아래 인터페이스 및 터미널 이미지는 개략적인 예시입니다. 호스트 이름, 상태 표시줄 및 표시되는 값은 예시일 뿐이며, 실제 설치 환경이나 테스트 실행 결과를 나타내는 것은 아닙니다.

WebDAV 경고는 무엇을 의미합니까?

WebDAV는 ownCloud가 동기화 클라이언트 및 관련 파일 작업을 위해 파일 목록을 표시하고 관리하는 데 사용하는 HTTP 기반 인터페이스입니다. 브라우저 로그인은 웹 인터페이스가 응답하는지 여부만 확인할 뿐입니다. WebDAV 요청이 경로, 메서드, 인증 헤더 및 HTTPS 연결이 온전한 상태로 ownCloud에 도달했는지 여부는 확인하지 않습니다.

먼저 오류가 외부적인 원인인지 아니면 ownCloud 자체 검사에서만 발생하는 문제인지 확인하십시오. 동기화 클라이언트 오류와 인증된 WebDAV 요청 실패는 DAV 경로 또는 인증 문제일 가능성이 높습니다. 클라이언트는 정상적으로 작동하지만 관리자 경고가 계속 표시되는 경우, 서버 자체에서 TLS 인증서를 포함한 공용 호스트 이름을 확인하고 연결할 수 있는지 테스트하십시오.

1단계: 정확한 URL을 기록하고 WebDAV를 직접 테스트합니다.

사용자가 브라우저에 입력하는 것과 동일한 호스트 이름과 설치 경로를 사용하십시오. 루트 도메인 설치의 경우, 현재 클래식 서버 DAV 경로는 일반적으로 다음과 같은 형식을 따릅니다.

https://cloud.example.com/remote.php/dav/files/USERNAME/

ownCloud가 특정 경로 아래에 설치된 경우, 해당 경로를 <head> 태그 앞에 포함시키세요 /remote.php(예: https://example.com/owncloud/remote.php/dav/files/USERNAME/). 본인의 계정 이름과 URL을 사용하십시오. 임의로 만든 호스트 이름을 테스트하거나 모든 설치가 동일한 하위 디렉터리를 사용한다고 가정하지 마십시오.

클라이언트 컴퓨터에서 인증된 PROPFIND 요청을 보냅니다. cURL을 사용하는 경우 사용자 이름만 전달하면 암호를 명령에 포함하는 대신 암호를 입력하라는 메시지가 표시됩니다.

curl -i --user USERNAME -X PROPFIND \
  -H 'Depth: 0' \
  'https://cloud.example.com/remote.php/dav/files/USERNAME/'

유효한 인증된 WebDAV 응답은 일반적으로 HTTP 헤더를 사용합니다 207 Multi-Status. `A`는 401단순히 자격 증명이 수락되지 않았음을 의미할 수 있으며, `B`는 404잘못된 경로 또는 프록시 경로 재작성을 403나타낼 수 있습니다. `C`는 액세스 규칙, WAF 또는 서버 정책을 나타낼 수 있으며, `C` 또는 `D`는 301클라이언트 302또는 자체 검사가 예상대로 따르지 않는 리디렉션을 나타낼 수 있습니다. 구성을 변경하기 전에 응답 헤더와 서버 로그를 읽으십시오. 명령 출력 결과를 공유하기 전에 사용자 이름, 쿠키, 토큰 및 공용 IP 주소를 삭제하십시오.

2단계: 서버가 자체 공개 URL에 접속할 수 있는지 확인합니다.

일부 설정 검사는 ownCloud 서버에서 구성된 공용 주소로 요청을 보냅니다. 노트북뿐만 아니라 해당 서버에서도 기본 DNS 및 HTTPS 검사를 실행하십시오.

getent hosts cloud.example.com
curl -I https://cloud.example.com/status.php

호스트 이름은 서버에서 접근 가능한 주소로 확인되어야 하며, HTTPS 요청은 인증서 이름, 신뢰 체인 또는 연결 오류 없이 완료되어야 합니다. DNS가 NAT 리플렉션(헤어핀 NAT라고도 함)을 지원하지 않는 방화벽을 통해 서버를 가리키는 경우, 외부 클라이언트는 정상적으로 작동하지만 내부 자체 검사는 실패할 수 있습니다. 이 경우 DNS 분할, 리버스 프록시로의 내부 경로 설정 또는 공급자 측 네트워크 조정이 적절할 수 있습니다. 네트워크 설계에 맞는 최소한의 변경 사항만 적용하십시오.

신뢰할 수 있는 도메인 항목은 ownCloud로 들어오는 요청에 대한 호스트 허용 목록입니다. 문서화된 구성 절차에 따라 사용자가 실제로 사용하는 호스트 이름만 추가하십시오. 임의로 내부 주소를 추측하여 추가하지 마십시오. 이 overwrite.cli.url설정은 일부 구성에서 명령줄/백그라운드 컨텍스트에서 사용하는 URL을 제어합니다. DNS, 라우팅 또는 TLS 문제를 해결하는 것을 대체하는 것은 아닙니다. 설정을 변경하기 전에 경고 메시지의 실제 의미를 확인하십시오.

3단계: Apache 재작성 및 디렉터리 설정 확인

Apache 설치의 경우, ownCloud의 수동 구성 가이드에서는 기본 제공되는 mod_rewrite` <hostname> AllowOverride All`을 사용할 때 ownCloud 디렉터리에 대한 .htaccess`<hostname>` 설정과 Apache 자체의 DAV 모듈이 애플리케이션 경로를 점유하지 않도록 하는 DAV 관련 Apache 설정을 권장합니다. 사용자 지정 사이트에 전체 샘플을 붙여넣기보다는 공식 가이드와 가상 호스트 및 디렉터리 블록을 비교해 보세요.

Debian 또는 Ubuntu 시스템에서는 로드된 rewrite 모듈과 Apache 구성 구문을 검사하십시오.

sudo apachectl -M | grep rewrite
sudo apachectl -t

재작성 규칙이 없는 경우, `--rewrite` 명령어를 사용하여 활성화한 sudo a2enmod rewrite다음 구성을 다시 검증하고 구문 검사가 통과된 후에만 Apache를 재로드하십시오. 경로가 <Directory>실제 ownCloud 웹 루트와 일치하는지, 그리고 구성 상위에서 재정의 규칙이 비활성화되어 있지 않은지 확인하십시오. ownCloud에서 생성된 재작성 규칙을 일반적인 재작성 레시피로 수동으로 교체하지 마십시오 .htaccess. 사용자 지정 규칙은 애플리케이션 경로를 손상시키거나 업그레이드 중에 손실될 수 있습니다.

4단계: 리버스 프록시, WAF 규칙 및 인증 헤더를 확인합니다.

웹 서버에 직접 호출했을 때는 엔드포인트가 정상적으로 작동하지만 공개 URL을 통해 호출했을 때는 실패하는 경우, 리버스 프록시 또는 로드 밸런서를 점검하십시오. 해당 프록시가 전체 경로를 유지하고 , 예상되는 호스트 및 HTTPS 정보를 전달하며, 필요한 경우 ` <up>` , `<up> `, `<up>`과 /remote.php/dav/같은 WebDAV 메서드를 허용하는지 확인하십시오 . 설치 접두사를 제거하거나 DAV 요청을 다른 백엔드로 보내는 프록시는 파일 작업이 실패하더라도 웹 UI는 정상적으로 작동하는 것처럼 보이게 할 수 있습니다.PROPFINDOPTIONSPUTMOVE

요청 실패 시점의 프록시, Apache/Nginx 및 ownCloud 로그를 검토하십시오. 웹 애플리케이션 방화벽(WAF) 또는 ModSecurity 규칙이 메서드 또는 요청 본문을 거부할 수 있습니다. 정확한 규칙 ID를 확인하고 영향을 받는 ownCloud 경로 또는 요청에 대한 예외를 생성한 후 다시 테스트하십시오. 경고를 없애기 위해 WAF를 전역적으로 비활성화하지 마십시오. FastCGI/PHP 핸들러 뒤에서만 DAV 인증이 실패하는 경우, 인증 헤더가 PHP로 전달되는지 확인하십시오. ownCloud 구성 노트에 이러한 유형의 문제가 설명되어 있습니다.

5단계: TLS 및 리디렉션 유효성 검사

WebDAV 클라이언트는 브라우저와 마찬가지로 유효한 HTTPS에 의존합니다. 인증서가 호스트 이름에 대해 유효한지, 필요한 중간 인증서가 포함되어 있는지, 그리고 ownCloud 자체 검사를 실행하는 서버 환경에서 해당 인증서가 신뢰되는지 확인하십시오. 브라우저는 cURL 또는 PHP에서 보고하는 인증서 문제를 숨기거나 별도로 신뢰할 수 있습니다. 이러한 문제를 해결하기 위해 인증서 검증을 비활성화하지 마십시오.

리디렉션 루프, 예기치 않은 HTTP-HTTPS 리디렉션 또는 DAV 경로에서 로그인 페이지나 일반 홈페이지로의 리디렉션이 발생하는지 확인하십시오. 브라우저의 기본 URL로 인해 리디렉션이 발생하는 것은 정상일 수 있지만, DAV 요청은 최종적으로 애플리케이션 엔드포인트에 도달해야 하며, 요청 메서드와 Authorization 헤더는 그대로 유지되어야 합니다. 프록시가 TLS를 종료하는 경우, ownCloud가 프록시의 문서화된 구성에 따라 올바른 전달 프로토콜과 호스트를 수신하는지 확인하십시오.

양쪽에서 수정 사항을 확인하십시오.

목표로 삼은 변경 사항 각각을 적용한 후에는 여러 단계를 한 번에 변경하는 대신 동일한 검사를 반복하십시오.

• 클라이언트 측에서 문서화된 DAV URL에 인증하고 응답이 예상되는 WebDAV 응답인지 확인합니다(일반적으로 207 Multi-StatusPROPFIND에 대한 응답).
• ownCloud 호스트에서 공개 호스트 이름이 제대로 확인되고 TLS 유효성 검사 오류 없이 HTTPS를 통해 인스턴스에 연결되는지 확인하십시오.
• ownCloud 관리자 개요를 다시 확인하고 로그에서 새로운 DAV, 프록시 또는 인증 오류가 있는지 검사하십시오.
• 웹 인터페이스 또는 지원되는 동기화 클라이언트에서 작은 파일 업로드, 이름 변경 및 다운로드를 테스트해 보세요.

클라이언트 요청은 정상적으로 처리되지만 경고 메시지가 계속 표시되는 경우, 서버 자체의 DNS, 라우팅, 인증서 신뢰도 및 구성된 공용 URL을 확인하십시오. 자체 검사와 클라이언트 검사 모두 실패하는 경우, 엔드포인트 경로, 재작성 규칙, 프록시 라우팅, 요청 메서드 및 인증 포워딩을 먼저 확인하십시오. 서버가 호스팅 제공업체에서 관리되는 경우, 타임스탬프, 익명 처리된 HTTP 상태 코드, 요청 경로 및 일치하는 로그 항목을 지원팀에 제공하십시오. 암호 또는 비밀 키가 포함된 구성 정보는 제공하지 마십시오.

버전별 지침을 확인하려면 ownCloud Server 10.15 Apache 설치 가이드 , ownCloud Classic WebDAV 액세스 문서 및 ownCloud WebDAV 인증 구성 참고 사항을 배포 환경과 비교하십시오 . 설치된 릴리스 및 배포 유형에 맞는 설명서를 따르십시오.