特定のボリュームがマウントできない

ポスト遅くてすみません。
はにさんの方法でトライしてみました。
>中のデータが大事で、とにかくそれを回収したいということなら、
rootでログインして実行してみました。
○○○○○:〜 root# sudo mkdir /Volumes/repair
○○○○○:〜 root# sudo mount -t hfs /dev/disk0s9 /Volumes/repair
mount_hfs: Input/output error
○○○○○:〜 root#
わたしには意味がわからないのですが、"error"と言う文字のみ読めますので、これはエラーと判断してよいでしょうか？
5度ほど同じことをしても同じ結果に終わってしまいます。
ですので、ここから先には進めていません。
それと、はにさんのおっしゃっていた
>それとも、diskutil info disk0s9 とかしたら（disktool コマンドと違って）マウントポイントとか表示されるのでしょうか？
実行すると、こんな結果です。
○○○○○○:〜 root# diskutil info disk0s9
Device Node: /dev/disk0s9
Device Identifier: disk0s9
Mount Point:
Volume Name:
File System: Journaled HFS+
Permissions: Disabled
Partition Type: Apple_HFS
Bootable: Is bootable
Media Type: Generic
Protocol: ATA
Total Size: 9.5 GB
Free Space: 0.0 B
Read Only: No
Ejectable: No
○○○○○○:〜 root#
こんな感じです。
安食達蔵さん、すみません。
私のやり方が悪いのか、現在のところまだマウントできません。
皆さんにご支援いただき、私も何とかマウントさせたいです。
No9さんありがとうございます。
しかし、少々不安が・・・
今から、挑戦してみたいと思いますが私のような素人でも大丈夫なのでしょうか？
シングルユーザーモードと言うのは、真っ黒の画面に白い文字が出るやつですよね・・・
トライした方が・・・いいですよね？

> ○○○○○:〜 root# sudo mount -t hfs /dev/disk0s9 /Volumes/repair
> mount_hfs: Input/output error
root でやっているのなら、sudo は不要です。（でもエラーとは関係ありません）
-r オプションを付けるとどうでしょうか。
mount -r -t hfs /dev/disk0s9 /Volumes/repair
とします。
> シングルユーザーモードと言うの..
nuki さんの場合、disk4 からは正常に立ち上がっているので、シングルユーザモードでやる必要はありません。今、ターミナルの rootでゴソゴソやられていますが、ある意味、これはとても危険なことなのですよ。でも、正常にはマウントしないディスクをマウントさせたいのだから仕方ないですけど。
> 実行すると、こんな結果です。
> ○○○○○○:〜 root# diskutil info disk0s9
> Device Node: /dev/disk0s9
> Device Identifier: disk0s9
> Mount Point:
> Volume Name:

ありがとうございます。disktool -l の結果と同じですね。

