imnas

LetITgo님, 일전에 문제해결 차원에서 꼼꼼한 접근을 시도하니 어떤 분은 화를 내시는 경우도 있더군요. 상대방에 대한 인식공격도 아니고 관련 주제에 대해서 자유롭게 대화하자는 의도임에도 화를 내는 경우가 있어 사실은 조심스럽습니다만, 양해해 주세요.^^ PC에 마지막남은 기계적 장치인 하드디스크는 제가 생각했던 것 이상의 최첨단기술이 집약되어져 있고, 단위면적당 더 많은 정보 기록을 위해 관련 엔지니어들어 엄청난 노력을 진행하고 있나봅니다. 이번 기회에 보니 우리가 쉽게 생각해서는 안된다는 생각이 들더군요. NAS용 HDD라 해서 하드웨어적으로 특별한 것이 뭐가 있겠느냐, 동일한 '플레터'에 소프트웨어적인 기술 차이가 아니겠느냐 이렇게 생각할 수 있을지도 모를 것입니다.(하드웨어적인 차이가 없다거나 미세하다는 의미로) 과연 동일한 '플레터'에 소프트웨어 기술만 가지고 성능 + 안정성 + 내구성을 향상시킬 수가 있고, 이것만으로 NAS용 HDD라 할 수 있을까 생각해 보았습니다. Brian Beeler라는 사람의 글을 보면, 일반 데스크톱 HDD와 NAS HDD의 하드웨어적인 차이를 설명하고 있습니다. http://www.storagereview.com/pick_the_r ... sktop_hdds 저희가 관련분야 엔지니어가 아니기 때문에 글 전체를 이해하는 것에는 무리가 있겠으나, 위의 글에 비교표를 보면 데스크톱 HDD의 Usage가 8x5, NAS HDD는 24x7일이라는 것을 보아 8시간씩 주 5일 사용과 연중무휴 사용을 구분하고 있으며, Base Plate(하드디스크의 몸통이랄 수 있는) 항목에는 Standard와 Structural Rigidity로 구분하기도 합니다. 이는 쇠붙이의 구조적 강성차이가 있다는 것으로 이해가 되네요. 그 외에 'Motor/Spindle/Case Design'를 보시면 센서와 부품들에 대해서도 다루고 있습니다. 데스크톱 HDD나 NAS HDD나 동일한 플래터에 하드웨어적으로 센서 정도(?) 달렸기에 겨우 그정도의 차이라 할 수는 없는 것 같네요. 하드디스크라는 것이 회전 역학에 따른 진동으로 내구성에 지대한 영향을 끼치기 때문에 하드웨어적으로나 소프트웨어적으로 여러기술들이 접목된다고 할 수 있습니다. LetITgo님 덕분에 저도 공부 좀 하네요.^^

LetITgo님 반가워요.^^ 앞서 작성한 제글은 아쉽게도 기술적 접근보다는 경험에 의해 단순한 사용시간 대비, NAS가 한시적 또는 상시적이냐에 따라 데스크톱 HDD나 NAS HDD의 여부를 언급한 것에 불과합니다. 일반 사용자들이 디테일한 기술적 접근은 어렵더라도 내구성면에 왜 NAS용이 좋은지는 대충 알고들 계실 것이라 생각합니다. 또한 일반적인 유저들은 대부분 HDD의 수명을 보증기간 이상의 시간을 기대하는 경우가 흔하며, 하드웨어에 문외한인 일반적인 주변 분들 대부분 HDD를 반영구적 장치로도 생각하는 경우도 있더군요. 이러한 상황에서 HDD의 고장으로 상처(?)를 받기도 하던데, 유지관리 면에서 마음 편하게 보증기간 이상을 경과하게 되면 개비할 마음의 준비를 하는 것이 좋은 것 같다는 취지의 글이었습니다.^^ 따지고 들자면, LetITgo님 말씀이 백번 옳죠. 덕분에 좋은 공부를 하게되는데요. 저도 다시한번 관련 내용을 확인해 보았습니다. 그런데 말씀 중에 제가 확인한 사항과 달리하는 부분이 있군요.^^ 하드디스크를 단순하게 데스크톱 HDD와 NAS용 HDD로 구분하면 하드웨어는 동일하고 소프트웨어 차이라 하셨는데, 제가 확인해 본 결과와는 다른 내용입니다. 왜냐하면, NAS용 HDD라고 하더라도 실제로 회전 진동관련 RV센서와 TCA 모터를 가진 제품이 라인업에 따라 존재하기도 합니다. 물론 1~5베이의 NAS 시스템 구성에 주로 사용하는 유명 벤더들의 라인업은 소프트웨어 기술만으로 안정성과 퍼포먼스를 지향하기도 하지만 꼭 엔터프라이즈급 라인업이 아니라도 적용된 제품을 쉽게 찾을 수 있습니다. WD 4TB Red WD40EFRX (1GB당 49원) - NAS용으로 NASWare 기술만 적용 됨 HGST 4TB Deskstar NAS HDN724040ALE640 (1GB당 45원) - RVS 센서, TFC 센서 장착 ( 다나와 확인 결과, 3TB 용량도 역시 WD보다 HGDT가 저렴한 제품이 있군요.) 펌웨어가 RPM을 작동시킨다기 보다는 보다 정교한 2-플랜 밸런싱을 위해서 7200 RPM 보다는 낮게 의도된 디자인이라 할 수 있는데요. 하드웨어적으로 RV, TFC 센서가 장착된 제품이 오히려 더 장점이 있음에도 단위용량당 가격이 오히려 더 저렴한 제품도 있네요. 요즘 보면 WD 제품에 힘을 실어주는 개인이나 사설 커뮤니티들이 있던데요.^^ 물론 WD 제품이 타사에 비해서 성능이 우수하면 이의가 없습니다만 어떤 객관적인 자료가 있나 모르겠네요. 자료 확인이 용이해서 시게이트를 확인해 보니, 드라이브 베이의 수로 라인업을 구성하나 보네요. 하드디스크가 많을수록 가중되는 진동의 상관관계로 인해서인가 봅니다. 1. 1~5 베이는 가정용 NAS, 백업, 미디어, 인쇄 또는 웹서버로 분류(재미있게도 24/7이 빠져있네요.^^) - 2-플랜 밸런스 2. 6~8 베이는 24/7, 중소기업 NAS, 대용량 데이터 스토리지, 백업/리치 미디어 스토리지 - RV 센서 3. 9베이 이상은 24/7, 엔터프라이즈 대용량 데이터, 중앙집중식 NAS, 백업/복구, 비디오 편집 - TFC 센서 결론적으로 NAS용 하드디스크는 소프트웨어 기술만 적용되는 것이 아닌, 하드웨어적인 차이가 있다고 할 수 있겠네요.

