Linuxでイミュータブル(変更不可能)なストレージを作成・管理する

Linuxでイミュータブル(変更不可能)なストレージを作成・管理するには、目的(単一ファイル保護か、バックアップ全体保護か)に応じて複数の方法があります。

主な手法は、ファイル属性の変更(chattr)、ファイルシステム単位での読み取り専用マウント、そしてVeeamなどのバックアップソフトウェアによるハードニング(Linux強化リポジトリ)です。

1. chattr コマンドによるファイル/ディレクトリのロック

ext3ext4xfs などのファイルシステム上で、ファイルやディレクトリに「イミュータブル属性(+i)」を付与します。この属性を持つファイルは、rootユーザーであっても修正、削除、名前の変更、リンクの作成ができません。 

  • 属性を付与する (不変にする):
    bash
    sudo chattr +i /path/to/file_or_directory
  • 属性を確認する:
    bash
    lsattr /path/to/file_or_directory
  • 属性を解除する (戻す):
    bash
    sudo chattr -i /path/to/file_or_directory
  • 用途: 設定ファイル、システムバイナリ、アーカイブデータなど、絶対に変更されたくない単一ファイルやディレクトリの保護。

2. ファイルシステムの読み取り専用(Read-Only)マウント

ストレージをOS全体として読み取り専用でマウントします。

  • 一時的に読み取り専用で再マウントする:
    bash
    sudo mount -o remount,ro /mnt/data
  • fstabで永続的に設定する:
    /etc/fstab のオプションに ro を追加します。text/dev/sdb1 /mnt/data ext4 defaults,ro 0 2
  • 用途: データウェアハウス、監査ログなど、書き込みが完了したデータを保護する。 

3. Linux強化リポジトリ(Veeam式)

バックアップソフト「Veeam」が推奨する手法で、バックアップデータを数日間~数週間、rootユーザーでも消せない「真のイミュータブル」にします。これは以下の要素の組み合わせで実現されます。 

  1. 専用のLinuxサーバー: Veeamがsshで専用ユーザーでアクセス。
  2. XFSファイルシステムreflink 機能を利用して高速かつ保護されたデータ保持。
  3. 一時的なイミュータビリティ設定: バックアップデータに一定期間(例: 7日間)の不変フラグを適用。
  • メリット: ランサムウェアがroot権限を持っても、指定期間内はバックアップを削除・暗号化できない。 

4. 追記専用(Append-only)ストレージ

ファイルに「追記」のみ許可する属性(+a)を付与します。既存データは変更できませんが、新しいログを追記し続けることができます。 

  • 属性を付与する:
    bash
    sudo chattr +a /var/log/app.log

注意事項

  • rootの権限chattr +i でロックされたファイルは、rootであっても -i を外さなければ削除できません。
  • バックアップ保護の注意点: イミュータブル設定した期間は、たとえ正当な業務であっても、データの削除や上書きが不可能になるため、運用の設計が必要です。

Linuxでストレージ(ファイルやディレクトリ)をイミュータブル(不変)にするアプローチ


Linuxでストレージ(ファイルやディレクトリ)をイミュータブル(不変)にするアプローチとして、「バックアップをとってから chattr で属性を変更する」という流れは、個別のファイル保護としては非常に理にかなっています。

ただし、システムの運用目的によっては「ファイル単位」ではなく「ファイルシステム全体」を保護する方が安全な場合もあります。

現状の手順の確認と、より堅牢にするためのポイントを整理しました。


1. ご提示の手順の確認と詳細

chattr コマンドを使用する方法は、Linuxの拡張属性(Ext4やXFSなど)を利用した標準的な保護手法です。

手順の詳細

  1. バックアップ: 万が一設定を間違えたり、後で元の状態に戻せなくなったりするのを防ぐため、コピーを取っておくのは非常に良い習慣です。
  2. 属性の設定: 以下のコマンドで「不変(Immutable)」属性を付与します。
    Bash
    sudo chattr +i [ファイル名またはディレクトリ名]
    • 効果: rootユーザーであっても、この属性を外さない限り、削除、名前変更、書き込み、リンク作成ができなくなります。
    • ディレクトリに適用する場合: 中にあるファイルも再帰的にロックするには -R オプションを使います。
      Bash
      sudo chattr -R +i /path/to/directory

2. さらに堅牢にするためのステップ

「イミュータブルなストレージ」という目的が、セキュリティ向上や誤操作防止であれば、以下の点も考慮するとより確実です。

属性の確認方法

設定した後は、正しく適用されているか確認しましょう。

Bash

lsattr [ファイル名]

----i--------- のように i が表示されていれば成功です。

リードオンリー・マウント(より強力な方法)

特定のディレクトリやパーティション全体を「読み取り専用」にしたい場合は、マウント時に制限をかけるのが一般的です。

  • 一時的な変更:
    Bash
    sudo mount -o remount,ro /target/path
  • 恒久的な変更: /etc/fstab にて、該当のパーティションのオプションに ro (read-only) を追記します。

注意点:物理的な破壊やフォーマットには無力

chattr +i はOSの論理的なレベルでの保護です。

OSを介さずにストレージを直接操作された場合(別のPCに接続して操作するなど)は、この属性が無視されることがあります。

ディスク自体の物理的な故障や、ディスク全体のフォーマット(初期化)は防げません。


バックアップ全体をイミュータブル化をする

バックアップデータそのものをイミュータブル(不変)化するのは、ランサムウェア対策や誤削除防止として非常に強力な手段です。

「バックアップ全体」を対象にする場合、ファイル単位の chattr よりも、ストレージ層やファイルシステム層でロックをかける手法が一般的です。主な3つのアプローチを解説します。


1. ファイルシステム・レベル(論理ロック)

OS上のファイルシステム機能を使い、書き込み権限を物理的に遮断する方法です。

手順:読み取り専用(Read-Only)マウント

バックアップが完了した直後に、そのパーティションを「読み取り専用」に切り替えます。

  1. バックアップ実行(通常通り書き込み)
  2. 読み取り専用に再マウント:Bashsudo mount -o remount,ro /dev/sdb1 /mnt/backup /dev/sdb1 はバックアップ用ディスクのデバイス名です。
  3. 確認: mount | grep /mnt/backup(ro,...) と表示されれば、rootユーザーでも書き込み・削除ができません。

2. オブジェクトストレージ・レベル(S3 Object Lock)

もしクラウド(AWS S3や互換性のあるMinIOなど)をバックアップ先にしている場合、「Object Lock」という機能が使えます。

  • 仕組み: 指定した期間(例:30日間)、削除や上書きをAPIレベルで拒否します。
  • メリット: 管理者アカウントが乗っ取られても、保持期間が過ぎるまでデータは絶対に消せません。

3. バックアップ専用ツールによる「不変バックアップ」

最近のバックアップツール(Veeam, Restic, BorgBackupなど)には、標準でイミュータブル機能が備わっているものが多いです。

