[NAS 구축기 08] 시놀로지 NAS 문제 해결, 자주 겪는 실전 사례 정리

작성자:

시놀로지 NAS를 쓰다 보면 어느 순간 갑자기 막히는 상황이 온다. 접속이 안 되거나, 백업이 실패하거나, 설정을 분명히 저장했는데 권한이 여전히 막혀 있거나. 처음엔 당황해서 설정 화면을 이것저것 건드리게 되는데, 그렇게 하면 오히려 원인을 더 놓치는 경우가 많다. 이 글은 NAS 구축기 시리즈 여덟 번째로, 실제로 운영하면서 자주 마주쳤던 시놀로지 NAS 문제 해결 사례를 유형별로 정리한 것이다. 완벽한 매뉴얼이 아니라 “나는 이 순서로 봤더니 빨리 잡혔다”는 실전 경험에 가깝다.

처음 NAS를 쓰기 시작했을 때는 오류가 나면 무조건 설정부터 바꿨다. 그런데 그렇게 하니까 고쳐지는 게 아니라 오히려 문제가 꼬이는 일이 반복됐다. 결국 복구 시간을 줄여준 건 특별한 기술이 아니라, 확인하는 순서를 고정한 것이었다. 어떤 오류든 네트워크 → 권한 → 저장소 → 서비스 로그 순서로 훑으면, 대부분 중간 어딘가에서 원인이 잡혔다.

왜 설정부터 건드리면 안 되는가

NAS 오류는 보통 한 가지 원인에서 시작하지 않는다. 예를 들어 외부 접속이 안 되는 상황이라면, 공유기 IP 할당 문제일 수도 있고, 포트 포워딩이 풀렸을 수도 있고, DSM 방화벽이 막고 있을 수도 있다. 이 세 가지가 동시에 얽혀 있는 경우도 드물지 않다. 이때 섣불리 방화벽 설정을 건드리면, 원래 문제였던 IP 주소 변경은 그대로 남아 있으면서 방화벽만 헐거워지는 상황이 된다.

그래서 내가 정착한 방식은 “수정 전에 원인 후보를 먼저 나열하고, 가장 단순한 것부터 확인한다”는 것이다. 대부분의 문제는 복잡한 원인보다 단순한 실수에서 시작하는 경우가 훨씬 많다. NAS가 재부팅된 뒤 IP가 바뀐 것, 비밀번호 인증이 만료된 것, 디스크 용량이 꽉 찬 것. 이런 것들을 먼저 확인하고 나서 더 깊은 설정으로 들어가는 게 순서다.

유형 1 — 접속이 갑자기 안 될 때 확인 순서

외부에서든 내부에서든 NAS에 접속이 안 되는 상황은 생각보다 자주 온다. 이때 확인할 것들을 순서대로 나열하면 다음과 같다.

  1. NAS IP 주소가 바뀌었는지 확인한다. 공유기 DHCP 환경에서는 NAS나 공유기가 재부팅되면 IP 주소가 달라지는 경우가 있다. 공유기 관리 페이지에서 현재 NAS에 할당된 주소를 먼저 확인한다. 이게 제일 흔한 원인이다.
  2. 같은 네트워크 안에서 DSM 로그인 자체가 되는지 확인한다. 내부 접속은 되는데 외부 접속만 안 된다면, NAS 자체 문제가 아니라 공유기 포트 포워딩이나 DDNS 문제일 가능성이 높다.
  3. 포트 포워딩 설정이 살아 있는지 확인한다. 공유기 펌웨어 업데이트 이후 포트 포워딩이 초기화되는 경우가 있다. 특히 KT, SKT, LG 같은 ISP 제공 공유기는 업데이트 후 설정이 날아가는 일이 종종 있다.
  4. DSM 방화벽 규칙을 확인한다. 시놀로지 DSM 제어판 → 보안 → 방화벽에서 규칙이 의도치 않게 바뀌어 있는 경우가 있다. 특히 DSM 업데이트 이후에 확인하는 게 좋다.

외부 접속 문제는 변수가 많아서 한 번에 잡기 어려울 수 있다. 관련해서 흔히 하는 실수들을 따로 정리해둔 글이 있으니 같이 보면 도움이 된다. → NAS 외부 접속 안 될 때 가장 흔한 실수 5가지

유형 2 — 권한 오류가 반복될 때 보는 포인트

권한 문제는 겉으로는 설정이 다 맞아 보이는데 실제로는 접근이 막히는 상황이라 특히 헷갈린다. 여기서 자주 놓치는 부분이 사용자 권한과 그룹 권한의 충돌이다.

시놀로지 DSM에서는 사용자에게 직접 권한을 주는 방법과, 그룹에 권한을 주고 사용자를 그룹에 넣는 방법이 있다. 이 두 가지가 동시에 설정되어 있을 때, 서로 다른 권한이 충돌하면 더 제한적인 쪽이 적용된다. 예를 들어 그룹 권한에서 특정 폴더를 읽기 전용으로 막아뒀는데, 사용자 직접 권한에서 읽기/쓰기를 줬다면 실제 결과는 케이스마다 다르게 나타날 수 있다.