はにさん色々とすみません。
しきり直して、はにさんに御教授頂いた方法をもう一度、頭から実行してみました。
結果です。
>disktool -r /dev/disk1
実行・結果
nuki01:〜 nuki01$ disktool -r /dev/disk3
Refreshing Disk Arbitration ...
nuki01:〜 nuki01$
>disktool -r とすると disktool -l
Mountopoint や volName　反応なし
>disktool -n disk0s14 repair
実行・結果
nuki01:〜 nuki01$ disktool -n disk0s14 repair
Device disk0s14 will be attempt to renamed to repair ...
〜
***Notifications Complete for type 1
***DiskChanged('disk0s14', '', '', 0, Success = 0)
Got end signal
nuki01:〜 nuki01$ disktool -r
Refreshing Disk Arbitration ...
nuki01:〜 nuki01$ disktool -l
結果
再起動後もマウントしませんでした。
>/sbin/fsck -fy /dev/disk0sX
実行
nuki01:〜 nuki01$ /sbin/fsck -fy /dev/disk0s9
Can't open /dev/rdisk0s9: Permission denied
nuki01:〜 nuki01$ /sbin/fsck -fy /dev/disk0s10
Can't open /dev/rdisk0s10: Permission denied
nuki01:〜 nuki01$ /sbin/fsck -fy /dev/disk0s11
Can't open /dev/rdisk0s11: Permission denied
nuki01:〜 nuki01$ /sbin/fsck -fy /dev/disk0s12
Can't open /dev/rdisk0s12: Permission denied
nuki01:〜 nuki01$ /sbin/fsck -fy /dev/disk0s13
Can't open /dev/rdisk0s13: Permission denied
nuki01:〜 nuki01$ /sbin/fsck -fy /dev/disk0s14
Can't open /dev/rdisk0s14: Permission denied
つづいて
>mkdir /Volumes/rinji
実行
nuki01:〜 nuki01$ mkdir /Volumes/rinji
mkdir: /Volumes/rinji: File exists
nuki01:〜 nuki01$ mount -t hfs /dev/disk0s9 /Volumes/rinji
mount_hfs: Permission denied
nuki01:〜 nuki01$
結果
反応なし
ここで一つ気になることが？
"Permission denied"とは、Permissionが違いますよと言う解釈でよろしいでしょうか？
うっかりお伝えするのを忘れていたのですが、マウントできないHDDにはOS9の起動システムが入っています。
場所は、多分0s9(マウント時名：Macintosh_01)だと思います。
その他に、0s11(マウント時名：Macintosh_03)。他は、全てデータファイルです。
現在OS9は、他のコンピューターから外付けHDに丸ごとCopyしてＯＳＸ側からClassicとして認識させています。
>sudo mkdir /Volumes/repair
実行
nuki01:〜 nuki01$ sudo mkdir /Volumes/repair
Password:
mkdir: /Volumes/repair: File exists
nuki01:〜 nuki01$ sudo mount -t hfs /dev/disk0s9 /Volumes/repair
mount_hfs: Input/output error
nuki01:〜 nuki01$ sudo mount -r hfs /dev/disk0s9 /Volumes/repair
usage: mount [-dfruvw] [-o options] [-t ufs | external_type] special node
mount [-adfruvw] [-t ufs | external_type]
mount [-dfruvw] special | node
nuki01:〜 nuki01$ ls /Volumes/repair
nuki01:〜 nuki01$
結果
> ls /Volumes/repair
まで実行してみましたが、中身を見ることができませんでした。
以上こんな結果です。

> >/sbin/fsck -fy /dev/disk0sX
> 実行
> nuki01:〜 nuki01$ /sbin/fsck -fy /dev/disk0s9
> Can't open /dev/rdisk0s9: Permission denied
これは権限が無いからできないよ、というエラーです。
こういうときは、root でやるか、頭に sudo を付けます。
それと、この場合は、sudo を付けてもエラーがでてうまくゆきません。
sudo /sbin/fsck_hfs -fy /dev/disk0s9
としてください。これでエラーが出ずに完了するようなら、ディスクはマウント準備完了状態にあります。
上でエラーがでなければ（あるいは、何度 fsck をかけてもエラーが無くならないようでしたら、次のマウントコマンドを試します）、
sudo mount -r -t hfs /dev/disk0s9 /Volumes/repair
として下さい。（報告されているのには、-t が抜けているためエラーになってます）。これで、ls /Volumes/repair として中が見えないでしょうか。
前の書き込みで、単に
(sudo ) mount -t hfs /dev/disk0s9 /Volumes/repair
とすると、IO エラーが出てますので、ディスクは何か悪い状態になっていると思われます。なので、fsck でエラーがでないというのはちょっと不思議です。IOエラーのために、fsck そのものがうまくできてないという可能性もあります。でも、悪い状態でも、-r オプションを付けて、read only でなら、マウントできることが少なからずあります。このときは、このディスクを普通には使うことはできませんが、中のデータ（多くの場合大部分）を救い出すことはできます。

下記は、エラーがないと思ってよろしいですか？
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s9
** /dev/rdisk0s9
** Checking HFS volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Checking Catalog hierarchy.
** Checking volume bitmap.
** Checking volume information.
** The volume Macintosh_1 appears to be OK.
nuki01:〜 nuki01$

エラー無しです。
これでマウントできないとしたら、どうしてでしょうね。

