IT·개발

시놀로지 DS716+ phpMyAdmin AH00141 오류 삽질기 — 근본 원인(커널 3.x)과 검증된 우회책까지

5월 16, 2026 2 min read

DS716+(DSM 7.1.1) 환경에서 phpMyAdmin Docker 컨테이너를 띄우려다 AH00141: Could not initialize random number generator 오류를 만났습니다. 결론부터 말씀드리면, 제 환경에서는 Docker로 끝내 해결하지 못했습니다. 다섯 가지 표준 해결책을 차례로 시도했지만 결과는 매번 동일했습니다. 원인은 파일 권한이나 옵션 문제가 아니라 커널 호환성의 벽이었습니다. 같은 오류로 시간을 쏟고 계신 분들이 조금 더 빨리 판단하실 수 있도록, 제가 거쳤던 과정을 있는 그대로 기록합니다.

1. 목표와 첫 번째 난관

목표는 간단했습니다. mariadb 이미지로 MariaDB 컨테이너를 올리고, phpMyAdmin을 붙여서 웹 브라우저에서 DB를 관리하는 환경을 만드는 것이었습니다. 나중에 데이터베이스를 다른 서버로 이식하기 쉽게 Docker 환경을 선호했습니다.

mariadb 컨테이너는 제가 만들어둔 Docker 네트워크 voca-net에 연결해 문제없이 생성됐습니다. (voca-net은 제가 임의로 붙인 이름입니다 — 환경에 맞게 변경하시면 됩니다.) 그런데 phpmyadmin 컨테이너를 실행하자마자 시작과 종료를 반복하는 무한 재시작 루프에 빠졌습니다. 컨테이너 로그를 열어보니 아래 오류가 끊임없이 찍혀 있었습니다.

AH00141: Could not initialize random number generator
phpMyAdmin Docker 컨테이너 로그에 반복 출력된 AH00141 난수 생성기 초기화 실패 오류

phpMyAdmin 컨테이너가 시작 직후 AH00141 오류를 뱉으며 종료되는 모습

“난수 생성기를 초기화할 수 없다” — 이 한 줄이 이후 한참의 삽질을 예고하고 있었습니다.

2. 표준 해결책 5종 시도 (Docker 마운트·권한 옵션) — 모두 실패

이 오류는 Docker 컨테이너가 호스트의 난수 생성 장치(/dev/random, /dev/urandom)에 접근하지 못할 때 발생한다는 설명이 일반적이었습니다. 검색을 통해 찾은 해결책들을 순서대로 시도했습니다.

기본 docker run 명령 구조는 아래와 같습니다. 아래 표의 각 옵션을 이 명령에 추가하거나 변형하는 방식으로 시도했습니다.

docker run -d \
  --name phpmyadmin \
  --network voca-net \
  -e PMA_HOST=mariadb \
  -p 8080:80 \
  phpmyadmin:latest
시도추가/변경 옵션결과
1-v /dev/urandom:/dev/random:ro (읽기 전용 마운트)실패. 동일 AH00141
2-v /dev/urandom:/dev/random (RW 마운트)실패. 동일
3-v /dev/random:/dev/random (직접 마운트, ro 포함 가능)실패. 변화 없음
4이미지 태그 변경: phpmyadmin:5.2실패. 동일
5--privileged 옵션 부여실패. 동일

시도 5의 --privileged는 컨테이너에 호스트 커널 기능 대부분에 대한 접근 권한을 부여하는 옵션입니다.

주의: --privileged 옵션과 -v /dev/random:/dev/random 직접 마운트는 보안상 호스트 시스템에 위험을 줄 수 있습니다. 일반 운용 환경에서는 권하지 않는 옵션이며, 원인 추적 단계에서만 실험적으로 시도한 것입니다.

이 옵션까지 부여해도 동일한 오류가 발생했다는 점이 중요했습니다. 파일 권한·디바이스 마운트 차원의 문제가 아닌 것이 명확해졌습니다.

3. 더 깊은 원인 — Apache getrandom() 호출과 커널 3.x 한계

다섯 번의 시도가 전부 같은 오류로 끝나자, 마운트 옵션이나 권한의 문제가 아닐 수 있겠다는 생각이 들었습니다. 로그를 처음부터 다시 천천히 읽어보니 AH00141 외에 다른 메시지가 눈에 걸렸습니다.

(38) Function not implemented라는 동반 코드가 함께 출력됐습니다. 38은 Linux errno 코드 중 ENOSYS에 해당하는 값으로, “커널이 해당 시스템 호출 자체를 지원하지 않는다”는 의미입니다. 단순히 접근 권한이 없는 게 아니라, 요청한 시스템 호출이 커널에 아예 없다는 신호였습니다. 이 숫자가 파일 접근 문제가 아닌 커널 레벨 문제라는 방향으로 시각을 바꿔준 단서였습니다.