NAS를 구축하면 저장 용량이 자꾸 부족해지게 되죠. 저도 예외가 아닌데요. 최근 하드디스크를 추가 구입하려고 다나와에 갔다가 유명 하드디스크 벤더측(s)의 답변 중에 데스크톱 HDD는 "1일 8시간 사용을 기준으로 생산된 것" 이라는 코멘트를 보게되었습니다. 2년 보증기간으로 계산해 보면 ... 8시간 * 365일 * 2년 = 5,840시간 위에 근거해서 2년 보증기간이라는 것이 결국 5840시간 보증한다는 것이네요.^^ 3년 보증기간이라면 2920시간을 더해서 8760시간이 됩니다. 일반 가정에서는 데스크톱 컴퓨터가 하루 8시간 돌아가는 경우는 아마도 주말에 밤새워 게임을 한다든지, 학생들 방학기간이 일텐데요. 이런 경우는 아무래도 일반적인 사용과는 달리 '빡세게' 사용하는 경우라고 할 수 있겠죠. 물론 NAS용으로 사용하는 것도 여기에 포함이 될 것입니다. 그렇다면 만약 데스크톱용 하드디스크를 24시간 돌아가는 NAS용으로 사용한다치고 사용시간을 일수로 계산을 하면 .... 5840 / 24 = 243일 8760 / 24 = 365일 위에서처럼 단순 사용시간만 가지고 계산한다는 것도 불합리한 측면이 있겠지만 대략적인 감은 잡을 수 있죠. 실제로 오랜기간 S사측 하드디스크를 사용해 본 경험에 의하면 1만시간 이하에서 고장나는 경우는 그렇게 흔치는 않더군요. 개인적으로 사용하고 있는 하드디스크 중에는 2만 시간 또는 3만 시간이 넘은 경우가 종종 있습니다. 시간상으로 '빡세게' 돌아간 셈인데요. 1일 24시간 사용으로 계산해 보면 ... 20,000 / 24 = 833일, 2년 초과 30,000 / 24 = 1250일, 3년 초과 (거의 수명을 다했다 생각하고 큰 기대는 하지 않는 것이 좋을 듯합니다. 백업용으로 사용하면서 고장나면 바로 교체할 수 있도록 마음의 준비(?)를 하는 것이 현명한 것 같습니다.) 데스크톱이 1일 8시간 사용을 기준으로 생산된 것인 반면에 NAS용은 24시간 사용이 전제되겠지요. 보증기간이 3년이라 했을 때 ... 24시간 * 365일 * 3년 = 26,280시간 보증기간으로 계산한다면 3년 즉, 최소 2.6만 시간을 버티어 주어야 NAS용이라 할 수 있겠는데요. 데스크톱용과 마찬가지로 보증기간 안에 고장나는 경우는 그렇게 흔치는 않을 것입니다. 기대수명을 데스크톱 2년, NAS용 3년이라할 때 편견인지 모르겠으나 이 기대수명 기간을 초과하게 되면 의외로 더 오랜기간 사용이 가능하다는 생각인데요. 결론적으로 NAS를 데스크톱처럼 필요할 때마다 운용한다면 데스크톱용 하드디스크로, NAS/서버처럼 24시간 운용한다면 NAS용이나 서버용을 사용하는 것이 바람직하다는 것이 저의 어리석은 생각입니다.^^

'엑스피이놀로지 팀'에서 기존 장치들에 대한 드라이버들을 꾸준히 제공하는 상황이라기 보다는 사용자들의 피드백이나 니즈에 따른 것이 아닌가 합니다. 호환목록 하단에서 아래와 같이 당부하는 듯이 ... 작동을 하건 안가건 사용자들이 장치에 대한 경험을 피드백을 통해 적극 공유한다면 '엑스피이놀로지 팀'에서도 좀 더 다르지 않을까 합니다만 .... 국내의 사정만 하더라도 필요한 정보만 가져가지 뭔가 '엑스피이놀로지 프로젝트'에 대한 참여는 전무한 사정이라 할 수 있네요. 국내에서는 '엑스피이놀로지'가 무슨 불법 소프트웨어처럼 오인받아 그런지 아예 포럼 활동 조차도 저조하네요. 본 포럼에서 보면 엑스피이놀로지 사용자가 미국, 러시아, 프랑스, 독일과 같은 주로 선진국들의 섹션이 활동화되어 있지만, 중국도 우리나라 만큼 굉장히 저조합니다. 중국이 불법 소프트웨어를 사용하지 않는 나라(?)라서 그런지가요? NAS 장치에 대한 이해나 필요성이 부각되지 않는 상태라서 그렇겠죠. 반면, 우리나라는 IT 강국, 강국 하면서도 참 ... 의외로 사용자가 많을 것이라 예상됨에도 오히려 XPEnology가 사설 커뮤니티의 NAS 포럼만도 못한 상황이라 하드웨어 관련 정보를 접하기가 굉장히 힘든 상황이네요. XPEnology에 대한 정보가 한 곳으로 집중화되지 못하고, XPEnology 사용자 스스로에게 도움되지 않아 안타깝습니다.

