LAN Tank(SOTO-HDLWU)
KNOPPIXでLANTANKの/hda3 を確認するものの、
鍵マークのついたフォルダに関しては
「xxxxは存在しないようです」と表示されて何も出来ない。
しかし、エロ救出作戦は諦めるわけにはいかず、
まずは頭を冷やしながら出来ることは大体やった。
cp コマンドでコピーを実施
→鍵マークのフォルダ認識せず×
rsync コマンドでコピーを実施
→鍵マークのフォルダ認識せず×
途方にくれた僕はとりあえず、SMBを立ち上げた。
KNOPPIXのSMBって一発共有してくれて楽だね。
おっ！
Windows上から鍵マークのついたフォルダが読める。
XCOPY E:\ D:\ /c /s /e /q /h /i /k /r /y /Z
のスイッチを付けてE:\（/hda3）から
D:\（外付けHDD）にXCOPYコピーをする。
おー、快調にコピーしているな～。
やっと安らかな睡眠生活が送れるなー。
っと思いきや、またまた問題発生。
「メモリが足りません」と表示されて、
XCOPYコピーが終了してしまった…
どうやら「メモリが足りません」と表示されるのは、
ファイル名が255バイトを越えているからっぽい。
技術力の無い僕はまだXCOPYに固執している…
ってことは、スイッチに/N を付ければ255バイト問題は
回避できるんじゃないか？なんて思いましたけど、
実際にXCOPYコピーし始めると鍵マークのファイル以外も
全部リネームされてコピーされるので即効中止。
そろそろテンパリ始めてますよ…
ググってるとファイル名が255バイトを越えてもコピーできる
ツール類があったので試してみたけど、ネットワーク環境には
対応して無いっぽくてコピーできなかった。
ちょっと待てよ。。。
冷静に考えたら鍵マークのついたフォルダは本来、
日本語で名前が付いていたフォルダが文字化け
しているだけっぽいので、KNOPPIX側に問題が
あるんじゃないか？とひらめいた！！
ここまで読んでくださった読者の方、
お付き合いくださり有難う御座います。
そもそもの大きな間違いはCD一枚に収まるバージョンの
KNOPPIX3.8.2をチョイスしたのが始まりです。
最新版のKNOPPIX5.0をDVDに焼きまして、
以下のオプションを付けてブートしてみてください。
boot: knoppix lang=ja.UTF-8
今までの苦労は何んだったんでしょう…
フォルダ名が文字化けして鍵マークになっていた
日本語表示のファイルも正しく認識しています。
/hda3 内のフォルダ全部をKNOPPIX 上で、
/uba1（外付けHDD）にドラック＆コピー。
あー、無知って恐ろしい技術力の無さに落胆。
今回の件での余計な出費は勉強代として消化しよう。
私もここ数日、全く同じような状況に悩んでいます。
機器は、LanDiskです。
PCをknoppixで起ち上げ、LanDiskの中身を見てみると
フォルダに鍵マークがあり、コピーも中を見ることも出来ません。
なんとかデータだけでも抜き出そうと必死です。。。
似たような症状のようなので、私の場合もknoppix5.0で
行えば可能性はありそうですね。
そこでひとつ、質問なんですが、
最終的にコピーした先のHDDは、Linuxベースのものですか？
USBメモリーやFAT32/NTFSではダメですかね？
取り出したデータをwindowsで弄れればイイんですけど。。。
そうですね…
旧バージョンのknoppixで中を確認して、
フォルダが鍵マークになっている状況でしたら。
UTF-8をサポートしているknoppix5.0を使えば、
問題なく中身を救出できるかもしれないです。
ご質問の件ですが、僕の場合はコピー先を
USB接続のHDD(FAT32)にしました。
NTFSもサポートしているらしいですが、
ここまで苦労したので確実な方法を取りたくて、
FAT32で作業したってのが本音です。
もちろん取り出したデータはWindowsで確認できます。
皆さん同じ様な現象に見舞われてるんですね。
大事なデータが救出できれば幸いです。
同じ悩みで書いた者です。
knoppix5.0でやってみたのですが、
文字化けが直りませんでした。
ちゃんと、bootでUTF-8をつけたのですが。。。
UTF-8を付けずに、やってもみたんですが、ダメでした。
しかし、UTF-8にするとちょっと置くまでフォルダをみることが
出来ました。
今までは鍵が付いてたものでも、鍵がなくなっているものがありました。
もう少しのような気もしますが、ダメそうな気もします。
ところで、オプションの追加は、
boot: knoppix lang=ja.UTF-8
でいいんですよね？不安なもので。。。
もう少しがんばってみます。
knoppixのHPを見ると、UTF-8 を使う場合の
ブートオプションは何通りかあるみたいです。
参考：「ja.UTF-8」「ja.utf-8」「ja.UTF8」「ja.utf8」
また、knoppixはデフォルト文字コードがEUCなので、
knoppix lang=ja
とオプションを付けて起動するとEUC-JPに
変更されるみたいです。
下記ページの中に「LANDISK環境で使用中のファイルは、Shift_JISであるため」との記載があります。
http://eggplant.ddo.jp/www/pukiwiki/index.php?Samba%A4%C8Netatalk%A4%CB%A4%E8%A4%EB%A5%D5%A5%A1%A5%A4%A5%EB%B6%A6%CD%AD
LANDISKの環境を熟知していないので、
なんとも言えないのですが、
sambaでUTF-8を明示的に指定して使っていなければ、
書き込んだファイルがShift_JISである可能性があります。
knoppixのsambaをShift_JISで起動できれば、
Windows側から見た時に鍵マークが付かないかもしれません。
文字コードについて詳しくないので、
トンチンカンなことを言ってたら申し訳ないです。
「この症状が数回（5、6回）続くとLANTANKが壊れると思う。」
同じ症状にはまり、このブログに辿り着いたものです。
復旧方法を参照させてもらい、shareの中のフォルダーまでは見えるようになったのですが、その中身が空っぽという事態になってしまっています。
で…ひとつお尋ねしたいのですが、この方法で復旧できたHDはHD一台、またはミラーリングで使用されている場合なのでしょうか？
自分の場合、スパニングで使用してしまっているのですが…この場合は絶望的なのか確認したいのです。
日付的に見られていない可能性も高そうですが…もし見て貰えたならお教え下さい。お願いします。
ruyさん
ご連絡ありがとうございます。
僕の場合、2台のHDDでミラーリングで組んでます。
Shareの配下がミラーされてソフトウェアコピーされてる仕様っぽいです。
スパニングの場合復旧するかわかりませんが、
もし、「SERIAL-KIT」ケーブルをお持ちなら復旧できるかもしれません。
ついこの間も、また同じ現象になりまして、復旧させました。
「SERIAL-KIT」ケーブルを刺して起動画面を見ていると、
Inodeが壊れてマウントできない状態の所で止まります。
Fsckを何度も根気強く掛けると、起動できる状態まで回復しました。
何度も同じ状況になって、その度にFSCKで回復させています。
いい加減、違うNASを購入してそちらで運用し始めていますが、
LANTankは良い勉強になったと思ってます。
ruyさんの状況ですと、同じ条件ではないので微妙ですが、
KNOPPIXでデータを吸い上げるより、「SERIAL-KIT」ケーブルで、
直接LANTankのHDDを復旧させる方法を試してみた方が良いかもしれません。
その場合、諦めないで何度もFsckを実効してみてください。
完全にInodeのエラーが消えなくてもマウントできる状態まで持って
行けるかもしれませんので。
お役に立てれば幸いです。ご検討をお祈りしています！
情報有難う御座います。
「SERIAL-KIT」ケーブルを持ってなかったので早速購入。先ほど起動させて見ました。
-----------------------------------------
Checking root file system...
fsck 1.35 (28-Feb-2004)
/dev/hda1 contains a file system with errors, check forced.
Duplicate or bad block in use!
/dev/hda1: Duplicate/bad block(s) in inode 1676: 19718
/dev/hda1: Duplicate/bad block(s) in inode 142400: 19720
/dev/hda1: Duplicate/bad block(s) in inode 142402: 19718 19722 19724 19726 19728 19730 19732 19734 19736 19761 19763 19765 19767 19769 19771 19773 19775 20125 20126 20127 20128 20129 20130 20131
/dev/hda1: Duplicate/bad block(s) in inode 142411: 19721 19723 19725 19727 19729 19731 19733 19735 19762 19764 19766 19768 19770 19772 19774 19776 19777 19778 19779
/dev/hda1: Duplicate/bad block(s) in inode 142743: 20134
/dev/hda1: Duplicate/bad block(s) in inode 142757: 19720 19721 19722 19723 19724 19725 19726 19727
/dev/hda1: Duplicate/bad block(s) in inode 143040: 19728 19729 19730 19731 19732 19733 19734 19735 19736
/dev/hda1: Duplicate/bad block(s) in inode 143076: 19761 19762 19763 19764 19765 19766 19767 19768 19769 19770
/dev/hda1: Duplicate/bad block(s) in inode 143084: 19771 19772 19773 19774 19775 19776 19777 19778 19779
/dev/hda1: Duplicate/bad block(s) in inode 143099: 20125 20126 20127 20128 20129 20130 20131 20133
/dev/hda1: Duplicate/bad block(s) in inode 143103: 20134 20135
/dev/hda1: Duplicate/bad block(s) in inode 158610: 20133
/dev/hda1: Duplicate/bad block(s) in inode 158611: 20135
/dev/hda1: (There are 13 inodes containing duplicate/bad blocks.)
/dev/hda1: File /var/cache/samba/browse.dat (inode #1676, mod time Tue Jun 9 23:07:19 2009)
has 1 duplicate block(s), shared with 1 file(s):
/dev/hda1: /var/log/kern.log (inode #142402, mod time Tue Jun 9 21:17:03 2009)
/dev/hda1:
/dev/hda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
fsck failed. Please repair manually and reboot. Please note
that the root file system is currently mounted read-only. To
remount it read-write:
# mount -n -o remount,rw /
CONTROL-D will exit from this shell and REBOOT the system.
Give root password for maintenance
(or type Control-D to continue):
-----------------------------------------
教えて頂いた通り、なのかな？
fsckをしていますが、先に"# mount -n -o remount,rw /"を試して見たほうがいいのか…色々してみようと思います。
起動しました。
fsck掛けると膨大なエラーが出続け、修復失敗のメッセージも続き…かな～りあきらめて居たのですが、fsckとrebootを繰り返すこと、丸一日半…ずっと見ていなかったLOGINメッセージが…。
その手前には、MySQLやSambaの起動メッセージ。
もしかしてと思いネットワークを確認したら…Sambaまで復活していました。
正直中のファイルが完全に残ってるかはまだ不明ですが、見れる内にと別PCへコピー中です。
有難う御座いました。
ruyさん
微力ながら、お力になれて良かったです。
データー吸い出して別のNASで運用した方が
良いと思います。
今は色々、良い商品が出てますしね。
LANTANKはカスタム心はくすぐってくれましたが、
信頼性の方は皆無ですから。。。