추가 조사 결과, 최신 phpMyAdmin Docker 이미지(특히 Debian Bullseye 기반)에 포함된 Apache 웹 서버가 getrandom() 시스템 호출을 직접 요구한다는 것을 파악했습니다. Docker Hub 공식 phpMyAdmin 이미지 페이지(https://hub.docker.com/_/phpmyadmin)에서 지원 태그와 각 태그의 기반 OS를 직접 확인하실 수 있습니다.

여기서 핵심 포인트입니다. /dev/random을 마운트하면 해결될 것 같지만, 실제로는 그렇지 않습니다. Apache가 getrandom()을 호출할 때는 파일 시스템의 /dev/random을 경유하지 않고, 커널에 직접 시스콜(syscall)을 날립니다. 그래서 /dev/random을 아무리 마운트해도 커널 자체가 getrandom()을 지원하지 않으면 소용이 없습니다. 이것이 마운트 옵션 조합이 전부 실패한 이유입니다.

솔직히 이건 제가 직접 커널 코드를 열어본 게 아니라 검색으로 파악한 내용이라 확신은 못 하지만 — DS716+는 DSM 7.1.1이라도 내부 커널은 3.x 버전대입니다. getrandom() 시스템 호출은 Linux kernel 3.17.0부터 도입되었는데(Linux man 페이지), 만약 DS716+의 커널이 3.17 미만이라면, 이 시스콜 자체가 커널에 존재하지 않게 됩니다. 실제로 (38) ENOSYS 오류가 반복되는 제 경험은 이 가설과 정확히 맞아떨어졌습니다. 이 분석은 추정이며, 환경에 따라 다를 수 있습니다.

4. 구버전 이미지로 우회 시도

커널 호환성 한계를 우회하기 위해 구버전 이미지 phpmyadmin:4.9를 시도했습니다. 그런데 4.9라는 태그 자체가 Docker Hub에 존재하지 않았습니다. 4.9.x 형태의 세부 버전만 있다는 것을 뒤늦게 파악하고 phpmyadmin:4.9.11로 재시도했습니다.

터미널 기록을 그대로 옮겼는데, 당시 phpmyadmin을 phomvadmin으로 잘못 쳤나봅니다. 실제 시도한 이미지명은 phpmyadmin:4.9.11이 맞습니다.

Error response from daemon: manifest for phomvadmin:4.9.11 not found: manifest unknown: manifest unknown
phpmyadmin 4.9.11 이미지 다운로드 시도 중 manifest not found 응답을 받은 터미널 화면

구버전 태그(phpmyadmin:4.9.11) 다운로드 시도에서 manifest not found 응답

네트워크 이상인지 확인하기 위해 기본 진단을 진행했습니다.

  • ping 8.8.8.8 → 정상
  • docker pull hello-world → 정상
  • ping hub.docker.com → 실패 (단, hello-world는 정상 수신됐기 때문에, 이것이 직접적인 원인은 아닌 듯했습니다)

네트워크 자체는 이상이 없었습니다. 결론은 하나였습니다. phpmyadmin:4.9.11이라는 태그 자체가 Docker Hub에 존재하지 않는다는 것입니다. Docker 기본 연결은 가능해도 특정 태그가 없으면 pull이 불가능합니다.

5. 최종 권장 — 시놀로지 패키지 센터 phpMyAdmin

표준 Docker 해결책 다섯 가지와 구버전 이미지 우회까지 모두 통하지 않았습니다. 이 시점에서 방향을 바꾸기로 했습니다. 커뮤니티에서 DSM을 6 버전대로 낮춰 시도했다는 언급도 봤지만, DSM 다운그레이드는 데이터 손실 위험이 크기 때문에 저는 선택지에서 제외했습니다.

시놀로지 패키지 센터 공식 phpMyAdmin 패키지를 설치해 사용하는 것이 제 환경에서 가장 현실적인 선택이었습니다. 설치 경로는 간단합니다.

  1. DSM 메인 화면에서 패키지 센터 실행
  2. 검색창에 phpMyAdmin 입력 후 검색
  3. 목록에서 phpMyAdmin 선택 → 설치
  4. 설치 완료 후 DSM 메인 화면에 phpMyAdmin 아이콘이 생성되며, 클릭하면 바로 접근 가능합니다

Docker를 고집했던 이유는 데이터 이식성 때문이었는데, 그 부분은 mysqldump를 이용한 수동 마이그레이션으로 대체하기로 했습니다. 커널 호환성 한계 앞에서 Docker를 더 오래 붙잡기보다, 패키지 센터라는 안정적인 대안을 일찍 선택했다면 시간을 많이 아꼈을 것 같다는 생각이 남습니다.

마치며

구형 NAS에서 Docker를 쓸 때, 겉보기엔 디바이스 접근 권한 문제처럼 보여도 실제로는 커널 기능 부재가 원인인 경우가 있습니다. 그럴 때는 마운트 옵션과 권한 설정을 아무리 바꿔봐도 근본적으로 해결되지 않습니다. 제 경우 DS716+(DSM 7.1.1)이 그랬고, 결국 Docker phpMyAdmin 구동에 성공하지 못했습니다. “권한 문제”가 아니라 “커널 기능의 문제”라는 것을 더 일찍 파악했더라면 삽질의 범위를 많이 줄일 수 있었을 것 같습니다. 같은 오류로 고생하고 계신 분들께 조금이나마 도움이 되길 바랍니다.

PS: 향후 NAS를 초기화하게 되면 DSM 버전을 달리하여 Docker phpMyAdmin 재시도 결과를 별도로 정리해볼 생각입니다.

참고 출처

Tags: