usb-automount: do it with pure udev rules

taylorchu · 2013-03-29 05:52:48

did someone do this before? today i just feel that usb "plug and play" is so easy to do; you dont even need a daemon.
udev rules can do this efficiently.

after you install the program, please reboot.

1. what happened? all your usb drives are mounted to /usb/... automatically.
2. how to safely remove usb drive?  sudo umount_dmenu
after you see "you can safely remove ...", then you can pull it off

try it: https://aur.archlinux.org/packages/usb-automount/

Last edited by taylorchu (2013-03-31 05:26:10)

WonderWoofy · 2013-03-29 06:32:59

Though I cannot give you reasons why, this practice is highly discouraged by upstream. I have seen it referred to as an "abuse of their intended functionality" before, but am not entirely sure why this would be.

Still, I have thought about doing this many times myself, but there are so many tools out there that apparently do this "correctly" that I just never actually went through with it. Actually these days, I just don't automount. I kind of like the fact that if someone else puts a usb in my machine, they will be entirely lost as to how to make it work. Though, I think my entire machine is kind of like that.

parazyd · 2013-03-29 06:45:06

@WonderWoofy: Just another level of security

taylorchu · 2013-03-29 07:41:40

I dont know but this is the reponse to my friend's joke: "too many commands in linux".
mkdir, mount, do the work, umount, rmdir => do the work straight

mhogomchungu · 2013-03-29 08:04:22

taylorchu wrote:

did someone do this before? today i just feel that usb "plug and play" is so easy to do; you dont even need a daemon.
udev rules can do this efficiently.
try it: https://aur.archlinux.org/packages/usb-automount/

Thats an odd way of doing things.

Let say you copied a folder with a bunch of files to the usb stick,what guarantee do you have that the data is written to the usb stick before you unplug it?.

Mounting tools use different mount options depending on the file system on the drive,you way just goes with the generic defaults for the file system on the drive and the default options may not be the optimal ones.

doing it this way and you will surely loose some data sooner or later.

65kid · 2013-03-29 12:11:20

As already mentioned by WonderWoofy, this is highly discouraged, udev rules are not meant to do complex things like automounting devices. For example these rules don't work at all with ntfs-3g devices because the ntfs-3g mount process has to stay around the entire time that the device is mounted and udev will kill the process after some time. This and other weird issues like devices being mounted twice etc. have already caused quite a few threads around here.

Furthermore the umount command is non-sense. As soon as the remove action is triggered, the device is already gone, what exactly is supposed to be unmounted? You are risking data loss here while udisks would allow you to safely unmount the device without requiring root priviliges.

Army · 2013-03-29 12:39:02

WonderWoofy wrote:

I kind of like the fact that if someone else puts a usb in my machine, they will be entirely lost as to how to make it work. Though, I think my entire machine is kind of like that.

*lol*, +1 brother!

@taylorchu, such an udev rule has been in the wiki some time ago. I used it for a long time, but at some point it didn't mount drives on boot, which were plugged in before the boot process. So I switched to udevil.

Just if you are curious, here's the script I used to use.

taylorchu · 2013-03-29 17:00:01

I am glad that everyone talked about the technical detail.
@mhogomchungu
1. this is automount, not autoumount. the rule for removing is to "auto remove the directory". likewise, any daemon cannot hace auto umount feature.
even if they force kernel to write back, they are doomed to lose data. (kernel write back faster or you unplug it faster)
2. this is not true: the generic mount detects filesystem with superblock. if it succeeds, it is really likely to be correct(otherwise your superblock is corrupted and it magically changes to the format of other filesystem type).

@65kid
1. you can mount ntfs with "mount" after ntfs-3g.
2. a device can never be mount twice this way.
3. if someone unplug without calling umount. the kernel still keep some records in /proc/mounts. umount removes that record.
in addition, it guarantees that rmdir will not have error.

@army
my udev rules can mount usb on boot. I haven't tried your rules yet.

falconindy · 2013-03-29 17:14:03

taylorchu wrote:

@65kid
1. you can mount ntfs with "mount" after ntfs-3g.

Doesn't this defeat the point of your rules?

taylorchu wrote:

2. a device can never be mount twice this way.

This is a non-problem, and it isn't even true.

taylorchu wrote:

3. if someone unplug without calling umount. the kernel still keep some records in /proc/mounts. umount removes that record.

No, this isn't true. The device disappears and the mount entry in the namespace is torn down without regard for open file handles. You can't possibly guarantee a safe removal of the device if you don't umount it before the device removal event.

taylorchu wrote:

in addition, it guarantees that rmdir will not have error.

I don't even know what this means, or why you should care.

Do. Not. Do. This.

taylorchu · 2013-03-29 17:46:43

@falconindy
1. i mean after you install ntfs-3g, you can use mount command to mount ntfs. there will not be any problem if it is called with udev rules.
2. I will just use the source code to show
https://github.com/karelzak/util-linux/ … nt.c#L1077
3. no, i mean if a stupid guy pulls the usb before he umounts the usb, some records still are kept in the kernel. The userspace mount will still mount next time for that device because a new block device is created instead. (for example, after pulling sdb without umount, and you insert the same device again, it will become sdc.)
i understand your point: there is no such thing as autoumount.
4. you cannot remove the directory if it is still mounted. even though the kernel might remove all related mount record for you, it is better to do it yourself.

