The problem did not exist with FreeBSD 9.x. When HAL was properly configured, sysutils/fusefs-ntfs installed and the instructions in /usr/local/share/doc/hal-0.5.11/README.fuse were followed, a ntfs-volume was automatically mounted just like any other volume (e.g. FAT). But since I upgraded my system to FreeBSD amd64 10.2 from 9.3, this is not the case anymore. Instead Dolphin now reports: "org.freedesktop.Hal.Device.Volume.UnknownFailure: mount: illegal option -- u usage: mount [-t fstype..." As I understand, in 10.x fuse is part of the base system now? Well, the automounting of ntfs-volumes just doesn't work anymore. At this point I would also like to ask if it is not about time to dump HAL, which is known not to work properly under FreeBSD anyway, in favour of a better automount mechanism, preferably based on devd(8). There is the port sysutils/automount which seems to work, but unfortunately only for USB-Sticks and harddrives, and not for CD-Roms or DVD's. The maintainer claims this is because devd does not produce events for CD's or DVD's and that this would be up to the FreeBSD developers. On the other hand, pcbsd has developed some other devd-based automount mechanism, "pc-mounttray", which is part of the pcbsd-utils-qt5 and does also mount CD's and DVD's, but does not work together with the native automounting functions of KDE, MATE, etc and is only available for 64-bit systems. Kind Regards, Werner Lehmann
Any news on this? When will that be fixed so one can get this working again performing a "freebsd-update" for the release branch? Or will this be fixed by 10.3-RELEASE?
(In reply to Werner Lehmann from comment #1) > Any news on this? When will that be fixed so one can get this working again > performing a "freebsd-update" for the release branch? Or will this be fixed > by 10.3-RELEASE? IMHO I think you'll get quicker resolution to this using HAL, than to try and adapt something else to work with it. Given that it is your belief that sysutils/hal is the culprit; would it make any sense to cc gnome@ since they maintain hal? Just a thought, in case it helps. :) --Chris
This is probably not an issue with HAL, ugly as HAL is. This is most likely fall-out of the removal of the old almost read-only implementation in the base system. In v9, the mount command attempt to mount NTFS file systems by calling the mount_ntfs(8) command. A script was provided on the gnome web page to replace mount_ntfs. It would translate the mount_ntfs command to ntfs-3g syntax and then exec ntfs-3g. The hooks in mount(8) to call mount_ntfs(8) were removed, breaking the ability to use the standard mount(8) command to mount the ntfs volume using the fuse-based ntfs-3g command. It looks like automount in 10.2 can work with devd to handle this. See section 17.4 of the FreeBSD Handbook. This assumes that you are talking about a removable device. Of course, the traditional /etc/fstab can be used for fixed ntfs file systems.
Thanks for the reply. I already suspected it had something to do with the removal of the old read-only implementation as you say. Regarding the new automount/autofs as described in chapter 17.4, I have tried that as well, only to find out that not everything gets always mounted in /media, my external ntfs-drive not at all (The label appears, but then no data in it and I have fuse installed), apart from the fact that if and when automount mounts something in /media, dolphin detects nothing. I have FreeBSD 10.2-RELEASE-0, so I don't know if I am missing something. But to me it looks like autofs is no solution that integrates with automatic desktop events provided by KDE/MATE/GNOME/LXDE, etc as HAL still does. I don't know if it is only me, but according to my perception many people who use FreeBSD use it as a desktop system. And to me a fully working automounting solution for a desktop environment is that little, but essential bit to put FreeBSD on par with Linux. A very positive step in the right direction in the recent past was to remove HAL from xorg and substitute it with devd for controlling the input devices, so I guess continuing in that direction with automounting would be the next logical thing. (Please also note that KDE4 unfortunately still needs HAL for power management, so would it not be possible to get that done by devd, too?). I am sorry that I can only give ideas and feedback from a desktop-minded end user, as I am not a computer scientist. In my first comment I already gave some ideas about automounting (devd-based sysutils/automount, but no support for optical media, or pc-mounttray) which might be a useful approach. Kind regards, Werner Lehmann
Have you made the appropriate entry in /etc/auto_master(5) to support ntfs-3g? Something like: /media -media -mountprog=/usr/local/sbin/ntfs-3g,rw,uid=1234,gid=1234,norecover,noatime,windows_names I don't currently have access to an NTFS file system to play with this. It's just a best guess. Also, carefully read the mount(8), ntfs-3g and auto_master(5) pages for a lot more detail. I have not fully groked auto_master(5) page. There is a LOT of flexibility and a lot of potential complexity. You want something that will work to make /media recognize an NTFS file type and use the correct mount operation.
I queries on the configuration of automount(8) for ntfs file systems and received two identical responses that, I believe, will resolve you issue. I was pretty close: - Install fusefs-ntfs - Enable autofs: # sysrc autofs_enable=YES # sysrc autounmountd_flags="-t 10" # unmount after 10s of inactivity - Make sure to add this to /etc/auto_master: /media -media -nosuid - Then you need this little patch for /etc/autofs/special_master: --- special_media.bak 2016-01-19 11:00:55.766975000 +0100 +++ special_media 2016-01-20 11:29:56.205575000 +0100 @@ -59,7 +59,16 @@ continue fi - echo "-fstype=${_fstype},nosuid :/dev/${_p}" + if [ ${_fstype} = "ntfs" ]; then + if [ -f "/usr/local/bin/ntfs-3g" ]; then + echo "-mountprog=/usr/local/bin/ntfs-3g,fstype=${_fstype},nosuid :/dev/${_p}" + else + /usr/bin/logger -p info \ + "Cannot mount ${_fstype} formatted device /dev/${_p}: Install sysutils/fusefs-ntfs first" + fi + else + echo "-fstype=${_fstype},nosuid :/dev/${_p}" + fi done # No matching device - don't print anything, autofs will handle it. - Start auto$foo: # service automountd start # service automounter start # service automountd start - Insert the NTFS device - Look for a new directory in /media - Access it A SLIGHTLY different answer from Edward Tomasz: --- special_media (revision 294670) +++ special_media (working copy) @@ -35,7 +35,11 @@ print_one() { _fstype="$(fstyp "/dev/${_key}" 2> /dev/null)" if [ $? -eq 0 ]; then - echo "-fstype=${_fstype},nosuid :/dev/${_key}" + if [ ${_fstype} = "ntfs" ]; then + echo "-fstype=${_fstype},nosuid,mountprog=/usr/local/bin/ntfs-3g :/dev/${_key}" + else + echo "-fstype=${_fstype},nosuid :/dev/${_key}" + fi return fi @@ -59,7 +63,11 @@ print_one() { continue fi - echo "-fstype=${_fstype},nosuid :/dev/${_p}" + if [ ${_fstype} = "ntfs" ]; then + echo "-fstype=${_fstype},nosuid,mountprog=/usr/local/bin/ntfs-3g :/dev/${_p}" + else Credit to Lars Engels and Edward Tomasz Napierała. (The latter wrote the automounter.) Note that you may want somewhat different options, but I think this should get you on the right track. If this fixes the issue, please close the ticket.
Assuming I understood right the last instruction "Then you need this little patch for /etc/autofs/special_master:", I copied the text of the first answer to a text editor and saved it as "autofs.diff". I then copied the file to the /etc/autofs/ directory and did a "patch <autofs.diff" which gave me the error message: oot@amd64:/etc/autofs # patch < autofs.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- special_media.bak 2016-01-19 11:00:55.766975000 +0100 |+++ special_media 2016-01-20 11:29:56.205575000 +0100 -------------------------- Patching file special_media using Plan A... Hunk #1 failed at 59. 1 out of 1 hunks failed--saving rejects to special_media.rej done I tried to delete the last bit "# No matching device - don't print anything, autofs will handle it.", and tried to apply the patch again, but got the same error message. I then created a second "aufofs2.diff" from the second answer and the got the following error message: root@amd64:/etc/autofs # patch < autofs2.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- special_media (revision 294670) |+++ special_media (working copy) -------------------------- Patching file special_media using Plan A... Hunk #1 failed at 35. patch: **** unexpected end of file in patch
Sorry. I truncated the patch. I just tested this one (if I can do the cut and paste right this time.) --- special_media (revision 294670) +++ special_media (working copy) @@ -35,7 +35,11 @@ print_one() { _fstype="$(fstyp "/dev/${_key}" 2> /dev/null)" if [ $? -eq 0 ]; then - echo "-fstype=${_fstype},nosuid :/dev/${_key}" + if [ ${_fstype} = "ntfs" ]; then + echo "-fstype=${_fstype},nosuid,mountprog=/usr/local/bin/ntfs-3g :/dev/${_key}" + else + echo "-fstype=${_fstype},nosuid :/dev/${_key}" + fi return fi @@ -59,7 +63,11 @@ print_one() { continue fi - echo "-fstype=${_fstype},nosuid :/dev/${_p}" + if [ ${_fstype} = "ntfs" ]; then + echo "-fstype=${_fstype},nosuid,mountprog=/usr/local/bin/ntfs-3g :/dev/${_p}" + else + echo "-fstype=${_fstype},nosuid :/dev/${_p}" + fi done # No matching device - don't print anything, autofs will handle it.
root@amd64:/etc/autofs # patch <autofs.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- special_media (revision 294670) |+++ special_media (working copy) -------------------------- Patching file special_media using Plan A... patch: **** malformed patch at line 10: "-fstype=${_fstype},nosuid,mountprog=/usr/local/bin/ntfs-3g root@amd64:/etc/autofs # Also moving up ':/dev/${_key}"' into line 10 changed nothing. Sorry, I am not a programmer, so I cannot see the possible error for myself.
Add trasz@ to CC for possible feedback regarding autofs comments. Any thoughts?
The patch was committed to 11-CURRENT in a slightly modified form. Just fetch it from the link below and copy to /etc/autofs/. Remember to make it owned by root and executable (chown 0:0, chmod +x). https://svnweb.freebsd.org/base/head/etc/autofs/special_media?revision=297016&view=co
Erm, allow me to rephrase: forget the patch; fetch the current version of the special_media script from the link above and put it where it belongs. After that you shouldn't need any special autofs configuration, apart from the steps described in the "17.4.2. Automounting Removable Media" section of https://www.freebsd.org/doc/handbook/usb-disks.html.
Add new maintainer to CC.
Is this still relevant?
Yes, it is. I am still using KDE4 with HAL (by now FreeBSD 11.1) and nothing has changed since then. I still have to mount external NTFS-Volumes manually as root with ntfs-3g. Btw: what are the plans for automounting functionality in KDE? Are you planning on sticking with HAL forever or are there any plans to change that? E.g there is dsbmd/dsbmc (still under development) now, a devd-based automounter, it somehow seems to work with MATE/caja and simpler window-managers, but not with KDE.
(In reply to Werner Lehmann from comment #15) > Yes, it is. I am still using KDE4 with HAL (by now FreeBSD 11.1) and nothing > has changed since then. I still have to mount external NTFS-Volumes manually > as root with ntfs-3g. Btw: what are the plans for automounting functionality > in KDE? Are you planning on sticking with HAL forever or are there any plans > to change that? E.g there is dsbmd/dsbmc (still under development) now, a > devd-based automounter, it somehow seems to work with MATE/caja and simpler > window-managers, but not with KDE. Is this a problem with KDE5 too? KDE4 is gone. Since this seems to be related to KDE, maybe we should invite kde@ here for some feedback.
Moin moin Automounting worked the last times i tried. You can use hald or bsdisks in kde. Please reopen if this is still an issue on a supported version of FreeBSD. Mfg Tobias
I think I understand what Werner Lehmann is writing. In my project ulbsd.ru, I have been using the following trick for many years since the FreeBSD 10.x with KDE4. Now I use this trick in FreeBSD 12.0 with KDE5. And it works for me. Step 1: I use patch for /usr/src/sbin/mount/mount.c: --- mount.c.orig 2016-10-15 17:03:43.284479000 +0300 +++ mount.c 2016-04-15 19:38:59.761871000 +0300 @@ -143,7 +143,7 @@ */ unsigned int i; const char *fs[] = { - "cd9660", "mfs", "msdosfs", "nfs", + "cd9660", "mfs", "msdosfs", "nfs", "ntfs", "nullfs", "smbfs", "udf", "unionfs", NULL }; cd /usr/src/sbin/mount/ make all install clean Step 2: Install fusefs-ntfs and create mount_ntfs link: pkg install -r latest fusefs-ntfs ln -s /usr/local/share/hal/mount-fuse /sbin/mount_ntfs chmod 555 /usr/local/share/hal/mount-fuse Step 3: Add to /boot/loader.conf: fuse_load="YES" Step 4: Add to /etc/sysctl.conf: vfs.usermount=1 Step 5: Add to /etc/devfs.rules: [localrules=10] # IDE/SATA Hard disks add path 'ad[0-9]*' mode 0660 group operator add path 'ada[0-9]*' mode 0660 group operator # SCSI/USB Hard disks add path 'da[0-9]*' mode 0660 group operator Step 6: Add to /etc/rc.conf: devfs_system_ruleset="localrules" Step 7: Change /usr/local/etc/PolicyKit/PolicyKit.conf: <config version="0.1"> <match user="root"> <return result="yes"/> </match> <define_admin_auth group="operator"/> <match action="org.freedesktop.hal.storage.mount-removable"> <return result="yes"/> </match> <match action="org.freedesktop.hal.storage.mount-fixed"> <return result="yes"/> </match> <match action="org.freedesktop.hal.storage.eject"> <return result="yes"/> </match> </config> After that, removable drives with the NTFS file system can be mounted on KDE4/5 in the usual way by root and users from the operator group. In KDE5 there is a small glitch (not critical) that can be fixed by changing the string "Exec=..." in file /usr/local/share/solid/actions/test-predicate-openwindow.desktop: Exec=/bin/sleep 0.5; [ ! -z "%f" ] && kde-open5 "%f"
I can confirm this is still happening in FreeBSD 12.1 and kde5 (5.14.5.18.12.2) with hal (0.5.14_34). I'm surprised this bug report got closed: Importance: --- Affects Many People Status: Closed Overcome By Events.
(In reply to Nick B from comment #19) The fact is that now the HAL is almost never used. See information about bsdisks https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242902 But the bsdisks is also not all good. I continue to use the HAL for now. My instructions in comment 18. But now I have modified the mount-fuse script a bit.
Thanks Serge for the info. Hopefully things line up so we have a proper mount interface for ntfs/exfat in kde in the near future.