devd based AUTOMOUNTER

Since it is generally a bad idea to unmount a file system after its storage has been removed (wrong order), I don't see the difference as such.
Then having several ZOMBIE processes trying to export ZFS pool forever is not a problem for You? For me its a BUG.

Simply removing the media is likely to screw up any file system involved, sometimes terminally.
Not true. For most time You only need to run fsck to mark filesystem as clean after removal before unmounting. After many removals of mounted filesystems with automount I have never ended with screwed filesystem.
 
Well, I have been at scientific conferences where the presentation was handed out on paper because the highly trained scientists pulled out their USB sticks without proper unmounting them and found out the files were shredded just before the talk. So it was back to good old "Open your books (proceedings) at page ...". I carry such items on at least three different types of data carrier, for that reason.

Any my question was aimed at the behaviour of the programms. Having ZOMBIE processes doing something is not good, it is a bug. But the same would/should be the case with other file systems. There, the forced unmount cleans up such things (I hope). The proper order is always to first unmount a file system and THEN remove the storage media.
 
Well, I have been at scientific conferences where the presentation was handed out on paper because the highly trained scientists pulled out their USB sticks without proper unmounting them and found out the files were shredded just before the talk. So it was back to good old "Open your books (proceedings) at page ...". I carry such items on at least three different types of data carrier, for that reason.
I definitely do not encourage to remove pendrive without unmounting at all times, I also did not said that all files copied to the ungracefully removed pendrive will be there, I just said that it never trashed my filesystem, fsck was always able to fix it and mark it clean. For most of the times files were there, several times last copied files were missing.

Any my question was aimed at the behaviour of the programms. Having ZOMBIE processes doing something is not good, it is a bug. But the same would/should be the case with other file systems. There, the forced unmount cleans up such things (I hope). The proper order is always to first unmount a file system and THEN remove the storage media.
ZFS datasets are not mounted, but pool is still imported:

Code:
% zpool list
NAME  SIZE  ALLOC  FREE  EXPANDSZ  FRAG  CAP  DEDUP  HEALTH  ALTROOT
local  216G  190G  25.6G  -  -  88%  1.00x  ONLINE  -
sys  15.9G  6.25G  9.62G  -  -  39%  1.00x  ONLINE  -
test  7.19G  69.5K  7.19G  -  0%  0%  1.00x  UNAVAIL  -

I tried to export it with force after pendrive removal, but that only creates zombie processes, they are probably harmless, I still got them as I do suspend/resume most of the time:
Code:
% ps ax|grep export
24782  6- I+  0:00.00 sudo zpool export -f test
24783  6- D+  0:00.00 zpool export -f test
16911  7- D+  0:00.01 zpool export -f test
73716 12  S+  0:00.00 grep --color export
36120  8- IN  0:00.00 sudo zpool export -f test
36121  8- DN  0:00.00 zpool export -f test
 
Under the evidence brought up I do need to change my point of view - supporting ZFS would be more trouble than it will be worth. Sad, but true.
 
Under the evidence brought up I do need to change my point of view - supporting ZFS would be more trouble than it will be worth. Sad, but true.
Its not that hard, if only that BUG that prevents from exporting ZFS pool after the pendrive is removed, its not that hard.

I already had 'flow' in my mind, but that BUG stopped all work ;)
 
That was what annoyed me a bit. Allowing ZFS should not be hard, unless I do not understand all things involved (can happen, but would be a bit embarrasing) OR there is some hidden problem that should not be there in the first place. And that is what happened. I did not know that exporting the pool after the device is gone would lead to deadlocks, zombies or even kernel panics. That should not happen, and I am confident that these things will be fixed. After that, it may be possible to have ZFS in the automount.
 
That was what annoyed me a bit. Allowing ZFS should not be hard, unless I do not understand all things involved (can happen, but would be a bit embarrasing) OR there is some hidden problem that should not be there in the first place. And that is what happened. I did not know that exporting the pool after the device is gone would lead to deadlocks, zombies or even kernel panics. That should not happen, and I am confident that these things will be fixed. After that, it may be possible to have ZFS in the automount.
There was time in FreeBSD history when removing the pendrive with any mounted filesystem would end in kernel panic. Thanks to @trasz this is not longer a problem ;)
 
