Linuxでのデバイスの自動マウントへのアプローチは変わり続けており、グーグルは現代のsystemdベースのボックスにさまざまな程度の適用性を持つかなりの数のソリューションを返します。
次のアプローチが存在するようです:
/etc/fstab
_を変更して、UUID /ラベル/デバイスごとにドライブごとのマウントを追加します。udev
ルール(明らかに「生のルール」は既存のsystemdポリシーと競合する可能性があります)thunar
+ _thunar-volman
_パッケージを介したXFCE、または_gnome-volume-manager
_パッケージを使用したGnomeのnautilus
自動マウント(どうやら依存しているようです- disks )。選択肢は多すぎる可能性があり、現在推奨されているアプローチがどれであるかは明確ではありません。さらに、異なる自動マウントサブシステムが競合し、パーティションが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-として自動的に追加しますマウントポイントを書き込みます。
_/etc/fstab
_のエントリは、systemdベースのシステムでも引き続き有効です。
代わりに.mountユニットを使用でき、fstabのエントリと同等と見なされます。
起動時または永続的にマウントが必要ない場合は、.automountユニットを使用できます。 systemdは、ユニットファイルで指定されたアイドル期間が経過すると、マウントを解除します。
詳細については、systemd.mount(5)
およびsystemd.automount(5)
のマニュアルページを参照してください。
現在「公式に」サポートされているアプローチがどれであるかは明確ではありません。
誰が公式にサポートしていますか?たとえば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
マップタイプ(および接続されているすべてのディスクを列挙するスクリプト)を使用するとうまくいきます。