Fix ownCloud Uploading Files Freezes at 99 Percent: Practical Troubleshooting Guide

An ownCloud upload that reaches 99 percent and then appears to freeze is usually not solved by repeatedly starting the upload again. At that point, the browser may have already transferred most or all of the file while the server is still completing work such as receiving the last chunk, assembling chunks, moving the completed file into its destination, updating metadata, or releasing locks. The percentage alone does not identify the cause, so the fastest approach is to check the server-side evidence in a fixed order.

This guide uses the current ownCloud Server 11.0 administration documentation available in October 2026. The same ideas apply to many ownCloud Classic deployments, but configuration paths and Docker behavior can differ on older releases. Before changing limits, confirm your installed version and deployment method.

ownCloud 파일 보기에서 대용량 파일 업로드가 99%에서 중단된 것으로 표시됩니다. — A file can appear stuck at 99 percent even though most data has already been transferred. Treat the percentage as a symptom, then check server-side evidence.

Quick diagnosis checklist

What to check	Why it matters	Strong clue
ownCloud, PHP, and web-server logs	The failure may occur after the browser finishes sending data.	Timeout, storage, WebDAV, locking, 5xx, or permission error at the upload time.
Temporary and upload-directory free space	Chunked uploads need temporary storage before finalization.	Large files fail while small files work, or the filesystem is nearly full.
User quota and destination storage	The final file still needs room in its destination.	Failure happens only for one user, folder, or external-storage target.
PHP upload and time limits	Non-chunked requests and supporting requests can be rejected or time out.	Errors mention request size, execution time, input time, or temporary upload files.
Session lifetime	A session that expires before a long upload finishes can interrupt completion.	Failures correlate with upload duration rather than file type.
Reverse proxy, CDN, or load balancer	An upstream component can impose its own body-size or timeout limit.	Direct access works but the public hostname through the proxy fails.
Transactional file locking	ownCloud locks files while file operations are committed.	Logs contain locking errors, especially under load or on clustered storage.

1. Reproduce once, then inspect the logs immediately

Do one controlled upload with a file that reliably reproduces the problem and note the exact time. Then inspect the ownCloud log, PHP log, and web-server error log around that timestamp. Do not make several configuration changes first; doing so makes it harder to know which layer actually failed.

ownCloud의 공식 문제 해결 문서에서는 PHP, Apache 및 ownCloud 로그를 먼저 확인하도록 명시적으로 권장합니다. 표준 Docker 배포에서 ownCloud는 Apache 및 PHP 출력이 컨테이너의 stdout/stderr을 통해 전달된다고 설명하며, 컨테이너 로그 다음에 .을 사용할 것을 제안합니다 docker compose logs owncloud -f.

로깅 제어 기능과 로그 파일 다운로드 버튼이 있는 ownCloud 관리 페이지 — 관리자 로그 보기는 업로드 제한을 변경하기 전에 증거를 수집할 수 있는 곳 중 하나입니다.

관리자 인터페이스에서도 ownCloud 로그를 확인할 수 있습니다. ownCloud 로그 및 구성 가이드 에는 설정 > 관리자 > 일반으로 이동하는 경로가 설명되어 있으며, occ configreport:generate더 자세한 구성 보고서가 필요한 경우 해당 옵션을 제공합니다.

어떤 로그 메시지를 확인해야 할까요?

요청 실패와 관련된 첫 번째 오류에 집중하고, 이후에 발생하는 모든 경고에 주의를 기울이지 마십시오. 유용한 범주에는 요청 시간 초과, 저장 공간 부족, 임시 파일 생성 또는 이름 변경 불가, 권한 오류, WebDAV 예외, HTTP 413/502/504 응답, 파일 잠금 실패 등이 있습니다. ownCloud 로깅 수준을 일시적으로 DEBUG로 높인 경우, 나중에 다시 원래 수준으로 되돌리십시오. ownCloud는 상세한 로깅이 서버 성능에 영향을 줄 수 있다고 명시하고 있습니다. 자세한 내용은 공식 로깅 구성 참조를 확인하십시오 .

업로드 실패 시 ownCloud 로그 항목을 보여주는 터미널 스타일 보기 — 업로드 실패가 발생한 정확한 시점의 로그 항목을 확인하십시오. 여기에 표시된 메시지는 예시일 뿐이며, 실제 서버 로그를 통해 문제를 진단해야 합니다.

