當前位置：首頁 > 运维知识 > linux >内容正文

linux

U盘的热拔插/自动挂载跟linux2.6 kernel、 udev、 hal、 dbus 、gnome-mount 、thunar的关系...

發布時間：2025/4/5 linux 18 豆豆

生活随笔收集整理的這篇文章主要介紹了 U盘的热拔插/自动挂载跟linux2.6 kernel、 udev、 hal、 dbus 、gnome-mount 、thunar的关系... 小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

U盤的熱拔插/自動掛載跟linux2.6 kernel、 udev、 hal、 dbus 、gnome-mount 、thunar的關系

博客分類：

System About

Linux配置管理網絡應用應用服務器腳本

將網上的資料整理了下。

簡單的說就是：

插入新設備后，
kernel 發現設備變化反應到 sysfs 上并通知 udev，
udev 把硬件相關內容送給 hal，
hal 過濾、處理之后發送信息到 dbus 總線，
thunar 從 dbus 收到信息后在 xfdesktop 桌面顯示新圖標，
用戶點擊桌面圖標后用 pmount 把設備掛上，打開掛載目錄。

具體的說就是：

?這是當時的情況，如今小有變化，gnome缺省使用 gnome-mount 而不是 pmount 了，gnome-mount 使用 gconf-editor 配置，而不是 pmount 的策略，其余機制沒啥變化。

(原發于BBS Linux 版面)

關鍵字: sysfs, hotplug, udev, hal, gnome-volume-manager, pmount

關于自動掛載可移動存儲介質，譬如 u 盤啥的一直是很多人想要實現的東東，缺省的，對于高版本內核的系統，gnome 里面是可以這樣的，這個原因恐怕很多人還不是很清楚，那天看了兩眼，來解釋一下，有啥不對的地方，還請指出
?
自動掛載磁盤分區的操作從底層來說，是要內核支持的，2.6 內核的sysfs 虛擬文件系統就提供了這一支持，這個文件系統 (/sys/) 通常用于反應系統硬件信息，總線上的設備變化、網絡設備的變化等事件在這里都能反應出來，這個文件系統的變化配合上內核的 hotplug 機制就可以掌握硬件改動相關的信息了。
?
說到內核的 hotplug 機制，簡單地說就是在硬件發生變化的時候去通知某一用戶態程序，缺省是 /sbin/hotplug，不過現在它已經被 udev 取代了，收到信息之后，udev 會根據 sysfs 的變化調用一些腳本來處理這個事件，這里的處理是指某個用戶空間的動作，而不是加載驅動，加載驅動是內核自己的事情，在 udev 反應過來之前就完成了。
?
下面輪到我們著名的硬件抽象層 (HAL) 程序的了，這個程序有一個派駐到 udev 的腳本，把硬件改動信息部分地送到自己這里來處理，根據它的不同設置，有可能會提示某些東東來掛載磁盤阿、檢測新進來的數碼相機阿……
?
那 hal 怎么發出通知呢? 這是利用一個新興的系統內用戶空間消息總線系統 -- dbus 來完成的，hal 會通過 dbus 上的一條消息總線把新加入的塊設備和相關的掛載提示信息，比如加載選項 sync, iocharset 之類的信息發送到總線上來，只等待一個終結者來接受并處理這些信息了。
?
這個終結者對于 gnome 來說就是 gnome-volume-manager (名字太長了，下面簡稱 gvm)，它從 dbus 上探聽消息，當發現有設備掛載提示的時候就會嘗試把設備掛載上來。缺省的，還會打開一個 nautilus 瀏覽窗口來瀏覽新掛載上的分區的內容。
?
嗯，最后一個問題就是怎么掛了，眾所周知，如果塊設備在 /etc/fstab 里沒有描述存在的話，掛載就比較麻煩:

本來如果有 fstab 中的 user 屬性的話，普通用戶可以掛載，但? 現在沒有，普通用戶沒法掛
如果 sudo 授權的話，用戶可能獲得掛載其他分區的過大權限，危及系統安全。

pmount 就是這個工具鏈上的最后一環，它可以代表用戶 (運行 gvm 的用戶) 來掛載一個屬于他的可移動存儲設備，即使 fstab 里沒有這個設備存在，缺省的掛載位置是 /media/ 下，和塊設備同名，比如 /dev/sda1 掛載到 /media/sda1/ 目錄。
?
嗯，綜上，設備的自動掛載就完成了，呵呵，希望一大堆的關鍵詞沒把大家搞暈，回顧一下: kernel 發現設備變化反應到 sysfs 上并通過 hotplug 機制通知udev， udev 把硬件相關內容送給 hal，hal 過濾、處理之后發送信息到 dbus 上，在 dbus 上等候的 gvm 收到消息后用 pmount 把設備掛上，這樣，設備的自動掛載就完成了 :)

從具體實現層面來說就是：

App
↑? ?? ?? ?? ???App等候設備處理信息并掛載設備
D-Bus
↑? ?? ?? ?? ???過濾處理內容后送給D-Bus
HAL? ?? ?? ?? ? 它是一個位于操作系統和驅動程序之上，運行在用戶空間中的服務程序
↑? ?? ?? ?? ???把硬件相關內容送到HAL
udev
↑? ?? ?? ?? ???kernel2.6發現設備變化反映到sysfs, 并通過hotplug機制通知udev
Linux Kernel2.6 自動調用驅動模塊

1. 自動掛載磁盤分區的操作從底層來說，是要內核支持的，2.6 內核的sysfs 虛擬文件系統就提供了這一支持，這個文件系統 (/sys/) 通常用于反應系統硬件信息，總線上的設備變化、網絡設備的變化等事件在這里都能反應出來，這個文件系統的變化配合上內核的 hotplug 機制就可以掌握硬件改動相關的信息.
說到內核的 hotplug 機制，簡單地說就是在硬件發生變化的時候去通知某一用戶態程序，缺省是 /sbin/hotplug，不過現在它已經被 udev 取代了，收到信息之后，udev 會根據 sysfs 的變化調用一些腳本來處理這個事件，這里的處理是指某個用戶空間的動作，而不是加載驅動，加載驅動是內核自己的事情，在 udev 反應過來之前就完成了.

2. 下面輪到我們著名的硬件抽象層(HAL)
HAL是Hardware Abstraction Layer的首字母縮寫。我最早是在Winnt 3.5的幫助中知道這個名詞的，對幫助文檔中的說法我比較認同，所以一直對它抱有好感。不過Windows下的HAL和Linux下的HAL兩者所指并非相同之物：
Windows 下的HAL ：位于操作系統的最底層，直接操作物理硬件，隔離與硬件相關的信息，為上層的操作系統和設備驅動程序提供一個統一的接口，起到對硬件的抽象作用。有了HAL，編寫驅動程序就容易多了，因為HAL的接口不但使用簡單，而且具有更好的可移植性（沒用過）。
Linux 下的HAL ：至于對硬件的抽象，Linux內核早就有類似機制，只不過沒有專門的名稱罷了。而Linux的HAL指的并非這個，它不是位于操作系統的最底層，直接操作硬件，相反，它位于操作系統和驅動程序之上，是一個運行在用戶空間中服務程序。
我們知道，Linux和所有的Unix一樣，習慣用文件來抽象設備，任何設備都是一個文件，比如/dev/mouse是鼠標的設備文件。這種方法看起來不錯，每個設備都有統一的形式，但使用并不那么容易，設備文件名沒有什么規范，從簡單的一個文件名，你無法得知它是什么設備，具有有什么特性。
結果形成這樣的尷尬：有了設備和設備驅動程序，卻不知道如何使用它。這些亂七八糟的設備文件，讓設備的管理和應用程序的開發都變得很麻煩，所以有必要提供一個硬件抽象層，來為上層應用程序提供一個統一的接口，Linux的HAL就這樣應運而生了。
但HAL并不提供諸如拍照和刻錄等之類的功能，相反它只是告訴應用程序，系統中有哪些設備可用，以及這些設備的類型、特性和能力等。主要說來，它提供以下幾項功能：
1.? ?? ?? ?獲取指定類型的設備列表。
2.? ?? ?? ?獲取/更改設備的屬性值。
3.? ?? ?? ?獲取設備具有的能力描述。
4.? ?? ?? ?設備插入/拔除時，通知相關應用程序。
5.? ?? ?? ?設備屬性或能力變化時，通知相關應用程序。
udev創建dev下的文件結點，加載驅動程序，讓設備處于可用狀態。而HAL則告訴應用程序，現在有哪些設備可用，這些設備的類型、特性和能力，讓應用程序知道如何使用它們。
設備的屬性管理是HAL最重要任務之一，有的設備屬性來源于實際的硬件，有的來源于設備信息文件(/usr/share/hal/fdi/)，有的來源其它配置信息(如/usr/share/hwdata/)。設備屬性的都有標準的定義，這些屬性定義是HAL的SPEC的主要內容之一，可以參考
http://people.freedesktop.org/~david/hal-spec/hal-spec.html

3.??udev & HAL
udev通過NetLink注冊內核的設備事件，當有設備插入/拔除時，udev就會收到通知，它會從事件中所帶參數和sysfs中的信息，加載適當的驅動程序，創建dev下的結點，讓設備處于可用的狀態。
.? ?? ?? ?udev只是一個框架，它的行為完全受它的規則所控制，這些規則存放在目錄/etc/udev/rules.d/中，其中90-hal.rules是用來讓udev把設備插入/拔除的事件通過socket socket:/org/freedesktop/hal/udev_event轉發給HAL的。
.? ?? ?? ?HAL掛在socket:/org/freedesktop/hal/udev_event上等待事件，有事件發生時就調用函數 hald_udev_data處理，它先從事件中取出主要參數，創建一個hotplug_event對象，把它放入事件隊列中，然后調用 hotplug_event_process_queue處理事件。
.? ?? ?? ?函數hotplug_event_begin負責具體事件的處理，它把全部事件分為四類，并分別處理 hotplug_event_begin_sysfs處理普通設備事件，hotplug_event_begin_acpi處理ACPI事件，hotplug_event_begin_apm處理APM事件，hotplug_event_begin_pmu處理PMU事件。要注意的是，后三者的事件源并非源于udev，而是在device_reprobe時觸發的 (osspec_device_reprobe/hotplug_reprobe_tree /hotplug_reprobe_generate_add_events/acpi_generate_add_hotplug_event)。
.? ?? ?? ?函數hotplug_event_begin_sysfs中，如果是插入設備，則創建一個設備對象，設置設備的屬性，調用相關callouts，然后放入設備列表中，并觸發signal讓dbus通知相關應用程序。如果是拔除設備，則調用相關callouts，然后從設備列表中刪除，并觸發signal 讓dbus通知相關應用程序。
.? ?? ?? ?應用程序可以主動調用HAL提供的DBUS接口函數，這些函數在libhal.h中有定義。應用程序也可以注冊HAL的signal，當設備變化時，HAL通過DBUS上報事件給應用程序。
.? ?? ?? ?callout是HAL一種擴展方式，它在設備插入/拔除時執行。可以在設備信息文件中(/usr/share/hal目錄)指定。
.? ?? ?? ?addon也是HAL一種擴展方式，它與callout的不同之處在于addon往往是事件的觸發者，而不是事件的消費者。HAL的事件源主要源于 udev，而udev源于kernel的hotplug，然而有的設備如電源設備、磁盤設備和特殊按鍵等，它們并不產生hotplug事件。HAL就得不到通知，怎么辦呢，addon就是用于支持新事件源的擴展方式。比如addon-acpi從/proc/acpi/event或者/var/run /acpid.socket收到事件，然后轉發成HAL事件。addon-storage檢測光盤或磁盤的狀態，并設置設備的屬性。addon- keyboard檢測一些特殊按鍵，并觸發相應事件。
access-check/ci-tracker/ck-tracker負責權限的檢查，里面提到的PolicyKit/ConsoleKit不是太熟悉，有時間再看看。
簡單的說，HAL就是一個設備數據庫，它管理當前系統中所有的設備，你可以以多種靈活的方式去查詢這些設備，可以獲取指定設備的特性，可以注冊設備變化事件。