권한 문제를 확인하는 순서는 이렇다.

  • 제어판 → 사용자 및 그룹에서 해당 사용자가 어느 그룹에 속해 있는지 먼저 확인한다.
  • 공유 폴더 → 편집 → 권한 탭에서 사용자별, 그룹별 권한을 각각 확인한다.
  • 권한 수정 후에는 반드시 테스트 계정 또는 시크릿 브라우저로 실제 접근 가능 여부를 확인한다. 화면에 저장됐다고 뜨는 것과 실제 접근이 되는 것은 다를 수 있다.
  • ACL(고급 권한) 설정이 켜져 있는 폴더라면, 하위 폴더 단위로 별도 권한이 설정되어 있을 수 있다. 이 부분을 놓치면 상위 폴더는 열리는데 하위 폴더는 막히는 상황이 된다.

권한 문제에서 가장 많이 하는 실수는 “설정을 저장했으니 됐겠지”라고 넘어가는 것이다. 수정 직후 테스트하는 습관 하나가 나중에 생기는 혼란을 많이 줄여준다.

유형 3 — 백업 실패가 났을 때 원인 좁히는 법

백업 실패 알림이 뜨면 처음엔 꽤 당황스럽다. 그런데 원인은 생각보다 몇 가지로 좁혀진다. 내가 경험한 범위에서는 대부분 아래 세 가지 중 하나였다.

  1. 대상 저장소 용량 부족 — 백업 대상이 외장 드라이브든, 다른 NAS든, 클라우드든 용량이 꽉 차면 당연히 실패한다. 백업 실패 로그를 보면 대부분 첫 줄에 용량 관련 오류 코드가 나온다.
  2. 인증 만료 또는 비밀번호 변경 — 원격 백업 대상 서버의 계정 비밀번호를 바꿨거나, 클라우드 서비스 토큰이 만료됐을 때 발생한다. Hyper Backup 기준으로는 작업 편집 → 인증 정보를 다시 입력하면 해결되는 경우가 많다.
  3. 스케줄 충돌 또는 이전 작업 미완료 — 이전 백업 작업이 끝나지 않은 상태에서 다음 스케줄이 시작되면 충돌이 생긴다. 작업 로그에서 “이미 실행 중” 또는 “잠금 파일 존재” 같은 메시지가 나오면 이 경우다. 이때는 실행 중인 작업을 수동으로 종료하고 다시 시작하면 된다.

백업 로그는 Hyper Backup 앱 → 백업 작업 선택 → 로그 보기에서 확인할 수 있다. 오류 코드와 함께 발생 시간이 나오니, 그 시간대에 무슨 변경이 있었는지 같이 보면 원인 파악이 빠르다.

백업 관련해서 한 가지 더 짚자면, 백업이 돌고 있다는 것과 백업이 실제로 복구 가능한 상태라는 건 다른 얘기다. 가끔 복구 테스트를 해보는 게 중요한 이유다. 백업 파일이 존재해도 복구가 안 되는 상황은 실제로 생긴다.

유형 4 — 전송 속도가 갑자기 느려질 때

NAS 파일 전송 속도가 갑자기 떨어지면 제일 먼저 해야 할 것은 원인을 네트워크 문제와 디스크 문제로 나누는 것이다. 이 두 가지를 구분하지 않고 NAS 설정만 건드리면 해결이 안 된다.

네트워크 문제인지 확인하는 방법: 같은 파일을 유선 연결 PC와 무선 연결 기기에서 각각 전송해본다. 유선에서는 빠르고 무선에서만 느리다면 NAS 문제가 아니라 Wi-Fi 환경 문제다. 공유기와의 거리, 채널 간섭, 2.4GHz/5GHz 대역 선택 등을 먼저 점검한다.

디스크 문제인지 확인하는 방법: 스토리지 관리자 → 디스크에서 각 디스크의 상태를 확인한다. S.M.A.R.T. 검사 결과에서 재할당 섹터나 오류 카운트가 올라가 있으면 디스크 이상 신호일 수 있다. 이 경우엔 빠른 시일 내에 데이터 백업을 우선으로 해야 한다.

인덱싱 작업이 돌고 있는지도 확인한다. 시놀로지 DSM에서 파일 검색이나 미디어 서버를 쓴다면, 대용량 파일을 새로 추가했을 때 자동으로 인덱싱 작업이 시작된다. 이 작업이 돌면서 디스크 I/O와 CPU를 많이 잡아먹으면 전반적인 속도가 느려진다. 리소스 모니터에서 CPU와 디스크 사용률을 확인하면 바로 보인다.

유형 5 — Docker 컨테이너가 계속 재시작될 때

Docker를 NAS에서 쓰기 시작하면 컨테이너가 올라왔다가 바로 꺼지는 상황을 한 번씩 겪게 된다. 이때 가장 먼저 해야 할 것은 컨테이너 로그를 읽는 것이다. Container Manager(구 Docker 앱) → 해당 컨테이너 → 로그 탭에서 확인할 수 있다.