2. 임시 보관 장소와 최종 보관 장소 모두의 여유 공간을 확인하십시오.

이는 99% 멈춤 현상을 해결하는 데 있어 가장 중요한 점검 사항 중 하나입니다. ownCloud Server 11.0에서는 업로드 시 여러 임시 영역을 사용할 수 있다고 설명합니다. PHP 업로드 임시 디렉터리에는 활성 청크를 저장할 공간이 있어야 하며, 사용자 업로드 디렉터리는 업로드가 완료될 때까지 파일의 청크를 저장합니다.

ownCloud 대용량 파일 업로드 문서 에 따르면 , 임시 PHP 공간은 동시 업로드 수에 청크 크기를 곱한 만큼 확보해야 합니다. 특히 대용량 단일 파일의 경우, 업로드 디렉터리에는 최종 파일 크기와 비슷한 크기의 임시 공간이 필요합니다. 이 공간은 파일 조립이 완료될 때까지 청크를 저장하는 데 사용됩니다. 업로드가 완료되면 ownCloud는 청크를 최종 위치에 저장하고 해당 디렉터리에서 삭제합니다.

터미널에 ownCloud 데이터 및 임시 디렉터리의 디스크 여유 공간 확인 결과가 표시됩니다. — ownCloud 데이터 디렉터리, PHP 임시 디렉터리 및 전용 청크 업로드 디렉터리가 포함된 파일 시스템의 여유 공간을 확인하십시오.

데이터 디렉터리, PHP 임시 디렉터리 및 를 통해 구성된 모든 위치가 포함된 파일 시스템을 확인하십시오 OWNCLOUD_DAV_CHUNK_BASE_DIR. 특히 대상이 외부 저장소인 경우 실제 목적지도 확인해야 합니다. 서버에는 여유 공간이 많지만 /별도의 데이터 볼륨이 가득 차 있을 수 있습니다.

업로드를 "완료"하기 위해 ownCloud 데이터 디렉터리로 파일을 수동으로 이동하거나 이동하지 마십시오. ownCloud는 데이터 디렉터리가 애플리케이션 전용이며, 직접 수정하면 동기화 및 데이터베이스 불일치가 발생할 수 있다고 경고합니다.

3. 기술적 제한을 늘리기 전에 할당량을 확인하십시오.

사용자 할당량으로 인해 업로드 스테이징 영역에 충분한 공간이 있더라도 대용량 최종 파일 업로드가 차단될 수 있습니다. 해당 사용자의 할당량을 확인하고, 필요한 경우 외부 저장소 마운트의 용량 및 권한을 확인하십시오. 충분한 공간이 있는 다른 계정이나 저장소에 동일한 파일을 업로드해 보는 것이 유용한 테스트 방법입니다. 업로드 실패가 파일이 아닌 사용자 또는 폴더와 관련된 경우, 할당량 또는 저장소 정책이 문제의 원인일 가능성이 높습니다.

4. PHP 및 ownCloud 업로드 설정을 검토합니다.

로그에 요청 크기 또는 실행 제한이 표시되는 경우 임의의 파일에 있는 값이 활성화되어 있다고 가정하기보다는 실제 PHP 설정을 검토하십시오 php.ini. 일반적인 지시문에는 post_max_size, upload_max_filesize, upload_tmp_dir, max_input_time, max_execution_time, 및 등 이 있습니다 memory_limit.

PHP 업로드 크기, 입력 시간, 실행 시간 및 메모리 설정을 보여주는 구성 편집기 — PHP 제한은 로그 또는 실제 구성에서 업로드 속도를 제한하는 것으로 나타날 때만 변경해야 합니다. 여기에 표시된 값은 예시일 뿐이며, 일반적인 권장 사항은 아닙니다.

지원되는 Dockerized ownCloud Server 11.0 구성의 경우, 문서에서는 이러한 항목을 환경 변수( OWNCLOUD_MAX_UPLOAD, OWNCLOUD_TEMP_DIRECTORY, OWNCLOUD_MAX_INPUT_TIME, OWNCLOUD_MAX_EXECUTION_TIME, 및 OWNCLOUD_MEMORY_LIMIT)에 매핑합니다. 이는 ownCloud에서 Docker 구성을 사용하는 배포 시 기존 PHP 또는 사용자 지정 패턴에 의존하는 대신 제공된 환경 변수를 사용해야 한다고 명시하고 있기 때문에 중요합니다 .htaccess.