Restic + REST Server の例

Linuxサーバーをバックアップ用リポジトリにする場合、rest-server--append-only モードで起動すると、**「データの追加はできるが、既存データの削除・変更は一切受け付けない」**状態にできます。

Bash

# サーバー側で追記専用モードで起動
./rest-server --path /path/to/backups --append-only

4. 物理的な保護(究極のイミュータブル)

最も原始的ですが、最も確実な方法です。

  • LTOテープ: 書き込み後に「ツメ」を折る、またはWORM(Write Once Read Many)メディアを使用する。
  • SDカード/USBメモリ: 物理的な書き込み禁止スイッチを「Lock」側にする。

運用上のアドバイス:保持期間の設定

「一生消せない」設定にしてしまうと、ストレージがいっぱいになった時に困ります。実運用では以下の2段階で考えるのがベストです。

  1. バックアップ時: 書き込み可能モードで実行。
  2. 完了後: ツールまたはOS側で「30日間ロック」などの期限付きイミュータブル設定を入れる。


バックアップツール(Veeam, Restic, BorgBackupなど)で無料のツール

挙げられた3つのツールは、いずれも無料で利用できる「Community Edition」や「オープンソース版」が存在しますが、**「Linuxでの使いやすさ」「イミュータブル(不変)化のしやすさ」**で選ぶなら、以下の順序で検討するのがおすすめです。


1. Restic (完全無料・オープンソース)

「シンプルさ」と「不変バックアップ」を両立したい場合に最適です。

  • 特徴: シングルバイナリで動作し、インストールが非常に簡単です。
  • イミュータブル化: rest-server という公式のサーバーソフトを併用し、--append-only オプションを付けて起動するだけで、**「バックアップの追加はできるが、過去のデータ削除は一切受け付けない」**という不変ストレージを簡単に構築できます。
  • 向いている人: Linuxのコマンドライン操作に慣れており、手軽にセキュアなバックアップ環境を作りたい方。

2. BorgBackup (完全無料・オープンソース)

「保存容量の節約(圧縮率)」を重視する場合に最適です。

  • 特徴: 重複排除と圧縮機能が非常に強力で、バックアップデータが驚くほど小さくなります。
  • イミュータブル化: Restic同様に append-only モードがありますが、設定には少し手間がかかります。また、基本的には「サーバー・クライアント」構成で真価を発揮します。
  • 向いている人: 大容量のデータを扱っており、ストレージ費用や容量を節約したい方。

3. Veeam Backup & Replication (Community Edition)

「GUI(画面)で操作したい」「Windowsも含めて一括管理したい」場合に最適です。

  • 無料版の制限: 「Community Edition」として、最大10インスタンス(VMや物理サーバー)まで無料で利用可能です。
  • イミュータブル化: Linuxサーバーを「Hardened Repository(強化されたリポジトリ)」として設定することで、ファイルシステムレベルで不変属性を自動管理してくれます。
  • 向いている人: コマンド操作よりもマウスでのGUI管理を好み、エンタープライズ級の機能を無料で試したい方。

ツールの比較まとめ

ツール名ライセンス操作性イミュータブル化の難易度特徴
Restic完全無料CLI低 (専用サーバーで簡単)爆速・シンプル・クラウド対応
BorgBackup完全無料CLI中 (設定が必要)高圧縮・高機能・実績豊富
Veeam10台まで無料GUI中 (Linuxの知識が必要)高機能・商用クオリティ

個人的な推奨

Linuxに詳しく、すでにサーバーを管理されているのであれば、まずは Restic を試してみるのが最も近道です。特に、ご自身でWebシステムを開発されている技術力があれば、Resticのシンプルさは非常に扱いやすく感じるはずです。

カテゴリー: 未分類 | コメントする

sshで「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」原因と対策は?

「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」は、SSH接続先サーバーの識別情報(ホスト鍵)が前回と異なる場合に表示されるセキュリティ警告です。主な原因はサーバー再構築やIPアドレスの変更です。対策として、端末の~/.ssh/known_hostsから該当ホストの旧情報を削除(ssh-keygen -R [IPまたはホスト名])します

原因

  • サーバーの再構築・入れ替え: サーバーのOS再インストールや再設定により、ホスト鍵が変更された。
  • IPアドレスの再利用: DHCPなどで、以前とは別のサーバーに同じIPアドレスが割り当てられた。
  • 中間者攻撃 (Man-in-the-Middle Attack): 悪意のある第三者が通信を傍受している(可能性は低いが、セキュリティリスクとして警告される)。 

対策(解決手順)

最も安全で一般的な方法は、ローカルマシンのknown_hostsファイルから古い情報を削除し、再登録することです。

1. コマンドで該当ホストの情報を削除(推奨)

ターミナル(端末)で以下のコマンドを実行します。

bash

ssh-keygen -R [接続先のIPアドレスまたはホスト名]

このコマンドにより、~/.ssh/known_hostsから該当する行が自動的に削除されます。 

2. 再度SSH接続

エラーが出たSSH接続コマンドを再度実行します。 

bash

ssh username@hostname

新しいホスト鍵を登録するか尋ねられるので、「yes」と入力して接続を確定させます。 

3. 手動でファイルを編集して削除 

もしコマンドが使えない場合は、エディタで ~/.ssh/known_hosts を開き、警告メッセージに表示された行数(例: Offending ECDSA key in /Users/xxx/.ssh/known_hosts:413)を直接削除します。

注意点

もし、サーバーの変更など思い当たる節がないのにこのエラーが表示された場合、第三者による不正アクセス(なりすまし)の可能性があります。管理者に確認してください。

カテゴリー: 未分類 | コメントする

MariaDBのパッケージ削除時に「Unmet dependencies(未解決の依存関係)」エラー

MariaDBのパッケージ削除時に「Unmet dependencies(未解決の依存関係)」エラーが発生し、通常の削除がブロックされている状態ですね。この場合、依存関係を無視して強制的に削除を進める必要があります。

以下の手順で解決を試みてください。

1. 依存関係の修復を試みる

指示通り、まずは標準の修復コマンドを実行します。 

bash

sudo apt --fix-broken install

コードは注意してご使用ください。

これで解決しない場合は、以下の強制削除の手順へ進んでください。

2. dpkg での強制削除

apt は依存関係に厳格なため、より低レイヤーの dpkg コマンドを使用して、依存関係を無視してパッケージを削除します。 

bash

# インストールされている関連パッケージを確認
dpkg -l | grep -e mysql -e mariadb

# 依存関係を無視して強制削除(package-nameを上記で確認した名前に置き換え)
sudo dpkg --purge --force-all mariadb-server mariadb-client mariadb-common

コードは注意してご使用ください。

※ mariadb-server-core-* などの個別パッケージ名も同様に指定して実行してください。

3. 残った関連ファイルのクリーンアップ

パッケージ本体が消えても設定ファイルなどが干渉することがあります。以下のディレクトリを手動で削除することで、クリーンな状態に戻せます。 