ESXi의 버전에 상관없이 아래와 같은 부팅실패가 이슈인가 보네요. 원인을 찾다가 제경우는 강제로 덮어 씌워 버렸더니 설치가 되길래 그런줄 알았습니다만, 간단히 해결이 가능합니다. 위와 같이 부팅에 실패할 경우 VM 자체를 강제로 전원 off시키고 다시 부팅해 보세요. 무슨 말인가 하면 .... 1. ESXi에서 VM을 생성을 하고 XPEnology를 설치하기 위한 준비가 완벽히 끝난 상태에서 시작됩니다.(vmdk 커스터마이징) 2. 어시스턴트를 실행해서 XPEnology 설치를 시작합니다. 3. admin 비밀번호를 입력하고, SHR에 언체크합니다. 4. 지정된 IP가 사용 중이지 않다면 설치에 들어갑니다. 5. 1, 2, 3, 4단계가 진행이 되고 마지막 5단계에서 DSM 구성을 쓰기 위해서 재부팅을 하게 되는데요. 이 때 위에서 처럼 VM 부팅시 missing operating system 에러가 발생하면, 그대로 VM을 꺼줍니다. 6. 어시스턴트가 부팅되기 기다리는 시간내에 강제로 off시킨 VM을 다시 켜주게 되면 설치가 그대로 다시 진행됩니다. 간단히 얘기해서 ... 아마도 ESXi에서 XPEnology가 설치될 때, 마지막 설치단계의 재부팅에서 약간 뭔가 어긋난 상태로 부팅이 되면서 실패가 일어나는 듯합니다.(bug라고 하는 이도 있네요.) 이 때 어시스턴트 프로세스가 진행되는 상태에서 콜부팅하면 설치가 이상없이 다시 진행이 되는군요. missing operating system이라는 메시지만을 보고 판단해서 설치 실패라고 생각하고 중단하시지 말고, 그대로 콜부팅 해주면 간단히 해결이 됩니다.

ESXi 5.1, 5.5와 6,0 모두 평균 2번씩 테스트 봤습니다만, 비정상적인 볼륨 마운트 헤제나 제거는 일어나지는 않네요. 물론 업데이트시에 정상적인 볼륨 마운트해제 일어납니다. 이 때는 재부팅을 해주면 다시 정상적으로 볼륨이 마운트되죠.

ESXi 사용자분이 DSM 5.2-5592 update 4를 하면 볼륨이 제거될까봐 걱정이라고 하셨는데요. [ESXi 6.0에서 VM으로 DSM 5.2-5592.4 실행 중, 오른쪽에 보면 볼륨이 언마운트되었다고 나옵니다만, 재부팅해주면 다시 리마운드 됩니다.] 어제, 오늘 제가 땡땡이 좀 치면서 최신 ESXi 6.0에 DSM 5.2-5592를 설치하고 제어판에서 update 4를 다운로드해서 업데이트 한 결과 볼륨이 비정상적으로 볼륨이 해제되는 일은 발생하지 않더군요. #. 주로 하드디스크 관련 업데이트가 포함된 경우 DSM이 고의적으로 볼륨을 언마트했다가 다시 리마운트하는 부분은 있습니다. RM이건 VM이건 마찬가지 입니다. (간혹 성질급한 사용자들이 오류가 발생해서 볼륨이 제거된 줄 착각하고, XPEnology가 안정성이 없다느니 하지만 ....) 오랜만에 ESXi에 XPNology를 올려봤는데, 문제점이 있더군요. 자칫 일반적인 컴퓨터 유저님들은 소위 삽질 좀 하시거나 포기할 정도로 좀 난해한 부분이 있더군요. 얘기를 이렇게 하면 저는 일반적이지 않은 컴퓨터 유저라는 것 같아 좀 그렇습니다만 .... 저도 땡떙이 치면서 설치하다가 삽질도 했습니다.^^ 일단 기존에 네이티브로 운영하던 기가바이트 EP35-DS3R에서 경험한 바에 의아하면 .... (EP35-DS3R는 엑스피놀로지를 위해 특별히 선택한 H/W가 아니고, 구형이고 상태도 별로 안좋은 PC라서 NAS로 활용하는 것입니다.) 1. ESXi 최신 버전(5.5/6.0)을 설치하니까 네트워크 카드가 잡히질 않더군요. 내장 랜과 추가로 아이타임 랜카드 2장이 장착되어 있는데, 리얼택 8111B, 8168E 이 ESXi 5.5나 ESXi 6에서 감지를 못해서 ESXi 5.1에서 업그레이드를 하거나 드라이버를 구해서 커스터마이징을 해야 하는 문제가 있었습니다. 콘솔 또는 ssh에서 업그레이드 : viewtopic.php?f=12&t=7776 드라이브 커스터마이징으로 : viewtopic.php?f=12&t=7785 2. 오랜 만에 ESXi에 XPEnology를 설치인데, 상식적으로 알고 있는대로 시도를 했더니 오류가 나고 안되더군요. 그래서 국내외 문서를 참조해서 3~4번 시도를 했음에도 역시 동일하게 오류가 발생합니다. 메소드는 각기 조금 차이는 있습니다만, 다 거기서 거깁니다. 결론은 .... missing operating system PXE 로 부팅 시도 operating system not found 3. XPEnology만 그러나 해서 Windows 10하고 우분투를 설치해봤더니 Windows 10도 마찬가지로 오류가 발생, 이것은 부팅시 전원 문제이고 다르게는 디바이스를 인식시키데서 ESXi가 약간 문제가 있는 듯합니다. 어떤 이는 버그라고 하기도 하고 .... 그래서 편법이랄 수 있지만 XPEnology의 경우는 설치 실패된 상황에서 확 덮어 씌워 버리니까 설치가 되네요.^^ 나중에 확실하게 정리를 좀 해뵈야겠습니다만, XPEnology도 커스터마이징해서 설치하는 것이 좋을 듯합니다.

