web-dev-qa-db-ja.com

ヘッドレスsystemd LinuxボックスでのUSBドライブの自動マウント

Linuxでのデバイスの自動マウントへのアプローチは変わり続けており、グーグルは現代のsystemdベースのボックスにさまざまな程度の適用性を持つかなりの数のソリューションを返します。

次のアプローチが存在するようです：

  1. _/etc/fstab_を変更して、UUID /ラベル/デバイスごとにドライブごとのマウントを追加します。
  2. udevルール（明らかに「生のルール」は既存のsystemdポリシーと競合する可能性があります）
  3. disks2 systemdサービスとして、または diskie 経由で実行
  4. devil
  5. sbmount
  6. デスクトップ環境によって提供される自動マウント、つまりthunar + _thunar-volman_パッケージを介したXFCE、または_gnome-volume-manager_パッケージを使用したGnomeのnautilus自動マウント（どうやら依存しているようです- disks ）。
  7. autofs カーネル自動マウンター
  8. systemd 自動マウント、使用例： automount-usb

選択肢は多すぎる可能性があり、現在推奨されているアプローチがどれであるかは明確ではありません。さらに、異なる自動マウントサブシステムが競合し、パーティションが1つのツールによってマウントされ、数秒で別のツールによって自動的にマウント解除される場合があります。

デスクトップ環境のシステムの場合、ほとんどのシステムがUSBマウントを自動的に処理するので簡単です。そのため、設定で自動マウントオプションを有効にする以外に、特別な操作は必要ありません。

主にテキストモードで動作するヘッドレスシステムの現在のアプローチは何でしょうか？

更新

私が見つけたすべてのオプションをいじった後、私は_/lib/systemd/system/systemd-udevd.service_を編集して_MountFlags=slave_をに変更した後、 usbmount to（ほぼ）just workこの問題 で説明されている_MountFlags=shared_。 UUIDまたはラベルを構成ファイルに手動で追加する必要はありません。欠点は、完全ではない_/media/usbN_の下にマウントポイントを作成することです。そのため、私は _automount-usb_ に切り替えました。これは驚くほど簡単にセットアップできました（_configure.sh_スクリプト）および_/media/<device>_<disk_label>_などのマウントフォルダーを作成します。例： _/media/sda2_mylabel_のように。

関連リンク：

自動Sambaマウント： automount-usbのフォーク もあり、接続されたUSBドライブをsamba read-として自動的に追加しますマウントポイントを書き込みます。

linuxsystemdfstabudevautomount
12
ccpizza

_/etc/fstab_のエントリは、systemdベースのシステムでも引き続き有効です。

代わりに.mountユニットを使用でき、fstabのエントリと同等と見なされます。

起動時または永続的にマウントが必要ない場合は、.automountユニットを使用できます。 systemdは、ユニットファイルで指定されたアイドル期間が経過すると、マウントを解除します。

詳細については、systemd.mount(5)およびsystemd.automount(5)のマニュアルページを参照してください。

3
Ignacio Vazquez-Abrams

現在「公式に」サポートされているアプローチがどれであるかは明確ではありません。

誰が公式にサポートしていますか？たとえばGNOMEには、udiskに基づく自動マウント機能が含まれています。GNOME自体が正式にサポートしていることは確かです。

1つ目は/etc/fstabにエントリを追加できるので、2つ目（つまり、USBストレージデバイス）に興味があります。

そのための「標準的な方法」はありません。せいぜい、既存のシステムの大部分はudisks2に自動化を追加することに落ち着いています。それ自体では、udisksは何も自動マウントしません–しかし、それは多くのグラフィカルデスクトップ環境で使用される「バックエンド」です（少なくともGNOMEとXfceの両方が使用します。私はKDEとEnlightenmentについては80％しか確信していません）。

（したがって、オプション3は「udisks2 + udiskieによる自動マウント」となり、オプション4は「udisks2 +デスクトップ環境による自動マウント」となります。）

Udevルールに関して：ファイルシステムのマウントであろうとサービスの開始であろうと、簡単な答えは（それをしないでください）（さまざまな理由で）。しかし、長い答えは、「直接実行しないでください。しかし、initに実行するように依頼することができます」。そのため、udevルールからsystemd-mountを実行することは恐ろしいことではありません。それは、.mountユニットと同じように、マウント要求をinitに渡すだけです...

ただし、これによりsystemdのバグ/警告/誤機能がトリガーされることが予想されます。udevがデバイスの準備が完了した後にルールを処理しただけなので、ディスクが自動的にアンマウントされる可能性がありますデバイスがまだ存在しないと考えているためです。

代わりに、udevilはルールを介して何も実行せず、udevによって発行された「デバイス準備」イベントにのみ反応するため、より適切に機能します。

fstabエントリは、静的デバイス向けです。ただし、デバイスの物理パス（PCIスロット3、USBポート1、パーティション1など）に対応する/dev/disk/by-path/...を使用して、雑多なUSBスティックを悪用することができます。同じUSBポートに接続されているすべてのディスクに一致するfstabエントリを書き込みます。

Autofskernelオートマウンターは、udiskと同様に、ユーザースペースによってさまざまな自動マウントを実装できるバックエンドにすぎません。autofsマウントが設定されている場合、マウントへのアクセスはすべて対応するデーモンに報告されます。最も一般的な実装は、従来の（マップベースの）autofsであり、最近ではsystemdが.automountユニットで実装されています。

そのため、「動的」USBデバイスロジックはユーザースペースに実装する必要があり、どちらにしても、単にudiskを使用するよりも作業が多くなります。

  • 単純なsystemdを使用する場合の唯一の選択肢は、上記のfstab "by-path"ハックの上に構築することです。目的のUSBポートのfstabエントリを作成したら、それをx-systemd.automount,x-systemd.idle-timeout=300でマークして、autofsオートマウンタを使用できます。 （または、もちろん、同じ結果を得るためにスタンドアロンの.mount + .automountユニットを作成します。）

    すべてのポートのすべてのUSBディスクの自動マウントを動的に生成したい場合、systemdはサードパーティのスクリプトなしではそれを行うことができません。

  • autofsdがあなたのしたいことができるかどうかはわかりませんが、（ユーザーのホームディレクトリ用の）some種類の動的マップをサポートしていることを覚えています。おそらく、programマップタイプ（および接続されているすべてのディスクを列挙するスクリプト）を使用するとうまくいきます。

3
user1686