bash

sudo rm -rf /etc/mysql /var/lib/mysql /var/log/mysql
sudo apt autoremove
sudo apt autoclean

コードは注意してご使用ください。

4. (再インストールする場合)

完全に削除できたことを確認(dpkg -l | grep mariadb で何も出ない状態)してから、再度インストールを行ってください。 

bash

sudo apt update
sudo apt install mariadb-server
カテゴリー: 未分類 | コメントする

Ubuntuのパッケージが壊れてしまった場合

buntuがWindowsと違い、GUIやapt自体でさえも削除できる自由があります。その高い自由度時々危険さが高いです。パッケージをインストールする時などにパッケージマネージャー( )がapt-get動かなくなることがあります。

パッケージが通じない場合

エラーメッセージ

$ sudo apt-get install <パッケージ名>

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package <パッケージ名>

または

E: Package '<パッケージ名>' has no installation candidate

解決方法

初めとしてをsudo apt-get updateしましょう。

パッケージがまだ行っていない場合、Ubuntu の完成パッケージリスト(下記)があってないを意味します。

/etc/apt/sources.list

以下のコマンドでリストを追加できますが、正しいパッケージはインストールしたいパッケージによって異なります。 Googleで検索することをおすすめします。

$ sudo apt-key adv --fetch-keys <パッケージリストのURL>
$ sudo apt-get update

パッケージのコンフリクトがあった場合

パッケージのコンフリクトがあった場合、既にインストールされているパッケージの依存関係ツリーとインストールしようとしているパッケージの依存関係ツリーのバージョンは非互換です。そのため、パッケージをインストールする時のログを注意し、確認事で新たな問題が発生してしまう可能性があります。

エラーメッセージ

以下のようなエラーメッセージが表示された場合、パッケージの矛盾があることを意味します。

$ sudo apt-get install <パッケージ名>

Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
n
The following packages have unmet dependencies:
 nvidia-jetpack : Depends: nvidia-jetpack-runtime (= 5.0.1-b118) but it is not going to be installed
                  Depends: nvidia-jetpack-dev (= 5.0.1-b118) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

適切に解決する方法

コンフリクトを解決できる事もありますが、apt全ての問題解決コマンドを試してみる事をおすすめします。その他のパッケージの問題もある場合にお役に立ちます。

$ sudo apt-get update
$ sudo apt-get clean
$ sudo apt-get autoremove
$ sudo apt-get autoclean
$ sudo apt-get --fix-broken install
$ sudo apt-get upgrade
$ sudo apt-get dist-upgrade

1つずつのパッケージの正しいバージョンをインストールする事でコンフリクトを解決できますが、関連パッケージの関連パッケージなども含むと数パッケージから数百パッケージのバージョンを自分で修正する必要があるかもしれません。

残念ながら、aptはコンフリクトに得意ではありませんが、その代わりというaptitudeツールがあります。

適性について

aptitudeaptと違い、コンフリクトがあった時、複数の解決方法を表示してくれますapt

aptitudeがUbuntuの優れたパッケージマネージャーではないため、インストールする必要があります。

$ sudo apt-get install aptitude

aptitudeでのパッケージのインストールコマンドがaptでのコマンドと同じであり、使いやすいと思います。

$ sudo aptitude install <パッケージ名>

コマンド実行の結果の例を紹介します。

The following NEW packages will be installed:
  nvidia-container{ab} nvidia-jetpack nvidia-jetpack-dev{a} nvidia-jetpack-runtime{a} 
0 packages upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 117 kB of archives. After unpacking 795 kB will be used.
The following packages have unmet dependencies:
 nvidia-container : Depends: nvidia-docker2 (= 2.10.0-1) but 2.11.0-1 is installed
                    Depends: libnvidia-container-tools (= 1.9.0-1) but 1.11.0-1 is installed
                    Depends: nvidia-container-toolkit (= 1.9.0-1) but 1.11.0-1 is installed
                    Depends: libnvidia-container1 (= 1.9.0-1) but 1.11.0-1 is installed
                    Depends: nvidia-container-runtime (= 3.9.0-1) but 3.11.0-1 is installed
The following actions will resolve these dependencies:

     Keep the following packages at their current version:
1)     nvidia-container [Not Installed]                   
2)     nvidia-jetpack [Not Installed]                     
3)     nvidia-jetpack-dev [Not Installed]                 
4)     nvidia-jetpack-runtime [Not Installed]             



Accept this solution? [Y/n/q/?] n

最初に紹介されるコンフリクトの解決方法がaptと同様であるため、nを記入し、スキップします。

The following actions will resolve these dependencies:

     Remove the following packages:                                                  
1)     nvidia-container-toolkit-base [1.11.0-1 (bionic, now)]                        

     Downgrade the following packages:                                               
2)     libnvidia-container-tools [1.11.0-1 (bionic, now) -> 1.9.0-1 (bionic, stable)]
3)     libnvidia-container1 [1.11.0-1 (bionic, now) -> 1.9.0-1 (bionic, stable)]     
4)     nvidia-container-runtime [3.11.0-1 (bionic, now) -> 3.9.0-1 (bionic, stable)] 
5)     nvidia-container-toolkit [1.11.0-1 (bionic, now) -> 1.9.0-1 (bionic, stable)] 
6)     nvidia-docker2 [2.11.0-1 (bionic, now) -> 2.10.0-1 (bionic, stable)]          

Accept this solution? [Y/n/q/?] Y

この例で次に紹介された解決方法がdowngradeでました。 変更されるパッケージを確認し、問題がなさそうなダメYを記入しました。

The following packages will be DOWNGRADED:
  libnvidia-container-tools libnvidia-container1 nvidia-container-runtime nvidia-container-toolkit nvidia-docker2 
The following NEW packages will be installed:
  nvidia-container{a} nvidia-jetpack nvidia-jetpack-dev{a} nvidia-jetpack-runtime{a} 
The following packages will be REMOVED:
  nvidia-container-toolkit-base{a} 
0 packages upgraded, 4 newly installed, 5 downgraded, 1 to remove and 0 not upgraded.
Need to get 1,817 kB of archives. After unpacking 4,485 kB will be freed.
Do you want to continue? [Y/n/?] Y

変更されるパッケージの再度の確認の上をY記入しますとパッケージが実際にインストールし始めます。

Get: 1 https://nvidia.github.io/libnvidia-container/stable/ubuntu18.04/arm64  nvidia-docker2 2.10.0-1 [5,536 B]
...

途中で得られるエラー

ただし、途中で以下のようなエラーが表示されることもあります。

debconf: delaying package configuration, since <依存パッケージの名前> is not installed

その場合はそのパッケージを事前にインストールし、aptitude install再度実行する必要があります。

$ sudo apt-get install <依存パッケージの名前> -y
$ sudo aptitude install <パッケージ名>

または、以下のようなエラーメッセージも表示される事があります。