USB 탈착없이 하는 법이라 질문이 간단할 줄 알고 들어와 봤는데, 굉장히 복잡하네요.^^ 저는 이렇게 코맨트하려고 들어왔습니다. 편하게 무선 USB 장치를 쓰는 건 어떨까요.^^

ESXi-Customize로 ESXi 5.5와 6.0 ISO 커스터마이징할 때 필요한 파일(.vib)로 리얼텍 8111B와 RTL8168E용입니다. 위에 칩셋 NIC는 ESXi 5.5와 6.0에서 감지가 안되더군요. 콘솔 커맨드로도 가능은 하지만 재설치할때마다 귀찮죠. EXSi 5.5와 6.0에서 각각 테스트 완료하고 업로드 하니 필요하신 분은 아래 링크에서 다운로드 받으세요. 물론 다운로드 받아 원하는 EXSi 버전으로 커스터마이징 해서 ISO를 만들고 설치하면 NIC가 detection 됩니다. 다운로드 : http://www.filedropper.com/esxi55-60forrtl8111b8168e

큐냅보다는 한 참 늦은 셈이지만, 시놀로지도 드뎌 4K 제품이 출시되기 시작하는군요. ㅎㅎㅎㅎ 솔직히 많이 기대했습니다! 4K라 봐야 4K 트랜스코딩 지원이고, 과연 어떤 하드웨어 스펙을 가지느냐라는 것에 관심인데요. DS216play라는 모델이 출시되었네요. 기사에 따르면, DS214play 아톰 CE5335기반과 비교해서 DS216play는 ST마이크로닉스의 듀얼 코어 SOC H412이 사용된답니다. 초기 출시 시점에서야 DS214play님이 자신의 몸값을 유지하겠지만, 점차 시간이 가면서 몸값을 얼마다 지탱할지 모르겠네요. 아마도 헤베유저나 얼리어답터에 가까운 사용자님들은 몸값 좋을 때 얼른 NAS를 처분하면서 4K를 준비하게 되겠죠? 앞으로 미디어 서버 구축을 NAS를 통해서 한다면, 이제는 4K를 고려하지 않을 수 없겠습니다. ref. http://www.kbench.com/?q=node/154871

ESXI야 NAS 입문자님들 보다는 대부분 컴퓨터 좀 만지시는 분들이 접근하시는지라 자세한 설명은 필요없겠습니다만, 혹시라도 네트워크 카드 감지 문제가 발생하는 경우 커스터마이징 없이 시도할 수 있는 것이 esxCLI입니다. 제경우입니다만, 오랜만에 ESXI를 설치하려고 덤볐더니 esxi가 5.5, 6.0에서는 네트워크 카드가 감지되지 않아 문제가 발생하더군요. 커스터마이징하지 않고, esxi 5.0이나 5.1을 설치한 후에 추가적으로 esXCLI 업그레이드를 시도합니다. 요즘은 뭐 네트웍 인프라가 너무 좋아져서 무얼하던 온라인 업데이트가 빨라서 좋더군요. 오히려 커스터마이징하는 것 보다 빠르네요. 방화벽 명령을 준 다음에 ... esxcli network firewall ruleset set --ruleset-id=httpClient --enabled=true 이제 원하는 버전으로 업그레이드 시킵니다. 예를 들어 ... esxcli software profile update -d / https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml / -p ESXi-5.5.0-1331820-standard 또는 esxcli software profile update -d / https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml / -p ESXi-6.0.0-20150404001-standard 이제 프롬프트가 떨어지면 리부팅 명령하고 기다리면 됩니다.^^

esxi에 볼륨문제가 있다길래 .... 가상화시킬 만족할만한 하드웨어 자체가 준비가 되지도 않은 상태이기 하지만, 굳이 선호할 이유도 없기 때문에 관심도 별로 없는 상태인데요. 오늘 esxi 5.1, 5,5, 6.0에서 XPEnology를 설치해 보았는데요. 역시 가장 큰문제는 장치 호환성이네요. 더군다나 설치방법은 물론 사용자 개별 환경도 너무 다양하고 말이죠. wpado님의 경우 esxi를 어떻게 사용하고 계신지 몰라도 뭐라 언급해드리기가 저도 어렵네요.

고수건 하수건 그게 무슨 문제입니까? 뭔가 서로 주고 받으면서 문제점을 찾아가는 것이죠. 그 과정에서 서로 배워가는 것이구요. 제 의도를 아무리 설명해도 기분이 안풀리실 것 같아 여기까지만 하겠습니다. 본의아니게 기분을 상하게 해드렸다면 사과드립니다. 기분푸셨으면 좋겠습니다.