There was time in FreeBSD history when removing the pendrive with any mounted filesystem would end in kernel panic. Thanks to @trasz this is not longer a problem ;)

Yep, I'm salty enough to remember those days, "why is this thing freezing all the time? :(" Lol.
 
I remember them, too. :(

But then, we were happy that this newfangled thing called USB was working at all.
 
Hello,

I'm using 1.5.3 on FreeBSD 10.1.

Now it mounts NTFS external hard disk, but not with its label (Iomega), but with its /dev/ name. And once mounted, I cannot unmount.

Please help!

Thanks,

Nad
 
Ok, I've tried every version. Only FAT32 stuffs mount.
For NTFS it never works, I find this strange as it works for you all...

Please help :/
 
Hi,

If you want help, you need to give us some information. First post automount_devd.conf and automount.conf.

Then, give us the result of pkg info | grep fuse. And check you have
Code:
fusefs_enable=YES
in etc/rc.conf.
 
Hello,

I'm using 1.5.3 on FreeBSD 10.1.

Now it mounts NTFS external hard disk, but not with its label (Iomega), but with its /dev/ name. And once mounted, I cannot unmount.

Please help!

Thanks,

Nad
NTFS is pretty 'random', its not about automount, its about the ntfs-3g. For example I have found many NTFS drives that will mount but I would not be able to write files on it (but can read), or it does not mount at all.

If You can, omit NTFS, its not safe filesystem.
 
Thanks,

Well I do have fusefs_enable="YES" in /etc/rc.conf

Here is the result of pkg info | grep fuse:
Code:
# pkg info | grep fuse
fusefs-exfat-1.0.1  Full-featured exFAT FS implementation as a FUSE module
fusefs-ext4fuse-0.1.3,1  EXT4 implementation for FUSE
fusefs-libs-2.9.3_3  FUSE allows filesystem implementation in userspace
fusefs-ntfs-2014.2.15_2  Mount NTFS partitions (read/write) and disk images
Here is automount.conf:
Code:
USERUMOUNT=YES
ATIME=NO
POPUP=YES
REMOVEDIRS=NO
FM="thunar"
USER=bioman
ENCODING=fr_FR.ISO8859-2
CODEPAGE=cp852
MNTPREFIX=/media
And automount_devd.conf:
Code:
notify 100 {
  match "system" "DEVFS";
  match "type" "CREATE";
  match "cdev" "(da|mmcsd)[0-9]+.*";
  action "/usr/local/sbin/automount $cdev attach";
};

notify 100 {
  match "system" "DEVFS";
  match "type" "DESTROY";
  match "cdev" "(da|mmcsd)[0-9]+.*";
  action "/usr/local/sbin/automount $cdev detach";
};
Is there a way to fix name of the device (currently /dev/foo), was the device label before.

vermaden: I cannot use another fs then NTFS, because I need my external HDD at work (Windows world), plus it works fine under Archlinux
 
Is there a way to fix name of the device (currently /dev/foo), was the device label before.
The sysutils/automount only checks for /dev/da* and /dev/mmcsd* devices:
Code:
% cat /usr/local/etc/devd/automount_devd.conf
notify 100 {
  match "system" "DEVFS";
  match "type" "CREATE";
  match "cdev" "(da|mmcsd)[0-9]+.*";
  action "/usr/local/sbin/automount $cdev attach";
};

notify 100 {
  match "system" "DEVFS";
  match "type" "DESTROY";
  match "cdev" "(da|mmcsd)[0-9]+.*";
  action "/usr/local/sbin/automount $cdev detach";
};
You may of course change that so it will also check labels on /dev.
vermaden: I cannot use another fs then NTFS, because I need my external HDD at work (Windows world), plus it works fine under Archlinux
FAT32 or exFAT will work the same here.
 
Thanks vermaden, it does not solve my problem.

Could you tell me what to change to get the device label name instead of the /dev/foo?

Also, does your scripts require HAL ?

Thanks,
Nad
 
Thanks vermaden, it does not solve my problem.

Could you tell me what to change to get the device label name instead of the /dev/foo?

I do not use labels, where are labels located?



Also, does your scripts require HAL ?

Well, it NEEDS HAL. Under Xfce4, now no devices are mounted anymore

Whats wrong with You people? :)