trying to overwrite '/etc/.../config.toml', which is also in package <依存パッケージの名前> <パッケージのバージョン>

その場合、事前に<依存パッケージの名前>を削除してから、または全ての依存パッケージをアンインストールしてくださいaptitude install

$ sudo apt-get remove <依存パッケージの名前> -y
$ sudo aptitude install <パッケージ名>

まとめ

Ubuntuのパッケージ管理が自由であるため、aptパッケージの依存関係ツリーが壊れてしまう事があります。

aptが対応できない場合、情報が多いため、aptitudeの使用をおすすめします。

カテゴリー: 未分類 | コメントする

Linux上のMariaDBにNavicatなどの外部管理ツールからアクセスする。

1. MariaDB設定ファイル(my.cnf)の修正

MariaDBが外部IPからの接続を許可するようにバインドアドレスを変更します。 

  • 設定ファイルの位置: 通常は /etc/my.cnf/etc/mysql/my.cnf、または /etc/my.cnf.d/server.cnf です。
  • 修正手順:
    1. テキストエディタで設定ファイルを開く (例: sudo nano /etc/my.cnf.d/server.cnf)。
    2. [mysqld] セクションを見つける。
    3. bind-address = 127.0.0.1 という行があれば、0.0.0.0 に変更するか、コメントアウト(先頭に #)します。ini[mysqld] # bind-address = 127.0.0.1 <- コメントアウトする bind-address = 0.0.0.0 <- すべてのIPを許可
    4. ファイルを保存して閉じる。
    5. MariaDBを再起動して設定を適用する: sudo systemctl restart mariadb。 

2. リモートアクセス権限の追加

MariaDBのユーザが特定のホスト(例: 開発用PC)からアクセスできるように許可設定を行います。 

  • 手順:
    1. ターミナルからMariaDBにrootユーザでログインする: mysql -u root -p
    2. 以下のSQLコマンドを実行して、リモート用ユーザを作成し権限を付与する。sql-- 全てのデータベースへのアクセスを許可する場合 GRANT ALL PRIVILEGES ON *.* TO 'user'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION; -- 特定のデータベースへのアクセスを許可する場合(推奨) -- GRANT ALL PRIVILEGES ON database_name.* TO 'user'@'%' IDENTIFIED BY 'password'; FLUSH PRIVILEGES; EXIT;
      • 'user'@'%' の % は全てのIPアドレスから接続を許可することを意味します。特定の固定IPのみ許可したい場合は % をそのIPアドレス(例: '192.168.1.10') に変更してください。 

3. ファイアウォールの開放

Linuxサーバのファイアウォール(ufwやfirewalld)でMariaDBのポート(デフォルト: 3306)を開放します。 

  • UFWの場合sudo ufw allow 3306/tcp
  • Firewalldの場合sudo firewall-cmd --permanent --add-port=3306/tcp -> sudo firewall-cmd --reload

4. Navicatでの接続設定 

Navicatで以下の項目を入力して接続します。

  • Host Name/IP Address: MariaDBサーバーのIPアドレス
  • Port: 3306
  • Username: 上記で設定したユーザ名 (例: user)
  • Password: 上記で設定したパスワード 

注意点

  • セキュリティbind-address = 0.0.0.0 と % での権限付与は、誰でもアクセスできる状態になるため、必ず強固なパスワードを使用し、可能であれば特定のIPアドレスのみアクセス許可するようにしてください。
  • SSHトンネル: クラウド環境などで直接ポートを開けられない場合は、Navicatの「SSH」機能を使用して、SSH経由でMariaDBにアクセスする方法が安全です。 

カテゴリー: 未分類 | コメントする

Sambaのインストール

UbuntuにSambaをインストールしてファイルサーバーを構築する基本的な手順は以下の通りです。この手順は、Ubuntu DesktopでもUbuntu Serverでもほぼ同じですが、細かな設定は目的によって異なります。

1. パッケージの更新とSambaのインストール

まず、システムを最新の状態に更新し、Sambaパッケージをインストールします。

Bash

sudo apt update
sudo apt upgrade
sudo apt install samba

2. 共有フォルダの作成と権限の設定

共有したいフォルダを作成し、Sambaでアクセスできるように適切な権限を設定します。既存のフォルダを共有することも可能です。

Bash

# 例: /home/your_username/share というフォルダを共有する場合
mkdir -p /home/your_username/share

# 共有フォルダの権限を設定 (例: グループに書き込み権限を与え、他は読み取りのみ)
# あなたの環境に合わせて変更してください。
# この例では、所有者とグループにフルアクセス、その他に読み取りと実行権限を与えています。
chmod 775 /home/your_username/share

# フォルダの所有者とグループをSambaユーザーまたは適切なユーザーに変更することも検討してください
# 例: chown your_username:your_username /home/your_username/share

重要: 権限設定はセキュリティに直結します。必要以上に緩い権限(例: chmod 777)を設定することは推奨されません。

3. Samba設定ファイルの編集

Sambaの設定ファイルは /etc/samba/smb.conf です。このファイルを編集して、共有するフォルダの情報を追加します。編集する前に、元のファイルをバックアップすることをお勧めします。

Bash

sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak
sudo nano /etc/samba/smb.conf

smb.conf の最後に、以下のような共有設定を追加します。

Ini, TOML

[share]
    comment = Ubuntu Shared Folder
    path = /home/your_username/share  # 上で作成した共有フォルダのパス
    browseable = yes                  # ネットワーク上で表示されるようにする
    read only = no                    # 書き込み可能にする
    guest ok = yes                    # ゲストアクセスを許可する (ユーザー認証なし)
    create mask = 0664                # 新規作成ファイルの権限 (所有者とグループに書き込み許可)
    directory mask = 0775             # 新規作成ディレクトリの権限 (所有者とグループに書き込み許可)
    # valid users = your_username     # 特定のユーザーのみアクセスを許可する場合 (guest ok = no と併用)
※ #マークのコメントは下記のように改行として使ってください。そのままだと起動時にエラーが出ます。
 path = /home/your_username/share
  # 上で作成した共有フォルダのパス
 browseable = yes
  # ネットワーク上で表示されるようにする

ポイント:

  • [share] は、Windowsなどからアクセスする際に表示される共有名です。
  • path は、実際に共有するUbuntu上のフォルダのパスです。
  • guest ok = yes は、ユーザー名とパスワードなしでアクセスできるようにする設定です。セキュリティ上の理由から、通常は guest ok = no に設定し、valid users で特定のユーザーのみにアクセスを許可することが推奨されます。

ユーザー認証が必要な場合(推奨)

もし guest ok = no に設定してユーザー認証を行う場合は、以下の設定を検討してください。

Ini, TOML

[share]
    comment = Ubuntu Shared Folder
    path = /home/your_username/share
    browseable = yes
    read only = no
    guest ok = no
    valid users = your_username  # アクセスを許可するLinuxユーザー名
    create mask = 0664
    directory mask = 0775

また、[global] セクションに以下の設定を追加して、セキュリティを向上させることも検討してください。

Ini, TOML

[global]
    # ... 既存の設定 ...
    client min protocol = NT1 # 古いWindowsクライアントとの互換性が必要な場合
    server min protocol = SMB2_02 # より新しいプロトコルを強制する場合

    # DNSで名前解決できない場合にWINSサーバーを使う設定 (通常は不要)
    ; wins support = yes

    # ローカルユーザーとSambaユーザーのパスワード同期を試みる (非推奨の古い方法)
    ; unix password sync = yes

設定ファイルを保存してエディタを閉じます(nanoの場合は Ctrl + O で保存、Ctrl + X で終了)。

4. Sambaユーザーの作成

Sambaで共有フォルダにアクセスするユーザーを作成します。このユーザーは、Ubuntuのシステム上に存在するユーザーである必要があります。

Bash

sudo smbpasswd -a your_username

your_username の部分を、実際に共有フォルダにアクセスするLinuxユーザー名に置き換えてください。このコマンドを実行すると、Samba用のパスワードを設定するように求められます。このパスワードは、Linuxのログインパスワードとは異なるものを設定できますが、同じにすることも可能です。

Linuxシステム上でグループを作成し、そこにメンバー(ユーザー)を追加する一連の流れを解説します。

Sambaで共有フォルダへのアクセスを制限する際、個別にユーザーを指定するよりも「グループ」で管理したほうがメンテナンスが楽になります。


1. グループを作成する

まずは、新しいグループを作成します。

Bash

sudo groupadd グループ名

例:sudo groupadd developers

2. 既存のユーザーをグループに追加する

既存のユーザーを特定のグループに所属させます。

Bash

sudo usermod -aG グループ名 ユーザー名
  • -a (append): 現在所属している他のグループから外れないように「追記」します。
  • -G (groups): 対象となるグループを指定します。

例:sudo usermod -aG developers tanaka

3. 新規ユーザーを作成してグループに追加する

まだユーザーが存在しない場合、作成と同時にグループに所属させることができます。

Bash

sudo adduser ユーザー名
sudo usermod -aG グループ名 ユーザー名

4. 正しく登録されたか確認する

ユーザーがどのグループに所属しているかを確認するには groups コマンドを使います。

Bash

groups ユーザー名

実行結果に指定したグループ名が含まれていれば成功です。


5. 【重要】フォルダ自体の権限設定

グループを smb.confvalid users に書くだけでは不十分な場合があります。Linux側のディレクトリ(フォルダ)自体にも、そのグループがアクセスできる権限を与える必要があります。

Bash

# 1. フォルダの所有グループを変更する
sudo chgrp -R グループ名 /path/to/share

# 2. グループに対して書き込み権限を与える
sudo chmod -R 775 /path/to/share

まとめ:コマンドの流れ

  1. グループ作成: sudo groupadd tech
  2. ユーザー追加: sudo usermod -aG tech user1
  3. Samba設定変更: valid users = @tech
  4. ディレクトリ権限変更: sudo chgrp tech /home/share
  5. 再起動: sudo systemctl restart smbd

これで、tech グループに属するユーザー全員がSamba経由でアクセスできるようになります。

Sambaユーザーの一覧を表示するコマンド

Sambaユーザーの一覧を表示するコマンドは、pdbedit -L です。このコマンドは、登録されているSambaユーザーのIDや名称を表示します。詳細な情報を確認したい場合は、pdbedit -L -v を使用します。これらのコマンドは管理者権限(sudo)で実行する必要があります。 

代表的なコマンドとオプション:

  • pdbedit -L: 登録済みのSambaユーザー一覧(簡易)
  • pdbedit -L -v: 登録済みのSambaユーザー詳細一覧
  • pdbedit -Lw: 旧形式(smbpasswd形式)で一覧を表示 

これらのコマンドはSamba 3系以降、ユーザーデータベースを管理する際に利用されます


========================================================================

5. Sambaサービスの再起動

設定変更を反映させるために、Sambaサービスを再起動します。

Bash

sudo systemctl restart smbd nmbd

または

Bash

sudo service smbd restart
sudo service nmbd restart

6. ファイアウォールの設定 (UFWを使用している場合)

Ubuntuのファイアウォール (UFW) を有効にしている場合は、Sambaの通信を許可する必要があります。

Bash

sudo ufw allow samba
sudo ufw enable # UFWがまだ有効になっていない場合

7. アクセスの確認

Windowsや他のLinux、macOSからSamba共有にアクセスできるか確認します。

Windowsからのアクセス

  1. エクスプローラーを開き、アドレスバーに \\<UbuntuのIPアドレス> または \\<Ubuntuのホスト名> と入力してEnterキーを押します。 例: \\192.168.1.100 または \\ubuntu-server
  2. ユーザー名とパスワードを求められたら、Sambaユーザーとして設定したユーザー名とSambaパスワードを入力します。
  3. 共有フォルダが表示されれば成功です。

Linuxからのアクセス

ファイルマネージャー(Nautilus, Dolphinなど)から「他の場所」や「ネットワーク」などを選択し、smb://<UbuntuのIPアドレス> または smb://<Ubuntuのホスト名> と入力して接続を試みます。

macOSからのアクセス

Finderのメニューバーから「移動」>「サーバーへ接続…」を選択し、smb://<UbuntuのIPアドレス> または smb://<Ubuntuのホスト名> と入力して接続を試みます。

これで、UbuntuにSambaサーバーが設定され、ファイル共有ができるようになります。問題が発生した場合は、smb.conf の設定や共有フォルダの権限、ファイアウォールの設定などを再確認してください。

Sambaの再起動コマンド

Sambaの再起動コマンドは、使用しているUbuntuのバージョンやシステム構成によっていくつか選択肢がありますが、現在主流のsystemdを採用しているUbuntu(多くのモダンなバージョン)では、以下のコマンドが一般的かつ推奨されます。

推奨される再起動コマンド:

Bash

sudo systemctl restart smbd nmbd

このコマンドは、Sambaの主要な2つのサービス、smbd(SMB/CIFSファイル共有デーモン)とnmbd(NetBIOS over TCP/IPネームサービスデーモン)の両方を再起動します。通常、Sambaの設定ファイル (smb.conf) を変更した後に、このコマンドを実行して変更を反映させます。

個別のサービスを再起動する場合:

  • smbd のみ再起動:Bashsudo systemctl restart smbd
  • nmbd のみ再起動:Bashsudo systemctl restart nmbd 通常は両方再起動することが推奨されますが、smbd の設定変更が主で、NetBIOS名解決に問題がない場合はsmbdのみでも良い場合があります。

古いSysVinitスタイルのコマンド(古いUbuntuや他のLinuxディストリビューションで使用される可能性あり):

もし上記の systemctl コマンドが機能しない、または非常に古いUbuntuバージョンを使用している場合は、以下のコマンドも試せます。

Bash

sudo service smbd restart
sudo service nmbd restart

確認方法:

再起動後、Sambaサービスが正常に動作しているか確認するには、以下のコマンドを使用します。

Bash

sudo systemctl status smbd
sudo systemctl status nmbd

両方のコマンドの出力で「Active: active (running)」と表示されていれば、サービスは正常に動作しています。

UbuntuでSambaが起動しているか確認

UbuntuでSambaが起動しているか確認する方法はいくつかあります。主に以下のコマンドを使用します。

1. systemctl status コマンド (推奨)

これが最も確実で推奨される方法です。Sambaの主要なサービスである smbdnmbd の状態を確認します。

Bash

sudo systemctl status smbd
sudo systemctl status nmbd

確認ポイント:

  • Active: active (running) と表示されているか。これが表示されていれば、サービスは正常に動作しています。
  • エラーメッセージが表示されていないか。エラーがある場合は、その内容から原因を探ることができます。

例:

$ sudo systemctl status smbd
● smbd.service - Samba SMB/CIFS server
     Loaded: loaded (/lib/systemd/system/smbd.service; enabled; vendor preset: enabled)
     Active: active (running) since Sun 2025-07-06 17:00:00 JST; 20min ago
       Docs: man:smbd(8)
             man:samba(7)
   Main PID: 1234 (smbd)
     Status: "smbd: ready to serve connections..."
      Tasks: 4 (limit: 4616)
     Memory: 10.5M
        CPU: 123ms
     CGroup: /system.slice/smbd.service
             ├─1234 /usr/sbin/smbd --foreground --no-process-group
             ├─1235 /usr/sbin/smbd --foreground --no-process-group
             └─1236 /usr/sbin/smbd --foreground --no-process-group

Jul 06 17:00:00 ubuntu systemd[1]: Started Samba SMB/CIFS server.

2. smbstatus コマンド

このコマンドは、Sambaサーバーに現在接続しているユーザーやロックされているファイルなど、Sambaの現在の接続状況や稼働状況の詳細を表示します。Sambaサービスが起動していなければ、このコマンドはエラーになります。

Bash

smbstatus

確認ポイント:

  • コマンドを実行した際にエラーが出ずに、何らかの出力が表示されるか。
  • Samba versionServicePID などの情報が表示されれば、Sambaは起動しています。
  • 現在接続しているクライアントがあれば、その情報も表示されます。

例:

$ smbstatus

Samba version 4.15.13-Ubuntu
PID     Username     Group        Machine                                   Protocol Version  Encryption           Signing
----------------------------------------------------------------------------------------------------------------------------------------
2345    your_username your_group   192.168.1.10 (ipv4:192.168.1.10:50000)      SMB3_11           AES-128-GCM          AES-128-CMAC

Service      Pid     Duration of lock       File
------------------------------------------------------------------------------------------

No locked files

3. ps aux | grep samba または pgrep smbd

これらのコマンドは、Sambaプロセスがシステム上で実行されているかを確認します。

Bash

ps aux | grep smbd
ps aux | grep nmbd

または

Bash

pgrep smbd
pgrep nmbd

確認ポイント:

  • ps aux | grep の場合、smbdnmbd のプロセスに関する行が表示されるか。
  • pgrep の場合、プロセスのPID(プロセスID)が表示されるか。PIDが表示されれば、そのプロセスは実行中です。何も表示されなければ、実行されていません。

これらの方法で、Ubuntu上のSambaサービスが正常に起動しているかを確認できます。通常は sudo systemctl status smbdsudo systemctl status nmbd を確認するのが最も手軽で確実です。

Sambaをシステム起動時に常時起動する

Sambaをシステム起動時に常時起動するように設定するコマンドは、以下の通りです。

Bash

sudo systemctl enable smbd
sudo systemctl enable nmbd

このコマンドは、smbd (Samba SMB/CIFSサーバー) と nmbd (NetBIOS over TCP/IPネームサービスデーモン) の両方を、システム起動時に自動的に開始するよう設定します。

補足:

  • enable コマンドは、サービスを「有効化」するもので、即座にサービスを起動するわけではありません。サービスをすぐに起動したい場合は、別途 sudo systemctl start smbd nmbd コマンドを実行する必要があります。
  • 一度 enable に設定すれば、システムを再起動するたびにSambaサービスが自動的に起動するようになります。
  • 現在の自動起動設定を確認するには、sudo systemctl is-enabled smbdsudo systemctl is-enabled nmbd コマンドを使用します。enabled と表示されれば、自動起動が有効になっています。
カテゴリー: 未分類 | コメントする

Linuxにおける「リカバリーポイント」Timeshift

Linuxにおける「リカバリーポイント」は、主にシステムスナップショットと呼ばれます。


1. 最も一般的なツール:Timeshift

デスクトップユーザーにとって、最も簡単で信頼できるのが Timeshift です。システムファイルの変更を監視し、OSが起動しなくなった場合でも「過去の正常な状態」に一瞬で戻せます。

作成手順

  1. インストール:
    • Ubuntu/Mint系: sudo apt install timeshift
    • Fedora系: sudo dnf install timeshift
  2. 初期設定:
    • RSYNC(一般的)または BTRFS(ファイルシステムが対応している場合)を選択します。
    • 保存先は外付けHDDや別パーティションを推奨します。
  3. スナップショットの作成: 「作成(Create)」ボタンを押すだけで、現在のシステム状態が保存されます。

復旧手順

  • OSが起動する場合: Timeshiftアプリを開き、リストから復元したい日付を選んで「復元(Restore)」をクリック。
  • OSが起動しない場合:
    1. LinuxのライブUSB(インストール時に使ったもの)から起動します。
    2. ライブ環境でTimeshiftをインストール・起動。
    3. 外付けHDDなどのバックアップ先を指定し、復元を実行します。

2. ファイルシステムレベル:Btrfs スナップショット

もしOSインストール時にファイルシステムとして Btrfs を選んでいるなら、より高度な管理が可能です。

  • 特徴: 書き込み時コピー(CoW)という技術を使うため、スナップショット作成が一瞬で終わり、容量もほとんど食いません。
  • ツール: Snapper というツールを使うのが一般的です。
  • GRUB-Btrfs: これを導入すると、PC起動時のメニュー(GRUB)に過去のスナップショットが表示され、**「壊れる前の状態をそのまま起動する」**という魔法のような使い方ができます。

3. サーバー・上級者向け:dd コマンド

ディスクを丸ごとイメージ化する方法です。

  • 作成: sudo dd if=/dev/sda of=/path/to/backup.img status=progress
  • 復旧: ifof を逆にして実行します。
  • 注意: 非常に時間がかかり、保存先の容量もディスクサイズ分必要になるため、日常的なリカバリーポイント作成には向きません。

比較表:どれを使うべき?

手法推奨ターゲットメリットデメリット
Timeshift初心者〜中級者操作が簡単、GUIがあるユーザーデータ(Home)は基本対象外
Btrfs/Snapperパフォーマンス重視高速、ストレージ効率が良い設定に少し知識が必要
Clonezilla / dd完全バックアップディスクの完全複製が可能柔軟性が低く、時間がかかる

💡 重要なアドバイス

Linuxのリカバリーツール(特にTimeshift)は、デフォルトでは「ドキュメントや写真などの個人ファイル」をバックアップ対象から除外します。これは、システムを戻した時にせっかく書いた原稿まで消えないようにするためです。

個人データのバックアップには、別途 Pika BackupDéjà Dup といったツールの併用を強くおすすめします。

Timeshift 基本コマンド

主に以下のコマンドで管理できます。

  • スナップショットの作成(手動)
    sudo timeshift --create --comments "バックアップのメモ"
  • 作成した一覧の表示
    sudo timeshift --list
  • 指定したスナップショットへの復元
    sudo timeshift --restore --snapshot '202X-XX-XX_HH-MM-SS'
  • スナップショットの削除
    sudo timeshift --delete --snapshot '202X-XX-XX_HH-MM-SS' 

主な使い方

  1. インストール
    sudo apt install timeshift (Ubuntu/Debian系)
  2. 初期設定 (ウィザード)
    初めて使う際は、GUIで起動しスナップショットタイプ(通常はRSYNC)やバックアップ先、スケジュールを設定します。
  3. 手動バックアップ
    sudo timeshift --create --comments "update_before"
  4. 復元 (ロールバック)
    一覧からIDを選択し、sudo timeshift --restoreを実行。システム再起動後、設定した状態に戻ります。 

覚えておくと便利なポイント

  • ホームフォルダは対象外: デフォルトでは /home フォルダはバックアップされないため、データ用には他のツールが必要です。
  • 自動バックアップ: 設定後は、crond/anacronにより自動でバックアップが作成されます。 

カテゴリー: 未分類 | コメントする

WireGuardのインストール(Claude)

1. WireGuardのインストール

bash

# パッケージリストの更新
sudo apt update

# WireGuardのインストール
sudo apt install wireguard -y

# インストール確認
wg --version

2. 鍵ペアの作成

WireGuardでは、サーバー用とクライアント用にそれぞれ鍵ペアが必要です。

bash

# 鍵を保存するディレクトリに移動
cd /etc/wireguard/

# サーバーの秘密鍵を生成
wg genkey | sudo tee server_private.key

# サーバーの秘密鍵から公開鍵を生成
sudo cat server_private.key | wg pubkey | sudo tee server_public.key

# クライアントの秘密鍵を生成
wg genkey | sudo tee client_private.key

# クライアントの公開鍵を生成
sudo cat client_private.key | wg pubkey | sudo tee client_public.key

# 秘密鍵のパーミッション設定(重要)
sudo chmod 600 server_private.key client_private.key

# 生成された鍵の確認
echo "=== サーバー秘密鍵 ==="
sudo cat server_private.key
echo ""
echo "=== サーバー公開鍵 ==="
sudo cat server_public.key
echo ""
echo "=== クライアント秘密鍵 ==="
sudo cat client_private.key
echo ""
echo "=== クライアント公開鍵 ==="
sudo cat client_public.key



3. サーバー設定ファイルの作成

bash

sudo nano /etc/wireguard/wg0.conf

設定内容(サーバー側):

ini

[Interface]
# サーバーのVPN内IPアドレス
Address = 10.0.0.1/24

# サーバーの秘密鍵(上で生成したもの)
PrivateKey = <サーバーの秘密鍵をここに貼り付け>

# WireGuardが使用するポート
ListenPort = 51820

# 起動時に実行するコマンド(IPフォワーディングとNAT設定)
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# クライアント1の設定
[Peer]
# クライアントの公開鍵
PublicKey = <クライアントの公開鍵をここに貼り付け>

# クライアントに割り当てるIPアドレス
AllowedIPs = 10.0.0.2/32

注意: eth0の部分は実際のネットワークインターフェース名に変更してください。

bash

# インターフェース名の確認
ip a

4. IPフォワーディングの有効化

bash

# 一時的に有効化
sudo sysctl -w net.ipv4.ip_forward=1

# 恒久的に有効化
sudo nano /etc/sysctl.conf
```

以下の行のコメントを外すか、追記:
```
net.ipv4.ip_forward=1

bash

# 設定を反映
sudo sysctl -p

5. WireGuardの起動

bash

# wg0インターフェースを起動
sudo wg-quick up wg0

# 状態確認
sudo wg show

# 自動起動の設定
sudo systemctl enable wg-quick@wg0

# サービスの状態確認
sudo systemctl status wg-quick@wg0

6. ファイアウォール設定

bash

# WireGuardポートの許可(既に設定済みなら不要)
sudo ufw allow 51820/udp

# VPN内通信の許可
sudo ufw route allow in on wg0 out on eth0

# 設定の再読み込み
sudo ufw reload

7. クライアント設定ファイルの作成

クライアント側で使用する設定ファイルを作成します:

bash

sudo nano /etc/wireguard/client.conf

設定内容(クライアント用):

ini

[Interface]
# クライアントのVPN内IPアドレス
Address = 10.0.0.2/24

# クライアントの秘密鍵
PrivateKey = <クライアントの秘密鍵をここに貼り付け>

# DNS設定(オプション)
DNS = 8.8.8.8

[Peer]
# サーバーの公開鍵
PublicKey = <サーバーの公開鍵をここに貼り付け>

# サーバーの実際のIPアドレスとポート
Endpoint = <サーバーのグローバルIP>:51820

# すべてのトラフィックをVPN経由にする場合
AllowedIPs = 0.0.0.0/0

# 接続維持のためのキープアライブ(秒)
PersistentKeepalive = 25

このクライアント設定ファイルを、実際のクライアント端末に転送して使用します。

トラブルシューティング用コマンド

bash

# WireGuardの状態確認
sudo wg show

# ログ確認
sudo journalctl -u wg-quick@wg0 -f

# インターフェース確認
ip a show wg0

# 接続テスト(クライアント接続後)
ping 10.0.0.2

複数クライアントを追加する場合

クライアントごとに鍵ペアを作成し、サーバー設定に[Peer]セクションを追加:

bash

# クライアント2の鍵生成
wg genkey | sudo tee client2_private.key
sudo cat client2_private.key | wg pubkey | sudo tee client2_public.key

サーバー設定に追加:

ini

[Peer]
PublicKey = <クライアント2の公開鍵>
AllowedIPs = 10.0.0.3/32

鍵の管理は重要なので、生成した鍵は安全に保管してください。

カテゴリー: 未分類 | コメントする

RDXドライブのマウント方法(Linux Mint)

Linux MintでRDXドライブをマウントする一般的な方法をご説明します。

RDXカートリッジは、基本的にUSB接続やSATA接続のストレージとして認識されます。


💻 RDXドライブのマウント方法(Linux Mint)

ほとんどのモダンなLinuxディストリビューション(Linux Mintを含む)では、RDXカートリッジをドライブに挿入すると、通常、デスクトップ環境(Cinnamon、MATE、XFCEなど)の機能により自動的に認識・マウントされます。

1. グラフィカルインターフェース (GUI) による自動マウント(推奨)

  1. RDXカートリッジをドライブに挿入します。
  2. 数秒待つと、システムがデバイスを認識し、デスクトップ上にアイコンが表示されるか、ファイルマネージャー(Nemoなど)のサイドバーに表示されます。
  3. アイコンをクリックするだけで、ファイルシステムにアクセスできるようになります。これが自動マウントです。

2. コマンドライン (CLI) による手動マウント

自動マウントされない場合や、サーバー環境などで操作する場合は、以下の手順で手動マウントします。

ステップ 1: デバイス名の確認

まず、RDXドライブがシステムにどのような名前で認識されているかを確認します。RDXカートリッジを挿入した後、ターミナルで以下のコマンドを実行します。

Bash

sudo fdisk -l

出力結果から、新しく追加されたデバイスを探します。通常は /dev/sdb1/dev/sdc1 のような形式で表示されます(末尾の数字はパーティション番号)。

ステップ 2: マウントポイントの作成

マウントするためのディレクトリ(マウントポイント)を作成します。

Bash

sudo mkdir /mnt/rdx_backup

(ここでは /mnt/rdx_backup をマウントポイントとしています。)

ステップ 3: マウントの実行

RDXカートリッジのファイルシステム(例:ext4NTFSFAT32など)に合わせて、以下のコマンドでマウントを実行します。

【例:ファイルシステムがext4の場合】

Bash

sudo mount -t ext4 /dev/sdb1 /mnt/rdx_backup

注意: /dev/sdb1 の部分は、ステップ1で確認した実際のデバイス名に置き換えてください。

ステップ 4: アクセスの確認

マウント後、作成したディレクトリにアクセスして、中のデータが読み取れるか確認します。

Bash

ls /mnt/rdx_backup

📤 マウントの解除 (アンマウント)

データをRDXカートリッジから安全に取り外すには、マウントを解除(アンマウント)する必要があります。アンマウントせずにカートリッジを取り外すと、データが破損する可能性があります。

1. GUI による解除

ファイルマネージャーのサイドバーまたはデスクトップのRDXドライブアイコンの隣にある**「取り出し」**(イジェクト)ボタンをクリックします。

2. CLI による解除

ターミナルで以下のコマンドを実行します。

Bash

sudo umount /mnt/rdx_backup

または、デバイス名を指定します。

Bash

sudo umount /dev/sdb1

アンマウントに成功したら、RDXドライブのイジェクトボタンを押してカートリッジを取り出してください。


RDXカートリッジはバックアップ用途で使われることが多いため、ファイルシステムがNTFSになっている可能性もあります。その場合は、マウント時に -t ntfs または -t ntfs-3g を指定してください。

もしマウント時にエラーが出る場合は、デバイス名ファイルシステムの種類が正しいか再確認してみてください。

カテゴリー: 未分類 | コメントする

Linux Mintで2台のSSDをミラーリング(RAID 1)する

主要な手順を説明します。ここでは、/dev/sda/dev/sdbがOSがインストールされていない未使用の2台のSSDであると仮定します。

Linux Mintで2台のSSDをミラーリング(RAID 1)するには、LinuxのソフトウェアRAID機能である**MDADM(Multiple Device Administration)**を使用するのが一般的です。これにより、片方のSSDが故障してもシステムを継続して使用できます。

以下に、主要な手順を説明します。ここでは、/dev/sda/dev/sdbがOSがインストールされていない未使用の2台のSSDであると仮定します。


1. MDADMのインストール

まず、ソフトウェアRAIDを管理するためのツールであるmdadmをインストールします。

Bash

sudo apt update
sudo apt install mdadm

2. パーティションの準備

ミラーリングを行う2台のSSD(例: /dev/sda/dev/sdb)に、RAID用のパーティションを作成します。

  1. パーティションツールの起動:
    Bash
    sudo fdisk /dev/sda /dev/sdbにも同様の操作を行います)
  2. パーティションの作成:
    • n (new) コマンドで新しいプライマリパーティションを作成します。
    • 全てのセクターを使用するように、デフォルト値(Enterキーを数回押す)を選択します。
  3. パーティションタイプの変更:
    • t (change partition type) コマンドを使用します。
    • コードとして fd(Linux raid autodetect)を入力します。
  4. 変更の書き込み:
    • w (write) コマンドで変更を書き込み、fdiskを終了します。

