손상된 경로를 찾아 ownCloud WebDAV 동기화를 복원하세요

"WebDAV 인터페이스가 제대로 작동하지 않는 것 같습니다"라는 경고를 해결하려면 ownCloud의 DAV 엔드포인트에 접근 가능한지, 그리고 웹 서버가 메서드를 포함한 WebDAV 요청을 PROPFINDownCloud의 PHP 애플리케이션으로 전달하는지 확인하십시오. 올바른 변경 사항은 공개 URL을 Apache, Nginx 또는 리버스 프록시가 처리하는지에 따라 다릅니다. 설정을 수정하기 전에 엔드포인트를 테스트하여 문제가 발생하는 부분을 수정하십시오.

경고 메시지가 실제로 무엇을 테스트하는지 찾아보세요.

ownCloud Classic의 관리자 검사기는 파일 동기화 검사에서 WebDAV 인터페이스를 사용할 수 없을 때 이 경고를 표시합니다. 이는 대부분 웹 서버 또는 요청 경로 문제이며, 파일이나 데이터베이스가 손상되었다는 증거는 아닙니다. ownCloud Server 11의 공식 경고 참조 문서 에서는 이 문제를 서비스 검색 검사 /.well-known/caldav와 는 별도로 설명하고 있습니다 ./.well-known/carddav

공용 설치 경로와 일치하는 DAV 엔드포인트를 사용하십시오. 도메인 루트에서는 엔드포인트가 일반적으로 입니다 https://cloud.example.com/remote.php/dav. 하위 디렉터리에 설치한 경우, 예를 들어 와 같이 해당 디렉터리를 포함해야 합니다 https://cloud.example.com/owncloud/remote.php/dav. ownCloud Classic 10.16은 일부 데스크톱 및 파일 관리자 연결에 대한 호환성 URL도 제공합니다 /remote.php/webdav. 하지만 이전 클라이언트 URL과 최신 DAV 엔드포인트를 모든 구성에서 동일하게 사용할 수 있는 것은 아닙니다.

깊이가 0인 인증된 요청을 보냅니다 PROPFIND. 이 명령에서 샘플 호스트/경로와 사용자 이름을 바꿔야 합니다. Curl은 사용자 이름만 제공되므로 암호를 입력하라는 메시지를 표시합니다 -u.

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

WebDAV 응답이 성공적이면 일반적으로 207 Multi-Status다음과 같은 결과가 나옵니다. 다른 응답은 다음과 같은 단서로 해석하세요. 301또는 302는 리디렉션이나 정규 URL 문제일 수 있습니다. 401는 인증이 수락되지 않았음을 의미합니다. 404는 경로 또는 PHP 재작성 명령이 ownCloud에 도달하지 못했음을 의미할 수 있습니다. 또는 405는 501서버, 프록시 또는 보안 계층에서 DAV 메서드를 거부했음을 나타냅니다. 브라우저에서 URL을 열었을 때 로그인 페이지가 표시된다고 해서 WebDAV가 성공했다는 것을 의미하지는 않습니다 PROPFIND.

웹 서버 레이아웃에 따라 해결 방법을 선택하세요.

Apache: ownCloud의 재작성 규칙을 활성화 상태로 유지

표준 Apache 설치의 경우, 먼저 ownCloud에서 제공하는 .htaccess파일이 있는지, 그리고 Apache가 설치 디렉터리에서 해당 파일의 재작성 지시문을 허용하는지 확인하십시오. ownCloud 설치 프로그램과 업그레이드 프로세스는 이러한 규칙을 유지합니다. AllowOverride NoneApache가 이러한 규칙을 읽지 못하도록 차단하는 경우, ownCloud 디렉터리에 필요한 재정의를 허용하거나 해당 규칙을 가상 호스트 구성으로 이동하십시오. 첫 번째 옵션은 일반적인 단일 ownCloud 사이트에서 유지 관리가 더 쉽습니다. 정책에 따라 애플리케이션 디렉터리 외부에 구성이 필요한 경우에는 중앙 집중식 가상 호스트 규칙이 더 적합할 수 있습니다.

정상적으로 작동하는 설정 위에 일반적인 재작성 블록을 붙여넣지 마십시오. 해당 기능이 mod_rewrite활성화되어 있는지, 사이트가 올바른 ownCloud 문서 루트를 가리키는지, 그리고 요청이 /remote.php/davPHP 핸들러에 도달하는지 확인하십시오. Apache 설정을 변경한 후에는 다시 로드하기 전에 설정 테스트를 실행하십시오. Docker 기반 ownCloud Classic 11에서는 이미지가 내장된 Apache 설정을 관리합니다. 실행 중인 컨테이너 내부에서 생성된 파일을 편집하는 대신 이미지에서 지원하는 설정 및 환경 메커니즘을 사용하십시오. 자세한 내용은 ownCloud Server 11 문제 해결 문서를 참조하십시오 .