4. 那 hal 怎么發出通知呢? 這是利用一個新興的系統內用戶空間消息總線系統 -- dbus 來完成的，hal 會通過 dbus 上的一條消息總線把新加入的塊設備和相關的掛載提示信息，比如加載選項 sync, iocharset 之類的信息發送到總線上來，只等待一個終結者來接受并處理這些信息了.

5. 這個終結者對于 gnome 來說就是 gnome-volume-manager (名字太長了，下面簡稱 gvm)，它從 dbus 上探聽消息，當發現有設備掛載提示的時候就會嘗試把設備掛載上來。缺省的，還會打開一個 nautilus 瀏覽窗口來瀏覽新掛載上的分區的內容。
嗯，最后一個問題就是怎么掛了，眾所周知，如果塊設備在 /etc/fstab 里沒有描述存在的話，掛載就比較麻煩:

本來如果有 fstab 中的 user 屬性的話，普通用戶可以掛載，但??現在沒有，普通用戶沒法掛
如果 sudo 授權的話，用戶可能獲得掛載其他分區的過大權限，危及系統安全。

pmount 就是這個工具鏈上的最后一環，它可以代表用戶 (運行 gvm 的用戶) 來掛載一個屬于他的可移動存儲設備，即使 fstab 里沒有這個設備存在，缺省的掛載位置是 /media/ 下，和塊設備同名，比如 /dev/sda1 掛載到 /media/sda1/ 目錄。

嗯，綜上，設備的自動掛載就完成了，呵呵，希望一大堆的關鍵詞沒把大家搞暈，回顧一下: kernel 發現設備變化反應到 sysfs 上并通過 hotplug 機制通知udev， udev 把硬件相關內容送給 hal，hal 過濾、處理之后發送信息到 dbus 上，在 dbus 上等候的 gvm 收到消息后用 pmount 把設備掛上，這樣，設備的自動掛載就完成.
PS:HAL的相關文件:
首先是硬件信息文件fdi的路徑會有：
/usr/share/hal/fdi 通常是由系統程序安裝包提供的文件。
/etc/hal/fdi 這里是用戶或者管理員修改fdi的位置。
這兩個路徑下各自存在information policy preprobe等3個目錄，用來存放不同用途的fdi文件。后面再解釋。

其次是HAL的一些Callout和Addon，他們位于 /usr/lib/hal/scripts 及 /usr/lib/hal/ 下面

再有一些與HAL本身相關的配置文件等：
/etc/init.d/hal hal的啟動腳本
/etc/udev/rules.d/95-hal.rules??HAL在UDEV中的規則
/etc/dbus-1/system.d/hal.conf??HAL的一些常用的Interface在DBUS中的權限設置。

相關程序
/usr/bin/lshal
/usr/bin/hal-device
/usr/bin/hal-get-property
/usr/bin/hal-set-property
/usr/bin/hal-find-by-capability
/usr/bin/hal-find-by-property
/usr/bin/hal-disable-polling
/usr/bin/hal-is-caller-locked-out
/usr/bin/hal-lock
/usr/sbin
/usr/sbin/hald

參考：http://blog.csdn.net/colorant/archive/2008/07/04/2611559.aspx

另外，關于HAL熱拔插的文檔：

http://wiki.archlinux.org/index.php/HAL_%28%E7%AE%80%E4%BD%93%E4%B8%AD%E6%96%87%29

[hide ]

1 介紹
- 1.1 關于熱插拔
- 1.2 關于卷掛載點
2 安裝和配置HAL
- 2.1 一、安裝
- 2.2 二、配置
  - 2.2.1 權限策略
  - 2.2.2 設備具體策略
    - 2.2.2.1 NTFS寫權限
      - 2.2.2.1.1 mount.ntfs鏈接
    - 2.2.2.2 語言問題
    - 2.2.2.3 對可移動設備開啟noatime掛載選項
    - 2.2.2.4 取消登錄時自動掛載
  - 2.2.3 重啟或啟動HAL