혹시 update 3 설치하신 후에 재부팅을 하셨어요? 재부팅을 해야만 볼륨이 재마운트되는 것입니다. 원래 드라이브 관련 없데이트가 되면 일단 언마운트시킨 다음에 다시 정상적으로 마운트가 되죠. 그래야 새로운 드라이브가 올라가고 다시 마운트해야 안전하기 때문이죠. 간혹 성질급한 사용자의 경우 무조건 볼륨이 언마운트된 것이 사고나 난것으로 오해하는 경우가 있습니다. 5.2-5592.3의 경우 성능면에서 확장성 호환이 포함되므로 당연히 업데이트 후에 재부팅해야 봄륨이 마운트됩니다. exsi라고 그런 엄청난 일이 일어난다는게 잘 믿기지가 않네요. 그리고 업데이트 4는 볼륨과는 아무 상관이 없는 부분들이 픽스되었습니다. 혹시 esxi를 테스트할 시간이 될지 모르겠네요.

제경우는 네이티브는 자동꺼짐과 WOL 킴으로 사용하는데, 간혹 업데이트 초기에 동작이 안되면 고생 좀 하는데요... 이것까지도 이번 업데이트4에서는 초기 문제가 없네요.^^ 느므느므느므느므 좋습니다.^^

Native하고 Hyper-V on Windows 10 상에 업데이트 시켰는데 별일이 없네요. 그도 그럴 것이 픽스된 이슈들이 대부분 보안관련이네요. 안티바이러스에서 오진하는 것과 아파치 서버하고 PHP 보안 업데이트 사이트 해킹 공격과 관련 XSS 취약점, PCRE 라이브러리 취약점을 픽스시켰네요. 그 외에 시놀로지 몇 기종에서 시스템 복구 후에 업데이트가 안되는 것이 픽스되었습니다. 이번 업데이트는 꼭 하셔야겠습니다. DSM 내부코어들은 엔진엑스(NginX)로 작동이 되는데, PCRE 라이브러리 보안 취약성이 발견되어져 이를 픽스시켰나봅니다. 또 웹사이트나 블로그 운영을 한다면 2개의 XSS 보안 취약성도 픽스시켜야겠네요. DSM이 보다 안전해지도록 업데이트하세요.

제어판 알림이 있어서 확인해 보니까, DSM 5.2-5592 update 4가 릴리즈되었네요. (2015/09/07) Fixed Issues Restored the mandatory file (/usr/syno/bin/zip) that has been removed due to Antivirus Essential's false-positive detection. Upgraded Apache HTTP Server to 2.2.31 to address one security vulnerability (CVE-2015-3183). Upgraded PHP to 5.5.28 to address two security vulnerabilities (CVE-2015-5589 and CVE-2015-5590). Fixed two security vulnerabilities to prevent cross-site scripting (XSS) attacks. Fixed a security vulnerability of PCRE library (ASA-201508-11). Fixed an issue where DSM cannot be updated after system recovery on certain models (DS2415+, DS1815+, DS1515+, RS815RP+, RS815+, DS415+). 혹시 문제 있으면 공유하세요. 저도 업데이트 해보고 문제점이 있으면 공유하겠습니다.^^

포럼에서 이러저런 얘기하다가 생각이 나서 적어봅니다.^^ 간단히 정리해서 ... 1. NAS의 최고관리자계정 admin 또는 administrator의 비밀번호를 분실하거나 2. 외부IP 차단은 물론 3. 내부IP까지 차단된 경우 어떻게 할까요? 개인적으로는 NAS 사용 초기에 ddns를 사용하다 외부IP가 차단된 경우가 있었지만, 이 때마다 내부IP로 접근했서 해결했습니다. 과연 1, 2, 3번이 동시에 이런 상황이 올 수 있을까 생각됩니다. 사실 2, 3번의 경우, 내외부IP의 접근은 NAS 설정과는 무관한 클라이언트 IP이고 그것도 내부 차단에 불과하므로 IP를 재할당 받거나, 이더넷 어답터 설정으로 내부 IP를 변경하는 등 공유기에서 얼마든지 변경할 수 있기에 해결가능할 것이라 생각됩니다. 극단적으로 네트워크 설정 변경이 불가능한 경우도 없지 않아 있겠죠. 그럴경우는 NAS를 재설치하면 해결됩니다. 만약 시스템과 데이터 파티션을 손대지 않고 DSM만 경신시키려면, 이미 공유한 바처럼 .... 뻑난 XPEnology 5.2-5592.3 포맷없이 살린 경험기 위에 방법을 사용해 보세요. 그 외에 다른 방법이 있다면 구체적으로 공유 부탁합니다.

아! 한가지 추가한다면 .... 저는 여전히 boog님 말씀을 이해 못하고 있습니다. 1. 어시스턴트에 무슨 특별한 기능이 있는지요? 아무리 뒤져봐도 그런 기능을 찾을 수 없네요. 2. 포토스테이션이 포토스테이션 계정을 사용한다. DSM과는 별개이고, DSM 로그인에 영향을 주지 않습니다. 3. 포토스테이션이 DSM 계정을 사용한다. DSM에 로그인이 불가능한데, 어떻게 포토스테이션에 로그인할까요? 여하튼 DSM이건 포토스테이션이 간에 차단이 되었습니다. 그러면 이상황을 어떻게 극복하라는 것인지요? "어시스턴트로 접속하면 접근이 가능하다." 이런 말씀인데, 접속해서 뭘 어찌해야 하는지 좀 알려주시면 감사하겠습니다.