로그에서 자주 보이는 원인은 세 가지다.

  • 포트 충돌 — 이미 다른 서비스가 같은 포트를 쓰고 있을 때 발생한다. 로그에 “port already in use” 또는 “address already in use” 같은 메시지가 나온다. 이 경우 컨테이너가 사용할 포트를 다른 번호로 바꿔주면 된다.
  • 환경변수 누락 또는 오타 — 컨테이너 설정 시 입력한 환경변수(예: 시간대, 계정 정보, 경로 등)가 빠졌거나 잘못 입력됐을 때 발생한다. 로그에서 “missing required variable” 또는 특정 변수명과 함께 오류가 나온다.
  • 볼륨 경로 오류 — 컨테이너가 마운트하려는 NAS 폴더 경로가 존재하지 않거나 권한이 없을 때 발생한다. 경로를 다시 확인하고, 해당 폴더가 실제로 있는지, 접근 권한이 있는지 체크한다.

설정을 바꾸기 전에 로그 한 번 읽는 습관만으로도 시행착오가 확실히 줄어든다. 로그가 영어라서 읽기 어렵게 느껴질 수 있는데, 오류 메시지의 핵심 단어만 검색해봐도 대부분 해결 방법이 나온다. Docker를 NAS에서 처음 시작하는 방법은 다음 편에서 이어서 정리할 예정이다. → [NAS 구축기 09] 시놀로지 Docker 입문, 집에서 굴려본 운영 팁

문제 유형별 빠른 확인 체크리스트

위에서 다룬 내용을 한눈에 보기 쉽게 정리하면 아래와 같다. 오류가 생겼을 때 이 표를 기준으로 순서대로 확인해보면 시간을 많이 줄일 수 있다.

문제 유형 먼저 확인할 것 자주 나오는 원인
접속 불가 NAS IP 주소 변경 여부 DHCP 재할당, 포트 포워딩 초기화
권한 오류 그룹 권한과 사용자 권한 충돌 ACL 하위 폴더 별도 설정
백업 실패 로그 오류 코드 확인 용량 부족, 인증 만료, 스케줄 충돌
속도 저하 유선/무선 비교 테스트 Wi-Fi 문제, 디스크 이상, 인덱싱 작업
컨테이너 재시작 컨테이너 로그 확인 포트 충돌, 환경변수 누락, 경로 오류

오류 대응에서 자주 하는 실수들

경험상 NAS 오류 대응에서 반복적으로 보이는 실수 패턴이 몇 가지 있다. 나도 초반에 다 해봤던 것들이다.

  • 로그를 보지 않고 설정부터 바꾼다. DSM에는 꽤 자세한 로그가 있다. 제어판 → 로그 센터에서 시스템 로그, 연결 로그, 파일 전송 로그를 각각 볼 수 있다. 오류가 났을 때 로그를 먼저 보는 것만으로도 원인이 절반은 보인다.
  • DSM 업데이트 직후 설정 변경 사항을 확인하지 않는다. DSM 메이저 업데이트 이후에는 방화벽 규칙, 포트 설정, 패키지 상태가 바뀌는 경우가 있다. 업데이트 후에는 주요 설정을 한 번 훑어보는 게 좋다.
  • 백업이 돌고 있다는 것만 확인하고 복구 테스트는 안 한다. 앞서도 언급했지만, 백업 작업이 성공으로 뜬다고 해서 복구가 된다는 보장은 없다. 몇 달에 한 번이라도 실제로 파일 하나를 복구해보는 테스트가 필요하다.
  • 권한 수정 후 실제 테스트를 생략한다. 설정 저장 후 실제 계정으로 접근이 되는지 확인하지 않으면, 나중에 다른 사람이 접근 못 한다는 문제가 생겼을 때 언제부터 막혔는지조차 모르게 된다.

복구 속도는 경험보다 순서에서 나온다

NAS를 오래 쓴다고 해서 오류 대응이 자동으로 빨라지는 건 아니다. 같은 문제를 여러 번 겪어도 매번 당황하는 경우가 있다. 반면 처음 쓰는 사람이라도 확인 순서를 고정해두면 훨씬 침착하게 대응할 수 있다. 결국 중요한 건 오류를 본 경험의 양보다, 어떤 순서로 좁혀갈지 흐름을 갖고 있느냐다.

이번 글에서 정리한 유형들이 전부는 아니지만, 처음 NAS를 쓰는 분들이 자주 막히는 상황 대부분은 커버된다고 본다. 더 구체적인 상황에서 막히는 경우가 있다면, 오류 메시지 전체를 복사해서 검색하거나 시놀로지 공식 커뮤니티에서 찾아보는 것도 방법이다. 생각보다 비슷한 사례가 많이 올라와 있다.

폴더 구조나 공유 설정 쪽에서 먼저 안정화가 필요하다면 이전 편도 참고가 될 수 있다. → [NAS 구축기 07] 집에서 NAS 폴더 체계 안정화하는 방법

다음 편에서는 시놀로지 NAS에서 Docker를 처음 시작할 때 어떤 기준으로 접근하면 좋은지, 실제 운영 흐름을 기준으로 이어서 정리할 예정이다.

같이 보면 좋은 글

시리즈 글 모아보기

댓글 남기기