3 疑難解答
- 3.1 掛載失敗
  - 3.1.1 IsCallerPrivileged failed
  - 3.1.2 無法從Gnome掛在內部驅動器
  - 3.1.3 權限被拒絕
    - 3.1.3.1 仍然不行
    - 3.1.3.2 其它修復方式
    - 3.1.3.3 另一種修復方式
- 3.2 自動掛載失敗
  - 3.2.1 插入的CD/DVD不能被hal識別
- 3.3 USB閃盤／驅動器沒有被正確地自動掛載
- 3.4 移除U盤導致不正常卸載
4 外部鏈接

介紹

硬件抽象層（Hardware Abstraction Layer，HAL）是一個守護進程，它允許桌面應用程序即時讀取硬件信息，這樣，無論接口或設備類型如何，應用程序都能找到并使用它們。用這種方法，圖形界面以一種無縫、一致的模式為用戶提供所有的資源。

關于熱插拔

熱插拔會發生很多事情，HAL只是其中一部分。當一個新設備被加入，例如插入一個U盤，會發生以下事情（粗略的）：

內核獲知此新設備并將其注冊到/sys .
Udev 創建一個設備節點（如/dev/sdb1 ），然后加載必需的驅動/模塊。
HAL守護進程接到D-Bus 的通知，將設備及其相關信息加入到數據庫。
HAL通過D-Bus將新設備的加入這件事廣播給所有訂閱程序，如Thunar對此將在快捷邊欄上顯示圖標，或者Metacity/Nautilus對此會在桌面添加一個圖標。
可能還有其它監聽程序，如卷管理器或者 AutoFS ，它被配置為自動創建掛載點并掛載某些類型的驅動器, 當iPod插入時啟動Rhythmbox ，等等。

HAL并不檢測硬件(內核)、管理設備或驅動(udev)或者自動掛載驅動器(卷管理器)。作為一個硬件抽象層（h ardware a bstraction l ayer），它的角色更象是一個通訊中心，為應用程序提供簡潔的設備接口。熱插拔設備無法正常檢測、使用或掛載等問題要仔細研究調查，要知道它涉及了方方面面。(參看'疑難排解')。

關于卷掛載點