>このときは、このディスクを普通には使うことはできませんが、中のデータ（多くの場合大部分）を救い出すことはできます。
少し安心しました。
sudo /sbin/fsck_hfs -fy /dev/XXXXをdisk0〜0s14まで実行してみました。
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0
** /dev/rdisk0
** Volume check failed.
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0
** /dev/rdisk0 (NO WRITE)
** Volume check failed.
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s1
** /dev/rdisk0s1 (NO WRITE)
** Volume check failed.
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s2
** /dev/rdisk0s2
** Volume check failed.
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s3
** /dev/rdisk0s3
** Volume check failed.
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s4
** /dev/rdisk0s4
** Volume check failed.
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s5
** /dev/rdisk0s5
** Volume check failed.
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s6
/dev/disk0s6: No such file or directory
Can't stat /dev/disk0s6
Can't stat /dev/disk0s6: No such file or directory
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s6
/dev/disk0s6: No such file or directory
Can't stat /dev/disk0s6
Can't stat /dev/disk0s6: No such file or directory
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s7
** /dev/rdisk0s7
** Volume check failed.
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s8
** /dev/rdisk0s8
** Volume check failed.
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s8
** /dev/rdisk0s8
** Volume check failed.
nuki01:〜 nuki01$ sudo /sbin/fsck_hfs -fy /dev/disk0s9
** /dev/rdisk0s9
** Checking HFS volume.
** Checking Extents Overflow file.
** Checking Catalog file.
** Checking Catalog hierarchy.
** Checking volume bitmap.
** Checking volume information.
** The volume Macintosh_1 appears to be OK.
nuki01:〜 nuki01$
disk0s14まではdisk0s9と同じ結果です。
それと少し思い出したのですが、参考になればと思いましてお書きします。
マウントできなくなる前に、TechToolのeDiskというものがこのDiskに存在していました。
　eDriveとは
　CDから起動せずに、そのVOLUMEをアプリケーションから指示してそのボリュー
　ムから起動し、Diskの調整をするためのものです。(あってるかな？)
少し調子が悪くなったので、そのVOLUMEを解除しました。
そのあたりの名残があるのでしょうか？
disk0s6の結果がその他のものと若干違っていたので2回行いました。
eDriveの名残なのでしょうか？

あまり余分のことはしない方がいいと思いますよ。
disk0 - disk0s8 までは普通のパーティションではありませんので、fsck しない方がいいと思います。（実際エラーがでてますが、副作用が無いとはいえません）。
TechTool の eDisk のことは知りませんし、分かりません。

＞少し安心しました。
安心している場合ではないですよ (^^;
最終手段なんて考えずに、まずははにさんのおっしゃるとおりに
sudo mount -r -t hfs /dev/disk0s9 /Volumes/repair
を実行してみて、マウントするのかを確認してデータ救出をすることを優先的に考えた方がいいと思います。
下手にいじりすぎると救えるデータも救えなくなってしまう可能性があります。
一応確認ですが、OS 9からの起動は試していますか？　ちょっと古いNO9さんのコメントにもありますが
OS が変わるとあっさりマウントしてしまうことはままあります。
# OS X -> OS 9 は経験ありませんが、OS 9 -> OS Xは経験あり。

Content not available

Content not available

mount_hfs: stat /Volumes/repair: No such file or directory
/Volume/repair がないよ、というエラーです。
sudo mkdir /Volumes/repair
として作ってやって下さい。
OSX はここにマウントポイントを作りますが、アンマウントするとまた削除してしまいます。すでに一度作られたかも知れませんが、何らかの原因で削除されているのではないかと思います。
うちの 10.3.5 で正常なパーティションをアンマウントしてから、 mount コマンドと、diskutil mount でマウントさせて見ました。
mount でマウントすると、マウントポイントをあらかじめ作っておく必要があります（ま、あたりまえですが）。うまくマウントできても、デスクトップには出てきません。一方、diskutil mount を使うと、マウントポイントを作ってなくても、よきに計らってくれ、マウントされると、デスクトップにも表示されます。ということで、何もトラブルが無ければ、diskutil mount でマウントでき、OSX の振舞いになりますが、これでうまくゆかないときは、mount で半強制的にマウントさせてやる必要があるかな、というところです。

あと、マウント作業がうまくいった後に中身を確認するコマンドは
ls -la /Volumes/repair
です。

Mac OS X のオペレーティングシステムのレベルではそれぞれのdevicesが確認されているのに、最も新しいコマンドラインの出力結果を診ますと、permissionsやnodeの問題を示唆する状況が出ています。これではコマンドラインでは解決しないような気がします。このpermissionsはMac OS X側ではなくディスク上の方だと思います。
マシン本体に接続されているディバイスのうち、内部などのディバイスはNVRAMにレジストリーが保存されます。周辺機器のレジストリやIDなどのリンク情報は、ハードドライブ上のHFS PLus file systemのある領域に、識別情報が動的に格納されては更新されます。この辺のメカニズムに問題を生じていると診ます。問題が起きる前の状況とでは、修復しにくい点が底辺にあるのだと思うのですが．．．
私の方で提案できる最終案は２つです。
NVRAMリセットの直後に、PantherインストールCDから起動して、ディスクを修復してみます。この時点で、マウントされなければ、再初期化をします。これが無理であれば、Mac OS 9.2.2の「ドライブ設定」の低レベルオプションを採用した方法で別マシンなどで行う別案です。