これで、/dev/sda1/dev/sdb1というRAID用のパーティションが作成されます。


3. RAIDアレイの作成

mdadmコマンドを使用して、2つのパーティションで構成されるRAID 1アレイ(ミラーリング)を作成します。

Bash

sudo mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
  • --create /dev/md0: 新しいRAIDデバイス(アレイ)として/dev/md0を作成します。
  • --level=1: RAIDレベルをミラーリング(RAID 1)に設定します。
  • --raid-devices=2: 2台のデバイスで構成します。

アレイの同期(リビルド)が自動的に開始されます。進行状況は以下のコマンドで確認できます。

Bash

cat /proc/mdstat

4. ファイルシステムの作成

RAIDアレイのデバイス(/dev/md0)上にファイルシステム(例: ext4)を作成します。

Bash

sudo mkfs.ext4 -F /dev/md0

5. マウントポイントの作成とマウント

データにアクセスするためのマウントポイントを作成し、RAIDアレイをマウントします。

Bash

sudo mkdir /mnt/raid1_data
sudo mount /dev/md0 /mnt/raid1_data

6. 自動マウント設定(fstabの編集)

システム再起動後も自動でRAIDアレイがマウントされるように、/etc/fstabに設定を追加します。

  1. UUIDの確認: RAIDアレイのUUID(Universally Unique Identifier)を確認します。
    Bash
    sudo blkid /dev/md0
  2. fstabファイルの編集: エディタで/etc/fstabを開き、以下の形式でエントリを追加します(UUIDの値は上記で取得したものに置き換えてください)。
    Bash# /etc/fstab に追記する形式の例 UUID="取得したUUID" /mnt/raid1_data ext4 defaults 0 0
  3. 設定の確認: 以下のコマンドで、fstabの設定が正しいかテストします。エラーが出なければ成功です。
    Bash
    sudo umount /mnt/raid1_data sudo mount -a

7. MDADM設定ファイルの保存

RAIDアレイの構成情報を設定ファイルに保存することで、システムの再起動時にRAIDデバイスが自動的に認識・組み立てられるようになります。

Bash

sudo mdadm --detail --scan | sudo tee -a /etc/mdadm/mdadm.conf

最後に、システムがこの新しい設定を読み込むように、RAMディスクを更新します。

Bash

sudo update-initramfs -u

カテゴリー: 未分類 | コメントする