HAL在/media/某文件夾下掛載卷。對于某文件夾的命名，它使用卷的標簽(label) ，如果卷沒有標簽，它會使用卷的類型(type) (如果目錄已存在則尾隨數字），例如/media/disk ,、/media/disk-1 ...

要給分區命名一個標簽，可以使用GParted (extra倉庫中) ，或者KDE下的PartitionManager (AUR 中)。

同時請留意以下掛載設備時常見的三個問題：

目錄/media/label_of_your_volume 必須不存在，它會由HAL自動創建和銷毀。
設備必須沒有寫在fstab中，否則HAL將拒絕加載它。
你必須有權加載設備，詳情參見 Permission Denied 。

如果由于某些原因你無法給分區命名標簽(label)，可以設置個偽標簽給HAL。你需要先準備好以下兩項：

$device_uuid , 設備的uuid(ls -l /dev/disk/by-uuid/
$fake_label , 你選擇的偽標簽

將以下內容寫入/etc/hal/fdi/policy/20-$device_name .fdi ，別忘了把$device_uuid 和$device_name 替換為真正的內容。

File: /etc/hal/fdi/policy/20-$device_name.fdi <?xml version="1.0" encoding="UTF-8"?><deviceinfo version="0.2"><device><match key="volume.uuid" string="$device_uuid "><merge key="volume.label" type="string">$device_name </merge></match></device></deviceinfo>

安裝和配置HAL

一、安裝

HAL要求守護進程dbus的存在，因此我們需要把它們兩個都裝上：

# pacman -S dbus hal

然后以root身份編輯/rc.conf 文件，把hal 添加到DAEMONS列，例如：

DAEMONS=(syslog-ng dbus halnetwork netfs ...)

現在DBUS和HAL守護進程就會在啟動時加載了。由于如果dbus沒有運行的話hal會自動加載它，這會導致關機時無法卸載，因此為免麻煩，DAEMONS列表里dbus應該排在hal前面。

注意：有些用戶報告說這樣設置會出問題。如果你發生問題的話，可以嘗試先加載hal 然后才dbus 。

或者你也可以手動啟動hal。以root身份輸入以下命令：

# /etc/rc.d/hal start

為了讓dbus和hal正常地發揮作用，本地用戶必須是optical ，storage 組的成員。要實現這一點，打開終端，以root身份輸入以下命令：

# gpasswd -a usernameoptical # gpasswd -a usernamestorage

把“username“換成你的用戶名（比如johndoe）

你必須完全注銷并重新登錄，這些用戶組設置才會生效。

二、配置

權限策略

程序通過一個D-Bus接口同HAL進行交流。在這里定義很多接口，每個相關含有不同方式：存儲設備接口，例如，有'彈出設備'和'關閉光驅'。為了能夠'掛載'USB盤上的一個分區，你必須獲取相關的D-bus接口（這個地方說的是'卷宗'volume ）。

/etc/dbus-1/system.d/hal.conf這個配置文件包含了HAL-specific具體的特權。也就是哪些用戶有權力訪問哪些接口。/etc/dbus-1/system.conf這個文件內容定義了用在D-bus接口上的例外的策略。簡單來說，你需要查看你給用戶訪問DBUS/HAL接口的權力有哪些，因為D-Bus默認是不會給你任何全權限的。

默認的hal.conf包含了一些允許和拒絕訪問的策略，amongst them this default (the later of two defaults and therefore seemingly the deciding one):

File: /etc/dbus-1/system.d/hal.conf <policy context="default"><deny send_interface="org.freedesktop.Hal.Device.SystemPowerManagement"/><deny send_interface="org.freedesktop.Hal.Device.VideoAdapterPM"/><deny send_interface="org.freedesktop.Hal.Device.LaptopPanel"/><deny send_interface="org.freedesktop.Hal.Device.Volume"/><deny send_interface="org.freedesktop.Hal.Device.Volume.Crypto"/></policy>

簡單的說，默認設置是用戶被拒絕訪問如掛載或者卸載卷的接口。下面的策略就是來讓'power'和'storage'組用戶訪問特定設備的：

File: /etc/dbus-1/system.d/hal.conf <policy group="power"><allow send_interface="org.freedesktop.Hal.Device.SystemPowerManagement"/><allow send_interface="org.freedesktop.Hal.Device.LaptopPanel"/></policy><policy group="storage"><allow send_interface="org.freedesktop.Hal.Device.Volume"/><allow send_interface="org.freedesktop.Hal.Device.Volume.Crypto"/></policy>

這就是為什么你需要添加你的用戶到這些組的原因（見'初始設置'），這樣也可以減少自己設置配置文件的數量。

設備具體策略

NTFS寫權限

如果你想在掛載NTFS文件系統時獲得寫入支持，你必須安裝ntfs-3g 然后添加如下內容到 /usr/share/hal/fdi/policy/10osvendor/20-ntfs-config-write-policy.fdi (不存在就新建)

<?xml version="1.0" encoding="UTF-8"?> <deviceinfo version="0.2"><device><match key="volume.fstype" string="ntfs"><match key="@block.storage_device:storage.hotpluggable" bool="true"><merge key="volume.fstype" type="string">ntfs-3g</merge><merge key="volume.policy.mount_filesystem" type="string">ntfs-3g</merge><append key="volume.mount.valid_options" type="strlist">locale=</append></match></match></device> </deviceinfo>

注意：GNOME自2.20版起使用ntfs-3g掛載ntfs分區，因此你不再需要添加這些了。

mount.ntfs鏈接

對hal>=0.5.10，上面的策略可能不起作用。這里有一個臨時的辦法可以強制hal使用ntfs-3g而不是標準的ntfs驅動。請注意，這個辦法將會使你的系統中所有ntfs驅動器都使用ntfs-3g的驅動！作為root創建一個從mount.ntfs到ntfs-3g的軟鏈接：

# ln -s /sbin/mount.ntfs-3g /sbin/mount.ntfs

這一做法可能引起的問題：

帶有“-i“參數的mount命令會失效
可能與內核中的ntfs模塊發生沖突

語言問題

Note: 這個問題在ntfs-3g 2009.1.1和更新的版本里不會發生。

如果你的文件名包含非拉丁字符的話可能會有問題。這是掛載程序沒有正確地解析這些策略和語言項。以下是解決方案：

移除軟鏈接： rm /sbin/mount.ntfs-3g
把它替換成包含如下內容的bash腳本：

File: /sbin/mount.ntfs-3g #!/bin/bash/bin/ntfs-3g $1 "$2" -o locale=en_US.UTF-8 ,$4 # put your own locale here

使它可執行：chmod +x /sbin/mount.ntfs-3g
添加到 /etc/pacman.conf

File: /etc/pacman.conf ...NoUpgrade = sbin/mount.ntfs-3g ...

對可移動設備開啟noatime掛載選項

這可以加速文件操作，同時降低閃存設備如U盤、SD卡的損耗.

File: /etc/hal/fdi/policy/20-noatime-removable.fdi <device> <match key="block.is_volume" bool="true"><match key="@block.storage_device:storage.hotpluggable" bool="true"><merge key="volume.policy.mount_option.noatime" type="bool">true</merge></match><match key="@block.storage_device:storage.removable" bool="true"><merge key="volume.policy.mount_option.noatime" type="bool">true</merge></match></match> </device>

取消登錄時自動掛載

如果要登錄時取消自動掛載ntfs或者其它文件系統：

File: /etc/hal/fdi/policy/20-disable-automount.fdi <device><match key="storage.hotpluggable" bool="false"><match key="storage.removable" bool="false"><merge key="storage.automount_enabled_hint" type="bool">false</merge></match></match></device>

重啟或啟動HAL

要修改生效，需要重啟hal

# /etc/rc.d/hal restart

疑難解答

Note: 所有修改需要用/etc/rc.d/hal restart 重啟HAL后才生效！

掛載失敗

IsCallerPrivileged failed

如果你在沒有使用KDM或者GDM的情況下，出現"IsCallerPriviliged failed"提示消息，可以試一下用ck-launch-session (包含在consolekit 軟件包)來啟動你的DE/WM。

例如對于startx/KDE，~/.xinitrc 中原來的是：

exec startkde

那么新的寫法就是：

exec ck-launch-session startkde

無法從Gnome掛在內部驅動器

如果你無法從Gnome掛在內部驅動器（在Nautilus中點擊它們），可以打開System -> Preferences下的Authorizations，然后查看org.freedesktop.hal.storage，選擇Mount file systems from internal drives，點擊Edit，然后將Active Console改為Yes。

權限被拒絕

注意: 解決此問題的另一種方法可見I won the struggle against hal and policykit 。它也有助于糾正掉電和系統關機的問題。

如果你是剛升級到的hal-0.5.11-7，突然出現用非root用戶掛載設備發生以下這些錯誤導致失敗：

"PermissionDeniedByPolicy mount-removable no"
"PermissionDeniedByPolicy mount-removable-extra-options no"
"org.freedesktop.hal.storage.mount-removable no <-- (action, result)"
"org.freedesktop.hal.storage.mount-removable-extra-options no <-- (action, result)"

可以編輯/etc/PolicyKit/PolicyKit.conf 并粘帖以下內容到<config>段以解決這些問題：

File: /etc/PolicyKit/PolicyKit.conf <match user="$user "> <match action="org.freedesktop.hal.storage.*"><return result="yes"/></match><match action="hal-storage-mount-fixed-extra-options"><return result="yes" /></match><match action="hal-storage-mount-removable-extra-options"><return result="yes" /></match> </match>

重啟dbus和hal。如果你使用KDE的話還要一同重啟KDE（否則設備通知器會出問題并停止響應）。作為這類問題的Hotfix這來自于 Gullible Jones的"So long, Arch" 一貼，也許它不是最佳的修復方案（特別是對于很多用戶的計算機），不過它的確能行得通。

Note: 請確認你象<match user="myuser"> and NOT like <match user="$myuser"> 這樣輸入你的用戶名。

仍然不行

如果以上方法仍然不行，可以嘗試以下“

注意：這將允許一切！

其它修復方式

如果你從.xinitrc中啟動窗口管理器，請看"IsCallerPrivileged failed"中的第2項。

另一種修復方式

File: /etc/PolicyKit/PolicyKit.conf <config version="0.1"><define_admin_auth user="USER"/> </config>

其中USER是你的用戶名。

File: ~.xinitrc exec ck-launch-session window-manager

這將給予用戶特定的管理員權限,它和hal和root用戶的hal管理權限一樣。

自動掛載失敗

插入的CD/DVD不能被hal識別

如果插入的CD/DVD沒有被hal識別（桌面上沒有圖標），檢查/etc/fstab ，移除可選驅動器的相關行。

如果不行，這可能是因為你的設備沒有被HAl標記為自動掛載。我也不知道這是為什么，不過你可以編輯包含以下內容的/etc/hal/fdi/information/media-check-disable-storage_model_$YOUR_DEVICE .fdi ：

File: /etc/hal/fdi/information/media-check-disable-storage_model_$YOUR_DEVICE .fdi <deviceinfo version="0.2"><device><match key="info.udi" string="/org/freedesktop/Hal/devices/storage_model_DV$<merge key="storage.media_check_enabled" type="bool">false</merge></match></device></deviceinfo>

如果key設為了false，那么你只需要把它改為true就行了。

USB閃盤／驅動器沒有被正確地自動掛載

這段內容來自這個論壇 .

如果你在自動掛載USB閃盤／驅動器時遭遇了麻煩，自動掛載CD、DVD卻毫無問題，而且如果你可以手動掛載那些遇到麻煩的USB設備，那么你應該在/etc/hal/fdi/policy中創建一個“preferences.fdi”文件，然后把下面這一行粘貼到文件中：

File: /etc/hal/fdi/policy/preferences.fdi <merge key="volume.ignore" type="bool">false</merge>

而且，如果你安裝了gparted，可能還需要刪除這個文件/usr/share/hal/fdi/policy/gparted-disable-automount.fdi 。在[1] 這個帖子的末尾有人提到這一點。

同時你還得刪除/etc/fstab 行中相應的usb設備，hal會自動掛載它們。

移除U盤導致不正常卸載

如果你在沒有卸載前移除你的U盤，HAL的自動卸載可能會工作不正常。

你會發現/media/.hal-mtab 中相應的記錄沒有被刪除，并且nautilus的設備列表（還有GNOME的桌面）會保留了指向設備曾經掛載過的空文件夾的鏈接。

這些都可以通過用延遲參數卸載U盤來解決。只要這么做：

1) 創建訪問權限755的可執行腳本/usr/lib/hal/hal-unmount.sh ，內容如下：

File: /usr/lib/hal/hal-unmount.sh #!/bin/sh # sanity check. DEVNAME should start with a / [ "$DEVNAME" != "${DEVNAME#/}" ] || exit 0# Lazily unmount drives which are removed, but still mounted if [ "$ACTION" = remove ] ; thenif [ -x /usr/bin/pumount ] ; then/usr/bin/pumount -l "$DEVNAME";else/bin/umount -l "$DEVNAME";fifiexit 0

2) 然后你得告訴HAL當你移除你的U盤時運行這個腳本。在/etc/udev/rules.d/90-hal.rules 中加入以下內容：

File: /etc/udev/rules.d/90-hal.rules SUBSYSTEM=="block", ACTION=="remove", RUN+="/usr/lib/hal/hal-unmount.sh"

3) 執行重啟