위에 글로 이어지는 부분에서 제가 오류를 범한 부분이 있어서 delete를 태그를 사용하려 했으나 게시판에서 삭제 태그 명령이 지원되지 않네요. 아래와 같이 추가합니다. 포토스테이션에서 제가 간과한 부분이 계정 시스템 설정 부분입니다. 제가 위에서 먼저 언급한 일반적인 어플리케이션과 서버 로그인 정책상입니다만, 포토스테이션의 사용자계정은 포토스테이션 계정에서 DSM 계정으로 변경이 가능합니다. 그렇게 되면 로그인 정책이 포토스테이션이 아닌 DSM로그인 정책이 적용됩니다. 다시 말해 '포토스테이션이라는 어플리케이션'만의 제한된 권한 설정 외에 확장된 로그인 정책 즉, DSM(운영체제) 차원에서의 정책이 적용될 수 있도록 변경이 가능하네요. 이 경우 과연 포토스테이션이 차단했다는 것이 옳을까요? 그렇지 않고 DSM이 차단한 것이라고 할 수 있을까요? DSM 계정을 사용한다는 것은 DSM 보안 정책을 사용한다는 것이므로 DSM에 의한 차단이 올바른 것 같습니다. 굳이 포토스테이션이 차단한라도 해도 반대는 하고 싶지는 않습니다.^^ 어쨋든 우선순위는 DSM이 우선입니다. 따라서 포토스테이션에서 계정정책을 변경했다고해도 DSM에서 차단이 된 상태라면 당연히 포토스테이션에서도 차단이 되겠죠. 1. 포토스테이션의 접근권한을 포토스테이션으로 설정 이 경우 DSM로그인과는 무관하므로 포토스테이션의 로그인 여부가 DSM에 영향을 주지는 못합니다. 2. 포토스테이션의 접근권한을 DSM 계정으로 설정 DSM권한이 포토스테이션에 적용되는 것이지, 포토스테이션권한이 DSM에 적용되는 것이 아니므로 포토스테이션이 DSM에 영향줄 수는 없습니다. 단, DSM정책이 포토스테이션까지 적용되므로 포토스테이션 접근시에 로그는 발생할 수 있을 것입니다. 포토스테이션이 차단여부를 포토스테이션이 결정하기 보다는 DSM이 결정하는 것이므로 포토스테이션에 의한 것이라 하기는 좀 어폐가 있다는 생각입니다만, 굳이 반대하고 싶지는 않습니다. 결론은 포토스테이션이 DSM과 무관하게 자신만의 접근권한을 가질 수도 있지만 DSM 계정을 사용할 수도 있다는 것입니다. 그렇다고 포토스테이션 접근권한이 DSM 계정에 영향을 주어 차단된다는 할 수 없겠죠.

bong님, 동일 오류가 발생할지라도 원인은 다를 수 있다는게 문제에요. 경우의 수가 있기도 해서 트러블슈팅이란 것이 쉬운게 아니죠.^^ 본 스레드는 이렇습니다. 1. 주제글 작성자 evildeer님은 IP가 거부라고 말씀하셨습니다. 2. 그런데 실제로 DSM이 IP를 차단하고 거부하는지 확실치가 않더군요. 3. IP가 차단된 원인 자체도 쉽게 파악이 안되기에, 그럴 바에는 DSM 통제불능 상태라는 전제하에 DSM만 경신하면 문제는 간단히 해결되기에 방법을 제시한 것이죠. bong님의 단정적으로 말씀하신 부분은 어시스턴트로 접속하면 DSM이 접속가능하다라고 하셨지, 구체적으로 어시스턴트에서 어디를 어떻게 하라는 설명이 없습니다. IP거부와 관련해 어시스턴트에 무슨 특별한 기능이 있는 것도 아니고, 단순히 내부IP를 확인하고 연결해 주는 정도죠. 내부IP를 꼭 어시스턴트에 접속해야만 알 수 있고 접속 가능한 것도 아니구요. 제가 머리가 나뻐그런지 저는 아직까지도 bong님 말씀이 이해가 안갑니다. 단순히 어시스턴트로 해결이 가능하다라는 단정적인 말씀 외에는 말이죠. 그리고.... 이렇게 말씀하셨는데요. 포토 스테이션에는 IP를 차단하는 기능이 없습니다. 따라서 포토스테이션이 IP를 접근금지시킬 수도 없습니다. 그렇기에 DSM로그에서도 포토스테이션이 IP를 차단시켰다는 로그도 나올 수 없는 것이죠. 단, 포토스테이션이라는 어플리케이션은 자신을 이용하는 것에 대한 접근권한은 설정 가능하기에 접근 권한이 주어지 않은 접근에 대한 denied 로그는 발생할 수 있을 것입니다. 잘못 작성된 부분은 다음 글로 이어집니다.

시놀로지 어시스턴트 드라이브 연결에서 로그인 정보를 저장한 경우와 그렇지 않고 저장을 안해서 연결시 로그인 정보를 입력해야 하는 경우가 있는데, 저는 전자라고 판단을 했습니다. 후자인 경우에 해당하신 모양이군요. 결론적으로 드라이브 연결을 로그인 정보를 입력하고 연결했다는 말씀이시군요. 이런 경우 연구대상감입니다.^^ 아마도 관리자 계정이겠죠? 관리자 계정이 아니래도 드라이브 연결이 가능하므로, 혹시모르니 관리자 계정이 아닌 일반 계정으로 DSM에 로그인하시려는 것은 아닌지, 또한 관련 설정을 상기해서 확인해 보시구요. 만약 관리자 계정인데 웹기반 운영체제인 DSM에서 웹브라우저로는 로그인이 안되고, 어시스턴트 드라이브 연결만 로그인되면 이는 황당한 상황이군요. 제경우는 이러한 황당한 경우와 비슷하게는 경험을 하긴 했습니다. 다름아닌 공유기의 오동작으로 인해서죠. 별짓을 다해도 해결이 안되어 혹시나 싶어 공유기 초기화를 시켰더니, 황당한 상황이 순신간에 해결이 되더군요. evildeer님의 상황은 일단 연구 대상이네요.^^ 관리자 계정인데 갑자기 내/외부 IP로도 접속거부가 되고, 유일하게 시놀로지 어시스턴트의 드라이브 연결에서만 로그인되는 상황이군요. 그래서 드라이브 연결로 데이터는 백업 받을 수 있는 상황이네요. 문제는 DSM은 통제불가능한 상황이라는 것이군요. DSM에 통제불능은 일단 제가 제시한 방법으로 해결이 되니, 다행입니다만, 어째서 evildeer님과 같은 상황이 발생하는지는 연구대상감입니다.^^ 우선적으로 해결은 가능하시니 다행이구요. 항상 데이터 유실에 대비한 준비는 꼭 해놓고 사용하세요.^^