업로드 관련 환경 변수가 포함된 ownCloud Docker Compose 서비스를 보여주는 편집기 — Docker 배포 환경에서는 업로드 관련 설정을 지원되는 환경 변수 구성에 저장하고 마운트된 임시 저장소의 용량이 충분한지 확인하십시오. 표시된 값은 예시입니다.

모든 제한값을 단순히 매우 큰 숫자로 설정하지 마십시오. 더 나은 목표값은 운영상의 안전을 유지하면서 최대 파일 크기와 가장 느린 합법적인 연결 속도를 모두 수용하는 값입니다.

5. 업로드 속도가 느린 경우 세션 지속 시간을 확인하세요.

ownCloud는 session_lifetime업로드 시간이 가장 오래 걸릴 것으로 예상되는 시간보다 짧아서는 안 된다고 명시적으로 경고합니다. 만약 사용자 지정 값을 설정했다면, 최소한 가장 느린 예상 업로드 시간에 필요한 시간(초) 이상으로 설정하거나, 불필요한 사용자 지정 값을 제거하고 지원되는 기본 동작으로 되돌리십시오.

특히 500MB 파일 다운로드는 완료되는데 수 기가바이트 파일 다운로드는 비슷한 시간이 지난 후 반복적으로 실패하는 경우 이 부분을 확인해 볼 가치가 있습니다.

6. 리버스 프록시 또는 CDN을 별도로 테스트하십시오.

ownCloud의 대용량 파일 관련 문서에 따르면 클라이언트 측 프록시 및 Cloudflare와 같은 서비스가 업로드를 제한할 수 있습니다. 즉, 완벽하게 구성된 ownCloud/PHP 스택이라도 다른 단계에서 요청 본문을 제한하거나, 긴 요청을 버퍼링하거나, 유휴 연결을 닫거나, ownCloud가 업로드를 준비하는 동안 시간 초과가 발생하면 업로드가 실패할 수 있습니다.

시스템 아키텍처에서 안전한 관리 테스트를 수행할 수 있다면, 일반적인 공용 경로와 리버스 프록시 또는 CDN을 우회하는 경로를 통해 동일한 업로드를 비교해 보세요. 직접 경로가 성공하면 해당 중간 서버의 공식 문서를 참조하여 요청 크기, 업로드 시간 초과, 버퍼링 및 WebDAV 동작 방식을 확인하십시오. 이 테스트를 수행하기 위해 TLS 보안을 약화시키거나 백엔드를 공개적으로 노출하지 마십시오.

대용량 업로드에 대한 웹 서버 시간 초과 설정을 보여주는 서버 구성 편집기 — 리버스 프록시 또는 웹 서버는 자체 타임아웃을 설정할 수 있습니다. 따라서 이는 해당 계층을 점검해야 한다는 점을 상기시키는 용도로만 사용하십시오. 지시어 이름과 허용 값은 실제 서버 스택에 따라 다릅니다.

7. 업로드 완료 중 오류가 발생할 경우 파일 잠금 여부를 확인하십시오.

트랜잭션 파일 잠금은 기본적으로 활성화되어 있으며 파일의 동시 변경을 방지합니다. ownCloud는 청크 업로드가 조립될 때도 잠금이 중요하다고 설명합니다. 사용량이 많은 서버에서는 전송이 완료되었지만 깔끔하게 커밋되지 못한 것처럼 보일 수 있습니다.

이 하위 시스템을 변경하기 전에 트랜잭션 파일 잠금 관련 문서를 검토하십시오 . ownCloud는 데이터베이스 잠금에 의존하는 대신 부하가 큰 작업 환경에서 메모리 캐시 백엔드를 사용하여 잠금을 처리하는 것을 권장합니다. 클러스터 환경에서는 모든 애플리케이션 노드가 동일한 잠금 상태를 확인해야 하므로 공유 Redis 잠금이 특히 중요합니다.

