뒷북이긴한데 혹시나 이런 증상 있으신 분 중에 해결 못하신 분들 위해 작은 기록 남깁니다(feat. SAN manager)
지인분 헤놀을 6.2.3에서 7.1.1로 바꿔서 마이그레이션 해주던 중
SAN manager 수리가 뜨길래 여기저기 찾아보다가 서버포럼에도 한 포스트가 있던걸 봤는데 해결책에 대한 부분은
못찾아서 올립니다. 제가 다른 포스트가 있는데 못찾은거 같습니다.
영어로 찾아보니 한 분이 해결책을 찾아놓으셨더라구요
https://github.com/PeterSuh-Q3/tcrp-addons/blob/main/sanmanager-repair/src/sanrepair.sh
여기로 가셔서 raw 다운로드 버튼을 눌러 저 sanrepair.sh 를 다운받아서 시놀로지상 아무 폴더에 넣습니다
저는 web 폴더에 넣었어요 그 다음 ssh 로 접속해서 sudo -i 로 루트접속한 후에
cp /volume1(web 폴더가 있는 볼륨으로 쓰세요)/web/sanrepair.sh /usr/sbin/
이렇게 해서 /usr/sbin/에 저 파일 넣고 작업 스케쥴러를 열어서
생성 -> 트리거된 작업 -> 사용자 정의 스크립트를 열고 작업 이름은 뭐 대충 SAN repair 로 넣고
root 선택 부트업 선택후 작업 설정탭에서 /usr/sbin/sanrepair.sh 이렇게 스크립트 적고 저장~!
저는 저장후 바로 해당 스크립트 선택 후 실행 누르고 바로 SAN manager 설치 성공~!
아쉽지만 매 부팅시 적용해야하는 스크립트랍니다. 안하면 또 수리 떠요 ㅋ
뒷북일지 모르나 작은 정보 공유합니다.
P.S 역시나 화정큐삼림 ㅋㅋ 답글에 남기신 방법 추가 합니다 제 방법 말고 ssh 접속후 이 방법으로 하세요
sudo -i
cd /usr/sbin
curl -kLO https://github.com/PeterSuh-Q3/tcrp-addons/raw/main/sanmanager-repair/src/sanrepair.sh
chmod +x sanrepair.sh
1등 
2등 글을 찾아오시는분들께 큰 도움이 되겠네요! 글은 NAS게시판으로 옮기겠습니다~
(역시 갓정큐삼님..)
3등 ARC 쪽에도 SAN MANAGER 손상이 발생하고 있는 모양입니다.
아마도 RR 소스 검증없이 그냥 베껴다가 쓰다가
RR 에선 MAC-SPOOF 를 다시 제거했는데, 이것까지 못따라간 모양입니다.
아이디어는 미국 헤놀포럼의 회원님이 주신것이고 그 이후 VMM 기동불가 이슈는 제가 찾아서 더 보완한것이구요.
TCRP-MSHELL 사용하시는 분들은 로더만 다시 빌드해 주시면 알아서 자동포함되도록 되어 있습니다.
ARC 나 RR 사용하시는분중에 이 스크립트만 적용하고 싶으신 분들 위해 다운로드 및 설치 커맨드를 좀더 보완해서 알려드리겠습니다.
이 순서대로 수행하십시요.
sudo -i
cd /usr/sbin
curl -kLO https://github.com/PeterSuh-Q3/tcrp-addons/raw/main/sanmanager-repair/src/sanrepair.sh
chmod +x sanrepair.sh
그 뒤로 스케쥴러 등록도 원 스크립트로 한방에 넣어 드리는 방법입니다.
대신 아래커맨드로 esynoscheduler.db 파일이 존재하고 있는지 먼저 확인해 보십시요. ARC 와 RR 도 이미 이 DB 파일은 사용하고 있을겁니다.
ll /usr/syno/etc/esynoscheduler/esynoscheduler.db
sqlite3 /usr/syno/etc/esynoscheduler/esynoscheduler.db "INSERT INTO task VALUES('sanmanager-repair', '', 'bootup', '', 1, 0, 0, 0, '', 0, 'while true; do sleep 10; /usr/sbin/sanrepair.sh; [ -d /config/target/loopback ] && break; done', 'script', '{"running":[17917]}', 1706787067, 0, '{}', '{}');"
cmt alert
신고
"님의 댓글"
이 댓글을 신고하시겠습니까?