again: this IS automount, NOT autoumount.

mhogomchungu · 2013-03-29 17:52:52

taylorchu wrote:

I am glad that everyone talked about the technical detail.
@mhogomchungu
1. this is automount, not autoumount. the rule for removing is to "auto remove the directory". likewise, any daemon cannot hace auto umount feature.
even if they force kernel to write back, they are doomed to lose data. (kernel write back faster or you unplug it faster)

How do you unmount your device then or how will a person who go with your solution unmount their devices before unplugging them?

This seem like half a solution and its silence on the remaining half suggests the solution to umount is to simply unplug a drive and let the tool clean up what will be left behind.

Last edited by mhogomchungu (2013-03-29 18:03:42)

65kid · 2013-03-29 18:08:15

1. i mean after you install ntfs-3g, you can use mount command to mount ntfs. there will not be any problem if it is called with udev rules.

You didn't understand the actual problem. Of course you can use "mount" with ntfs-3g, that wasn't the point. The point is that when you mount an ntfs-3g filesystem (maybe this is even true for all FUSE filesystems, I don't know), the mount process will spawn another mount process which has to stay around the entire time the device is mounted. udev however will kill this process after some time. This is what causes the infamous "transport endpoint not connected" error that we had a lot of threads about.

2. I will just use the source code to show
https://github.com/karelzak/util-linux/ … nt.c#L1077

https://bbs.archlinux.org/viewtopic.php?id=154375

4. you cannot remove the directory if it is still mounted. even though the kernel might remove all related mount record for you, it is better to do it yourself.

You know what is even better? Letting udisks handle it instead.

taylorchu · 2013-03-30 03:14:03

@mhogomchungu
1. i think you can choose to use umount or eject.
i will write a dmenu script for quick access.
2. yes. the udev rules will clean up the mount dir for you.

@65kid
1. would you mind giving the source in detail?
2. that is gvfs bug. if you use mount, after the first mount, the second mount will not succeed.
3. true.

65kid · 2013-03-30 11:46:20

taylorchu wrote:

1. would you mind giving the source in detail?

you mean like this? https://bbs.archlinux.org/viewtopic.php?id=157534
Or are you asking me to find the source code line where udev kills any long-running processes? I'm not gonna do that, if you don't believe me, try it yourself.

taylorchu wrote:

2. that is gvfs bug. if you use mount, after the first mount, the second mount will not succeed.

I don't think the problem in this thread had anything to do with gvfs. the udev rule simply ignored the fact that udisks had already mounted these devices.

The point is, these udev automount rules have caused nothing but problems, people shouldn't be encouraged to use them.

taylorchu · 2013-03-31 05:21:33

@65kid
oh, I misread the main points of your posts twice. very sorry about that
1. actually yes, udev kills long running process in 4-5secs (I tested this myself, and it is clearly written in the udev doc).
2. udev simply reports the device add/remove event. it is programmer's fault not to think about double-mount problems. i dont care what happened there, because they are not using "mount". mount is safe to use!
3. at first i dont know about the ntfs problem. but it is fixed now. You can test it with any ntfs usb drive.

taylorchu · 2013-04-04 06:41:01

I added another package: device-sound.
it creates similar behavior like we have on windows: play a sound when we insert/remove usb mouse or disk.
again it does not need to config. after installation, you will be about to hear it.

ccpaging · 2013-08-23 14:32:59

Great work. Better to add "-o utf8" to mount command.

Arch Linux

#1 2013-03-29 05:52:48

usb-automount: do it with pure udev rules

#2 2013-03-29 06:32:59

Re: usb-automount: do it with pure udev rules

#3 2013-03-29 06:45:06

Re: usb-automount: do it with pure udev rules

#4 2013-03-29 07:41:40

Re: usb-automount: do it with pure udev rules

#5 2013-03-29 08:04:22

Re: usb-automount: do it with pure udev rules

#6 2013-03-29 12:11:20

Re: usb-automount: do it with pure udev rules

#7 2013-03-29 12:39:02

Re: usb-automount: do it with pure udev rules

#8 2013-03-29 17:00:01

Re: usb-automount: do it with pure udev rules

#9 2013-03-29 17:14:03

Re: usb-automount: do it with pure udev rules

#10 2013-03-29 17:46:43

Re: usb-automount: do it with pure udev rules

#11 2013-03-29 17:52:52

Re: usb-automount: do it with pure udev rules

#12 2013-03-29 18:08:15

Re: usb-automount: do it with pure udev rules

#13 2013-03-30 03:14:03

Re: usb-automount: do it with pure udev rules

#14 2013-03-30 11:46:20

Re: usb-automount: do it with pure udev rules

#15 2013-03-31 05:21:33

Re: usb-automount: do it with pure udev rules

#16 2013-04-04 06:41:01

Re: usb-automount: do it with pure udev rules

#17 2013-08-23 14:32:59

Re: usb-automount: do it with pure udev rules

Board footer