It DOES NOT REQUIRE HAL, it does not use HAL at all even if HAL is installed. The only thing it really requires is DEVD, that is why its devd(8) based automount ;)
 
Okay, so my FreeBSD is f*cked up ^^
With version 1.4.3, my USB key was mounted in /media/TOSHIBA. But 1.4.3 does not work with 10.1 IIRC.
 
Okay, so my FreeBSD is f*cked up ^^
With version 1.4.3, my USB key was mounted in /media/TOSHIBA. But 1.4.3 does not work with 10.1 IIRC.
FreeBSD 10.x came with newer file(1) that needs -k flag now.

The other thing is that the config in port for devd(8) was working with older devd(8) while newer devd(8) has fixed regular expressions so needed a newer config, check this whole thread for details.
 
Hi vermaden,
I installed your program from ports automount-1.5.3 and I have problems with automount in mounting USB flash drives with msdos file systems. The problem is all drives I have don't have 'DOS/MBR' string. Here are some examples:
Code:
1. x86 boot sector, code offset 0x58, OEM-ID "BSD4.4  ", sectors/cluster 64, heads 255, sectors 7904295 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 965, Backup boot sector 2, serial number 0xd76016f9,  DOS executable (COM), boot code
2. x86 boot sector, code offset 0x58, OEM-ID "MSDOS5.0", sectors/cluster 8, reserved sectors 38, Media descriptor 0xf8, heads 255, hidden sectors 2976, sectors 7904352 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 7705, serial number 0x1938c1c6, unlabeled DOS executable (COM), boot code
3. x86 boot sector, Microsoft Windows 98 Bootloader IO.SYS+MSDOS.SYS, code offset 0x3c, OEM-ID "MSWIN4.1", sectors/cluster 32, root entries 512, Media descriptor 0xf8, sectors/FAT 245, heads 255, hidden sectors 63, sectors 2006976 (volumes > 32 MB) , serial number 0x66b10487, unlabeled, FAT (16 bit) DOS executable (COM), boot code
Instead of 'DOS/MBR' I have 'x86'. Removing 'DOS/MBR' on line 298 fixed my problem.
Code:
if echo "${TYPE}" | grep -q 'ext4'
  then
  TYPE=EXT4
  return
  fi
-   if echo "${TYPE}" | grep -q 'DOS/MBR boot sector'
+  if echo "${TYPE}" | grep -q 'boot sector'
  then
  __log "${TYPE} boot"

  TYPE=$( file -r -k -b -L -s ${DEV} | sed -E 's/label:\ \".*\"//g' )
  if echo "${TYPE}" | grep -q 'Unix Fast File'
  then
  TYPE=UFS
  return
  fi
 
I have two things I would like to share/suggest.

One thing that got me was the hard coded user name in the config file. I had to set up a labtop (no spelling mistake, a laptop for lab work) which is used by more than one user. Since each user has his own preferences, there can not be one standard user for that machine. But now this static configuration line does not work. So I replaced that one with this line:
Code:
USER=`ls -l /tmp/Xrootenv|cut -w -f 3`
This is giving me the currently running X user. This is most likely not elegant, but it works well for now. Maybe this can be a suggestion for improvements. Also, this only works with X running, but if you are running in console mode, you may also know how to use the rectangular assortment of rectangular things in front of you to spell the magic invocation needed to mount a file system. ;)

The second point is that I have tried to use PEFS with removable media. It would be a good add-on if the automounter would, after mounting, check for a hint on the device and then use the correct key file to mount the content with PEFS, in some sensible way. When using some indication for the key file on the device, you can have the key in some user directory, and maybe have several keys there for several projects. That way you may encrypt the data for different use cases with different keys, without looking them up each time or handing one keyfile around to world+dog for 'convenience'.

Thank you for reading.
 
Back
Top