Nginx: ownCloud 서버 구성을 사용합니다.

Nginx는 Apache 파일을 읽지 않습니다 .htaccess. Nginx가 ownCloud를 직접 제공하는 경우, PHP 위치 처리 및 DAV 관련 라우팅을 포함하여 ownCloud 버전 및 설치 경로에 맞는 Nginx 구성을 사용하십시오. 최소한의 PHP 위치를 사용자 지정하면 웹 인터페이스는 제공되지만 /remote.php/dav404 오류가 발생하거나 잘못된 핸들러로 전달될 수 있습니다. 현재 사용 중인 서버 블록을 공급업체의 ownCloud 10.16 설치 문서 와 비교한 후 구성을 테스트하고 Nginx를 다시 로드하십시오. 정확한 지시문은 배포판, PHP-FPM 소켓, ownCloud가 도메인 루트에 있는지 하위 디렉터리에 있는지에 따라 다릅니다.

리버스 프록시: 경로, 메서드 및 공개 URL을 유지합니다.

프록시 서버가 HTTPS 연결을 종료하거나 `/etc/dispatch`와 같은 하위 경로를 라우팅하는 경우 /cloud, 전체 DAV 경로를 백엔드로 전달하고 PROPFIND` /dispatch` PUT, `/ MOVEdispatch`, `/dispatch` 와 같은 WebDAV 메서드를 허용하는지 확인하십시오 DELETE. 프록시 서버 또는 웹 애플리케이션 방화벽은 PHP 엔드포인트가 올바르더라도 특정 메서드를 차단할 수 있습니다. 공용 URL을 통해 전송된 요청과 신뢰할 수 있는 네트워크에서 백엔드로 직접 전송된 요청을 비교해 보십시오. 직접 액세스 시 207 응답이 반환되지만 공용 URL을 통한 요청이 실패하는 경우, 프록시 경로, 메서드 필터링, 리디렉션 및 인증 헤더에 집중해야 합니다.

ownCloud의 trusted_proxies프록시 주소는 실제 주소로만 설정하십시오. 자동 URL 감지가 실패할 경우, `<reverse-proxy>` , overwritehost` <reverse-proxy> `, `<reverse-proxy>` 설정은 공개 URL을 설명할 수 있지만, 차단된 DAV 메서드나 누락된 PHP 경로를 복구하지는 않습니다. 프록시 신뢰 설정이 잘못되면 클라이언트 주소 헤더가 위조될 수 있습니다. 토폴로지에 맞는 공식 리버스 프록시 구성 지침을 참조하십시오.overwriteprotocoloverwritewebroot

DAV 검색과 파일 액세스를 분리하십시오.

/.well-known/caldav`<a href="..."> ` 및 ` <a href="...">` URL은 캘린더 및 연락처 클라이언트가 서비스 엔드포인트를 검색하는 데 도움이 됩니다. 이러한 /.well-known/carddavURL은 ownCloud의 DAV 엔드포인트로 연결되어야 하지만, 연결 실패 시 파일 동기화 WebDAV 검사 오류와는 별도의 경고가 표시됩니다. 이러한 검색 리디렉션만 수정하면 동기화 경고가 사라지지 않을 수 있습니다. Apache의 경우, ownCloud에서 제공하는 규칙이 활성화된 경우 검색을 처리할 수 있습니다. Nginx 및 하위 디렉터리 배포의 경우, 이에 맞는 서버 구성이 필요합니다. ownCloud 공식 경고 지침 에 따라 각 URL과 리디렉션 대상을 개별적으로 확인하십시오 .

수리를 확인하세요

인증된 PROPFIND테스트를 공개 DAV URL에 대해 다시 실행하고 응답이 있는지 확인합니다 207 Multi-Status. 그런 다음 ownCloud 관리 페이지를 새로 고치고 데스크톱 클라이언트를 사용하여 간단한 동기화 테스트를 실행합니다. 요청이 여전히 실패하면 HTTP 상태 및 타임스탬프를 웹 서버, 프록시, PHP 및 ownCloud 로그와 비교합니다. ownCloud 설명서에 따르면 Docker 환경에서 애플리케이션 로그는 마운트된 로그 디렉터리에 있고 Apache 및 PHP 로그는 컨테이너 출력으로 전송되므로 docker compose logs owncloud이러한 오류를 찾는 데 도움이 될 수 있습니다.

ownCloud의 최신 설명서는 Classic 11.0과 10.16 버전을 모두 다루고 있으며, 설치 방법은 버전별로 다릅니다. Classic 11 설명서에서는 Docker를 지원하는 설치 방법으로 명시하고 있습니다. 배포된 버전의 설명서를 참조하고, 이전 버전의 Apache 또는 Nginx 코드 조각을 최신 컨테이너나 프록시 설정에 그대로 적용하지 마십시오.