Bug 204464 - sysutils/fusefs-ntfs: No automount with HAL of ntfs-volumes since FreeBSD 10.x
Summary: sysutils/fusefs-ntfs: No automount with HAL of ntfs-volumes since FreeBSD 10.x
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords: needs-patch, needs-qa, regression
Depends on:
Blocks:
 
Reported: 2015-11-11 11:20 UTC by Werner Lehmann
Modified: 2019-02-03 11:10 UTC (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Werner Lehmann 2015-11-11 11:20:59 UTC
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
Comment 1 Werner Lehmann 2016-01-21 11:20:13 UTC
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?
Comment 2 Chris Hutchinson 2016-01-21 16:04:08 UTC
(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
Comment 3 rkoberman 2016-01-23 06:09:32 UTC
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.
Comment 4 Werner Lehmann 2016-01-23 10:31:17 UTC
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
Comment 5 rkoberman 2016-01-24 23:18:46 UTC
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.
Comment 6 rkoberman 2016-01-25 21:25:34 UTC
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.
Comment 7 Werner Lehmann 2016-01-26 20:05:00 UTC
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
Comment 8 rkoberman 2016-01-27 05:19:25 UTC
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.
Comment 9 Werner Lehmann 2016-01-27 10:54:40 UTC
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.
Comment 10 Jason Unovitch freebsd_committer 2016-04-10 00:22:02 UTC
Add trasz@ to CC for possible feedback regarding autofs comments. Any thoughts?
Comment 11 Edward Tomasz Napierala freebsd_committer 2016-04-11 11:09:42 UTC
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
Comment 12 Edward Tomasz Napierala freebsd_committer 2016-04-11 11:12:55 UTC
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.
Comment 13 Jason Unovitch freebsd_committer 2016-06-05 22:53:26 UTC
Add new maintainer to CC.
Comment 14 Walter Schwarzenfeld freebsd_triage 2018-01-14 03:39:15 UTC
Is this still relevant?
Comment 15 Werner Lehmann 2018-01-14 19:19:25 UTC
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.
Comment 16 Tobias Kortkamp freebsd_committer 2019-02-02 18:20:32 UTC
(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.
Comment 17 Tobias C. Berner freebsd_committer 2019-02-02 19:03:06 UTC
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
Comment 18 Serge Volkov 2019-02-03 11:10:28 UTC
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"