有馬総一郎のブログ

(彼氏の事情)

2024年01月21日 10:39:50 JST - 5 minute read - Comments - Linux

NTFSでフォーマットしたHDDがLinux(Pop!_OS)で自動で認識された

Windows機よりもLinux機ばかり起動するようになって大分経つ。2023 3/11にRyzen 5 5500 + 16Gのベアボーン1を買ったのもあり、それまでのWindows機の増設HDDを外付けHDDケースに移動して、メイン機 Pop!_OSに接続することにした。

ロジテック HDD ケース LHR-2BRHU3に入れ替える。

何もせず自動認識、マウント

初め、Linuxで外付けHDDが認識されなかったが、Windows機に接続しなおして、Windowsからは認識されたのを確認した後に、Linuxに接続しなおしてみたら、認識した上に自動でマウントされた。

NTFS認識用パッケージなどインストール必要がなかった。ディストリビューション(カーネル)2によって、多少の違いはあるかも知れないが、2023年メジャーなLinuxだとなにもせずに認識されると思われる。

自動マウントされたので、どういう状態でマウントされてるのか確認。cat /etc/mtab3で分かる。

$ cat /etc/mtab
/dev/sda1 /media/arimasou16/ボリューム ntfs3 rw,nosuid,nodev,relatime,uid=1000,gid=1000,windows_names,iocharset=utf8 0 0
/dev/sdb2 /media/arimasou16/ボリューム1 ntfs3 rw,nosuid,nodev,relatime,uid=1000,gid=1000,windows_names,iocharset=utf8 0 0

PARTUUID4を調べる。

$ sudo blkid /dev/sd*
/dev/sda: PTUUID="2e63720a-ef9d-ae91-1b48-95d25628253a" PTTYPE="gpt"
/dev/sda1: LABEL="M-cM-^CM-^\M-cM-^CM-*M-cM-^CM-%M-cM-^CM-<M-cM-^CM- " BLOCK_SIZE="512" UUID="DC45A8BF3DBD1BCE" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="efb3d83e-a83b-40c3-2769-b31ddb04397b"
/dev/sdb: PTUUID="bb0c8720-4f1b-9668-b6ba-e6af1246cc9e" PTTYPE="gpt"
/dev/sdb1: PARTLABEL="Microsoft reserved partition" PARTUUID="8b5899c2-9c7a-474a-bfc7-f86969143ada"
/dev/sdb2: LABEL="M-cM-^CM-^\M-cM-^CM-*M-cM-^CM-%M-cM-^CM-<M-cM-^CM- " BLOCK_SIZE="512" UUID="A9508E8F88DF9CA8" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="cec33f3e-2647-6b81-79f1-f3f043757aa7"

それから、マウント失敗のたびに起動できないと嫌なので/etc/fstabオプションについて調べる。

下の記事だとnobootwaitとあるが、上の記事はnofailとある。 What is the difference between ’nobootwait’ and ’nofail’ in fstab? - Unix & Linux Stack Exchangeのベストアンサーの下をみると

nobootwait is no longer a valid option in Ubuntu 16.04

とあり、man fstab fs_mntopsしてもnobootwaitはない。また、実際に追記してみたとき、認識されなかったのでnofailを追記する。

上記を踏まえて、デバイス指定をPARTUUIDにして、マウント失敗時してもブートを保留しないようにnofailを追加して /etc/fstab に外付けHDDを追記する。

PARTUUID=efb3d83e-a83b-40c3-2769-b31ddb04397b  /mnt/hdd1 ntfs3 rw,nosuid,nodev,relatime,uid=1000,gid=1000,windows_names,iocharset=utf8,nofail 0 0
PARTUUID=cec33f3e-2647-6b81-79f1-f3f043757aa7  /mnt/hdd2 ntfs3 rw,nosuid,nodev,relatime,uid=1000,gid=1000,windows_names,iocharset=utf8,nofail 0 0

これで行けるようになったのだが、あるときから

mount: /mnt/hdd1: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.