bong님이 단정적으로 말씀하셨는데, 이는 좀 무리가 아닌가 합니다.^^ (NAS 입문자님들이 오해하실까봐 말씀드립니다.) 시놀로지 어시스턴트에 특별한 기능으로 접근 가능한 것이 아니고, 외부IP(ddns)가 차단 된 상황에서 내부IP 192.168.xxx.xxx로 접근한다는 말씀일 것입니다. 만약 내부 IP까지 차단된 상황이면 의미가 없습니다. 다음과 같은 상황이면, DSM에 접근 및 통제가 불가능하다고 할 수 있는데요. 1. 외부IP 이건 내부 이건 IP가 차단된 상황 2. 관리자 접속 정보를 분실한 상황 evildeer님이 bong님 말씀대로 했는데도 안되었다는 것은 외부IP 이건 내부IP이건 접속 불가능 상태라고 할 수 있죠. 그런데 다행스럽게 bong님 때문에 힌트를 얻어 시놀로지 어시스턴트의 드라이브 연결을 했더니 연결이 가능하다는 것은 evildeer님이 DSM의 관리자 계정을 분실하거나 몇 개의 계정이 있어 뭔가 뭔가 혼동을 하는 상황이라 판단됩니다. 만약 계정 정보를 입력해서 접속한 것이 아니라면 아래와 같은 상황이라 판단됩니다. DSM에 A라는 관리자 계정있다면 접속정보를 분실하면 DSM에 로그인이 불가능하죠. 이러한 경우가 종종 있습니다. 왜냐면 NAS 입문자님이 로그인 정보 저장 후에 자동접속하다가 자동접속이 풀린 경우 로그인 정보를 기억해내지 못하는 경우 발생합니다. 그런데 위에 상황을 보면 evildeer님의 경우 시놀로지 어시스턴트의 드라이브 연결로 데이터 백업이 가능하다면 이는 Windows의 '자격증명' 저장 기능으로 DSM 로그인 정보가 아직 남아있다는 것입니다. 문제는 비밀번호를 분실했고, e메일로 찾을 수 있는 설정을 해놓지 않으셨으면, DSM은 통제불능상태라고 할 수 있죠. 제가 작성한 글들은 DSM 통제 불능상황에서의 시도 방법들입니다.