청킹이 적용되지 않는 경우, 공용 폴더에 매우 긴 파일을 업로드할 때 발생하는 특별한 상황에 대한 설명이 있습니다. ownCloud에 따르면, 1시간 이상 소요되는 업로드의 경우 충분히 큰 용량의 저장 공간이 필요할 수 있습니다 OWNCLOUD_FILELOCKING_TTL. 그렇지 않으면 Redis 가비지 컬렉션 과정에서 작업 시작 시 획득한 잠금이 해제될 수 있습니다. 업로드 경로가 이러한 상황에 해당하지 않는 한 이 설정을 변경하지 마십시오.

8. 변경 후에는 체계적으로 재시험하십시오.

ownCloud 업로드 패널에 대용량 ZIP 파일 업로드가 99% 진행된 상태로 표시되고 있습니다. — 서버 측 변경 후에는 여러 계층을 한 번에 변경하는 대신, 알려진 테스트 파일 하나를 반복 실행하고 결과를 기록하십시오.

확인된 문제를 해결한 후 동일한 파일, 계정, 대상 위치, 브라우저 및 네트워크 경로를 사용하여 다시 시도하십시오. 그런 다음 다음 세 가지 사항을 확인하십시오. 진행률이 완료되었는지, 파일이 예상 크기로 대상 위치에 나타나는지, 그리고 해당 요청에 대한 새로운 오류가 로그에 기록되지 않았는지 확인하십시오.

작은 파일, 중간 크기 파일, 그리고 마지막으로 처음 오류가 발생했던 파일 크기 순으로 진행하는 것이 유용합니다. 작은 파일은 항상 성공적으로 처리되지만 특정 크기 이상에서 오류가 발생하기 시작한다면 저장 용량 및 파일 크기 제한에 집중해야 합니다. 오류가 일정한 시간 간격 후에 발생하기 시작한다면 세션 및 시간 초과에 집중해야 합니다. 특정 호스트 이름이나 네트워크 경로에서만 오류가 발생한다면 프록시 및 로드 밸런싱에 집중해야 합니다.

하지 말아야 할 일

수 기가바이트에 달하는 업로드를 로그 확인 없이 계속 재시도하지 마십시오. 반복적인 업로드 실패는 시간을 소모하고 일시적으로 저장 공간을 차지할 수 있습니다.
ownCloud 데이터 디렉터리를 수동으로 수정하지 마십시오. ownCloud, WebDAV 또는 지원되는 관리 도구를 사용하십시오.
우선 파일 잠금 기능을 비활성화하지 마십시오. 잠금 기능은 데이터 무결성을 보호합니다. 대신 백엔드 문제를 진단하십시오.
PHP 설정이 하나의 설정 파일에 나타난다고 해서 반드시 유효하다고 생각하지 마십시오. 컨테이너, PHP-FPM, Apache 모듈 및 여러 INI 파일 위치에 따라 유효 설정이 다를 수 있습니다.
타임아웃 시간을 무한정 늘리지 마십시오. 요청을 종료하는 계층을 찾아 지원되는 최대 업로드 용량에 적합한 제한을 설정하십시오.

실질적인 의사결정 경로

간략한 실행 지침서가 필요하다면 다음 순서를 따르세요. 먼저 문제를 한 번 재현해 보고, ownCloud/PHP/웹 서버 로그를 읽고, 데이터, 임시 및 청크 저장소를 확인하고, 할당량을 검증하고, 유효 업로드 및 시간 설정을 확인하고, 세션 수명을 검사하고, 리버스 프록시/CDN을 우회하거나 검사한 다음, 트랜잭션 잠금 문제를 조사하세요. 이 순서는 위험한 구성 변경을 하기 전에 증거를 확보하고 발생 가능성이 가장 높은 인프라 제약 조건을 우선적으로 확인하는 데 도움이 됩니다.

중요한 점은 "99퍼센트" 자체가 오류 코드가 아니라는 것입니다. 이는 사용자가 문제를 발견한 위치를 나타낼 뿐, 어떤 구성 요소가 문제를 일으켰는지는 알려주지 않습니다. 확실한 해결책은 실패한 업로드의 타임스탬프를 서버의 저장소, 타임아웃, 프록시, 세션 또는 잠금 증거와 대조하는 것입니다.