と失敗するようになってしまった。ntfs3から 3 を取り除いてntfsと指定すると成功するようになった。

ファイルシステムの指定でntfsntfs-3gについては linux - fstab filesystem type for NTFS – ’ntfs’ or ’ntfs-3g’? - Server Faultにあるとおり、

$ ls -l /sbin/mount.ntfs*
lrwxrwxrwx 1 root root 13 11月  1  2022 /sbin/mount.ntfs -> mount.ntfs-3g
lrwxrwxrwx 1 root root 12 11月  1  2022 /sbin/mount.ntfs-3g -> /bin/ntfs-3g

と差はない。しかし、ntfsntfs3はどうなんだろうか、これも同じだろうか?man mount見ても分からない。

単純にファイルサイズを調べた感じや、実際の動作感覚だと呼ばれるものは違うようだが、どうなんだろうか。

$ ls  -l /lib/modules/$(uname -r)/kernel/fs/ntfs*
/lib/modules/6.6.6-76060606-generic/kernel/fs/ntfs:
合計 84
-rw-r--r-- 1 root root 84365 12月 11 23:49 ntfs.ko.zst

/lib/modules/6.6.6-76060606-generic/kernel/fs/ntfs3:
合計 216
-rw-r--r-- 1 root root 217892 12月 11 23:49 ntfs3.ko.zst

など見るとntfsNTFS-3Gの従来のもので、ntfs3はカーネル5.15から利用可能となったNTFSv3ドライバを利用したものなのだろうか?

だとすると、ntfs3の方が良いのかなぁ。しかし、ntfsじゃないと成功しないのでどうしようもない。

また、umaskを指定しないと権限が 777 となってしまうので、最終的に以下のようにしている。

PARTUUID=efb3d83e-a83b-40c3-2769-b31ddb04397b  /mnt/hdd1 ntfs rw,nosuid,nodev,relatime,uid=1000,gid=1000,windows_names,iocharset=utf8,nofail,umask=0022 0 0
PARTUUID=cec33f3e-2647-6b81-79f1-f3f043757aa7  /mnt/hdd2 ntfs rw,nosuid,nodev,relatime,uid=1000,gid=1000,windows_names,iocharset=utf8,nofail,umask=0022 0 0

LinuxによるNTFS領域の書き込みの精度について不安を抱かなくもないが、そのまま使い続けている。

一度、 NTFS is either inconsistent, or there is a hardware fault, or it's a SoftRAID/FakeRAID hardware. In the first case run chkdsk /f on Windows then reboot into Windows twice. The usage of the /f parameter is very important! If the device is a SoftRAID/FakeRAID then first activate it and mount a different device under the /dev/mapper/ directory, (e.g. /dev/mapper/nvidia_eahaabcc1). Please see the 'dmraid' documentation for more details.というエラーが出たので、その時はntfsfixを使うことで解決した。

$ sudo ntfsfix /dev/sdb2
Mounting volume... $MFTMirr does not match $MFT (record 3).
FAILED
Attempting to correct errors... 
Processing $MFT and $MFTMirr...
Reading $MFT... OK
Reading $MFTMirr... OK
Comparing $MFTMirr to $MFT... FAILED
Correcting differences in $MFTMirr record 3...OK
Processing of $MFT and $MFTMirr completed successfully.
Setting required flags on partition... OK
Going to empty the journal ($LogFile)... OK
Checking the alternate boot sector... OK
NTFS volume version is 3.1.
NTFS partition /dev/sdb2 was processed successfully.

その後、外付けHDDへのファイルの書き込みなどを行ったときに固まるということが3回あったが、それはファイルシステムによるものなのか、HDDケースによるものなのか分かない。USB-C、またはUSB-Aでの接続両方試したが、両方固まったことはある。

外付けHDDケースや、ベアボーン側両方がThunderbolt対応だったら、試してみたいが、接続元が対応してないし、対応ケースは思ったより高いので、試せていない。とはいえ、思ってたよりは安定している、とは思う。