안녕하세요. 먼저 뻑난 XPEnology 5.2-5592.3'라는 것에 대해 말씀드리자면, 엑스피이놀로지 입문자님이 어쩐 일로 이거저거 주물르다가 급기야는 NAS 자체가 아예 부팅되지 않는 상황이 발생한 경우를 말합니다. 긴 글을 읽을 시간이 없거나 성질급하신 분은 8로 건너 뛰세요. 이 경우 엑스피이놀로지에 데이터가 안전하게 살아 있는 경우라 할 수 있어서 시스템과 데이터 파티션을 건들이지 않고 다시 엑스피이놀로지를 부팅시켜야 하는 상황이라고 할 수 있습니다. 1. 엑스피이놀로지가 설치가 되면, 마이그레이션 방법을 이용해서 업그레이드나 다운그레이드가 가능하다는 것은 이미 잘 알려져 있습니다. 이 때 시스템 파티션이나 데이터 파티션을 건들이지 않고 DSM 운영체제만 경신이 됩니다. 2. 정상적으로 실행되던 엑스피이놀로지가 부트로더 관련 부분을 잘못 건들이면 정상적으로 부팅이 이루어지지 않게 되죠. 이러한 경우가 갑작스럽게 찾아오면 난감합니다. 디스크에는 멀쩡하게 데이터들이 잘 살아 있을텐데, 데이터를 유지한 상태로 DSM 운영체제만 재설치할 방법이 없기 때문이죠. 3. 디스크에 데이터만 멀쩡하다면 데이터를 추출해 내는 일은 쉽니다. 3-1 시놀로지는 우분투를 통해서 디스크를 마운트시켜 데이터를 뽑아내는 방법을 안내합니다. https://www.synology.com/ko-kr/knowledgebase/faq/579 [엑스피이놀로지 USB 대신 우분투 라이브 USB로 부팅한 화면] 네, 위와 같이 작업을 하면 어쨌든 가능한 일입니다. 그렇지만 문제는 NAS가 편리하고 좋다고 해서 무턱대고 시작한 입문자님들의 리눅스에 대한 개념은 거의 전무하다는게 문제지요. 아무리 자세하게 설명해도 뭐하나 삐끗하면 도중하차하기가 일쑤인데, 위에 방법으로 디스크를 마운트하고 데이터를 추출하거나 슈퍼블록을 찾아 수정하거나 하는 일이 보통일이 아닐 것입니다. 3-2 데이터만이라도 살리시고 싶으시면, Windows에서 크로스 플래폼 복구도구인 UFS Explorer를 실행해서 'Save this Object to'를 실행하시면 파일시스템 ext4를 Windows 파일시스템(NTFS)으로 얼마든지 가져올 수 있습니다. 물론 NAS의 데이터를 Windows로 복사해 올만한 양의 디스크가 준비되어져 있어야하며, 복사 할 시간이 '대박' 필요할지도 모릅니다.^^ 4. 사실은 본 포럼에 어떤 사용자님이 질문을 하셔서, 저도 그와 같은 상황을 만들어 보고 이걸 어떻게 살려야 될지 고민해 보았습니다. 4-1 우선 단순히 부팅이 안되는 뻑난 상황(비밀번호 분실로 접근이 불가능한 상황 포함)에서 엑스피이놀로지의 디스크에는 멀쩡히 데이터가 살아 있는 상황에서 클린 인스톨은 안됩니다. 개인적 이것은 순전히 엑스피이놀로지의 고의라 생각되는데요. 아마도 데이터를 날려 버릴 수 있기 때문에 데이터 보호차원에서 이러한 방식을 취하는 것이 아닐까합니다. 5. 4번과 같은 상황을 만들려고 이거저거 주물렀습니다. 그랬더니 부팅이 안되더군요. 부팅이 되더라도 부트메뉴에서 첫 번째 노멀부팅, 두 번째 디버그, 세 번째 인스톨/업그레이드 모두 먹통인 상황입니다. XPNoboot 5.2-5592.2으로 부팅해서 DSM 5.2-5592.3입니다. 이런 상황에서 이걸 어떻게 극복하죠? 6. USB를 빼서 XPNoboot 5.1-5502.2 iso로 부팅이미지를 경신했습니다. 그리고 부트메뉴에서 install/upgrade를 실행했습니다. 그 다음 시놀로지 어시스턴트를 실행했더니 해당 NAS가 마이그레이션 가능 상태로 나옵니다. 이러면 DSM을 재설치가 가능한 상황이 되는거죠. DSM 5.1-5502를 올리니까 하위버전이라는 메시지를 출력하면서 마이그레이션 진행이 완료되지 않습니다.(당연하겠죠) [이 처럼 etc.default/VERSION 편집없이는 마이그레이션으로 다운그레이드가 실행이 되지 않음] 7. 왠지 위와 같은 방법으로 XPNoboot 5.2.5592.2와 DSM 5.2.5592를 시도하면 어떨까라는 생각이 불현듯 스치더군요. 소가 뒷걸음치다가 쥐잡는다고, 웬걸 뻑난 엑스피이놀리지가 다시 살아나네요. 당연히 데이터도 그대로 유지된 상태입니다. [마이그레이션이 안되어야 함에도 이처럼 비정상적으로 된다는 것이 문제(???)] 정리하자면 7-1 부트이미지 XPNoboot 5.2.5592.2와 DSM 5.2.5592.3을 사용하는 상태에서 NAS가 뻑났습니다. 7-2 USB를 새로 경신하든지 해서 부트이미지 XPNoboot 5.2.5592.2로 부트메뉴를 띄웁니다.(5592.2가 안되면 혹시모르니 5592.1나 5592로 시도하세요.) 7-3 정상적으로 부팅이 되면, 첫 벗째 노멀부팅을 선택합니다. (install/upgrade가 아닌게 노멀부팅으로 된다는 것이 저도 이상하다 생각합니다.) 7-4 시놀로지 어스턴트에서 마이그레이션 상태가 되고, 설치가 진행되면 DSM 5.2.5592을 올려줍니다.(DSM 5.2.5592.1, DSM 5.2.5592.2, DSM 5.2.5592.3이 아닙니다.) 7-5 이상하게 뻑난 DSM 5.2.5592.3에 DSM 5.2.5592을 install/upgrade도 아닌 노멀부트를 선택해서 설치해 주니까 살아나더라구요.^^ 더 간단히 정리하자면 8. XPNoboot 5.2.5592.2 부트와 DSM 5.2.5592.3을 사용하는 상황에서 NAS가 뻑난 경우 새롭게 XPNoboot 5.2.5592.2 USB를 만들어 노멀 부팅한 후에 시놀로지 어시스턴트에서 마이그레인션 가능 상태 - 설치로 DSM 5.2.5592를 올리니까, 다시 DSM 5.2.5592로 살아더라구요.^^ 이후에 DSM 5.2.5592.2 또는 DSM 5.2.5592.3로 업데이트하면 완벽하게 디스크 초기화 없이 뻑난 엑스피이놀로지가 복구되는 것이죠. #. 엑스피이놀로지 NAS가 뻑나서 부팅이 안되는 상황이던지, 비정상적이던 실수던 볼륨을 제거시켰다던지 하는 상황에서 시스템이나 테이터 파티션을 포맷하지 않고 살리려면 어떻게던 디스크를 리눅스에 마운트시키고 슈퍼블록에 접근을 해서 etc.default/VERSION을 편집하고 마이그레이션으로 다운그레이드시킨다거나 아니면 데이터만을 준비된 추가 디스크에 복사해야 하는데, 리눅스에 익숙한 사용자가 아니면 어려운 상황입니다. 차선책으로 다행히 크로스 플랫폼 복구 도구 UFS Explorer를 통해서 매우 쉽게 데이터를 뽑아낼 수 있습니다만, 이마저도 데이타가 많으면 꽤 오랜 시간이 걸리고, 별도의 디스크가 필요하다는 점이 있습니다. 그렇지만 결론적으로 위의 8번 처럼 했더니 의외로 NAS 자체에서 바로 살릴 수 있었습니다. enjoy!

evildeer님 정상적인 방법은 아니구요. 한마디로 '뻑'간 엑스피이놀로지를 NAS 자체에 그대로 살리는데 제가 성공을 했습니다.^^ 혹시 본 포럼에 새 글로 작성되는 글을 참조하시면 도울될 수도 있지 않을까 합니다. 정상적인 복구 방법이라고는 할 수 없으므로 경험기로 올립니다. ---> http://xpenology.com/forum/viewtopic.php?f=12&t=7679