removable devices auto umounting

I'm just looking into the removable device issue for
freebsd. I can see
its easy enough to auto mount a removable device (although I
could use
some help getting sd/xd devices working with my card
reader), but the
removal seems to come unstuck.

I have some barely literates on my systems, so I do need to
work this
out. Is it possible to use a forced umount to do this? What
are the
options here?

Also how do I get the memory card reader working? I believe
I'm using a
texas instruments internal here. If its in a hidden document
somewhere a
link would be helpful. I have tried looking at the messages,
but its not
all that clear, and so far all I've found in searches is for
usb card
readers.

Cheers

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On Thu, Mar 20, 2008 at 11:55:32AM +1000, Da Rock wrote:
> I'm just looking into the removable device issue for
freebsd. I can see
> its easy enough to auto mount a removable device
(although I could use
> some help getting sd/xd devices working with my card
reader), but the
> removal seems to come unstuck.
> 
> I have some barely literates on my systems, so I do
need to work this
> out. Is it possible to use a forced umount to do this?
What are the
> options here?

In short, no. Removal of a USB device would be forwarded to
devd(8). But
since the device is no longer there at that moment, you
cannot unmount
it anymore. You might get a nice kernel panic for your
efforts, though. 

The FreeBSD disk subsystem was simple not written with
removable devices
in mind, because they didn't exist back then. Until that
code is fixed
(which is hard) you _have_ to unmount before you pull the
device out.

One (not bullet-proof) workaround might be to use the
automounter
[amd(8)], and have it unmount very quickly after they stop
being
active. This requires setting both the 'cache_duration' and
'dismount_interval' options in amd.conf(5) to very low
values.
 
Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~r
smith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much
appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725
(KeyID: C321A725)

What about a "Safely Remove Hardware"-style icon
on your desktop,
which could simply run a script to unmount (with force if
the user has
it open somewhere).

-Patrick

On 20/03/2008, Rolannessto <rsmithxs4all.nl> wrote:
> On Thu, Mar 20, 2008 at 11:55:32AM +1000, Da Rock
wrote:
>  > I'm just looking into the removable device issue
for freebsd. I can see
>  > its easy enough to auto mount a removable device
(although I could use
>  > some help getting sd/xd devices working with my
card reader), but the
>  > removal seems to come unstuck.
>  >
>  > I have some barely literates on my systems, so I
do need to work this
>  > out. Is it possible to use a forced umount to do
this? What are the
>  > options here?
>
>
> In short, no. Removal of a USB device would be
forwarded to devd(8). But
>  since the device is no longer there at that moment,
you cannot unmount
>  it anymore. You might get a nice kernel panic for your
efforts, though. 
>
>  The FreeBSD disk subsystem was simple not written with
removable devices
>  in mind, because they didn't exist back then. Until
that code is fixed
>  (which is hard) you _have_ to unmount before you pull
the device out.
>
>  One (not bullet-proof) workaround might be to use the
automounter
>  [amd(8)], and have it unmount very quickly after they
stop being
>  active. This requires setting both the
'cache_duration' and
>  'dismount_interval' options in amd.conf(5) to very low
values.
>
>  Roland
>
> --
>  R.F.Smith                                   http://www.xs4all.nl/~r
smith/
>  [plain text _non-HTML_ PGP/GnuPG encrypted/signed
email much appreciated]
>  pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321
A725 (KeyID: C321A725)
>
>
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On Thu, 2008-03-20 at 08:43 +0100, Rolannessto wrote:
> On Thu, Mar 20, 2008 at 11:55:32AM +1000, Da Rock
wrote:
> > I'm just looking into the removable device issue
for freebsd. I can see
> > its easy enough to auto mount a removable device
(although I could use
> > some help getting sd/xd devices working with my
card reader), but the
> > removal seems to come unstuck.
> > 
> > I have some barely literates on my systems, so I
do need to work this
> > out. Is it possible to use a forced umount to do
this? What are the
> > options here?
> 
> In short, no. Removal of a USB device would be
forwarded to devd(8). But
> since the device is no longer there at that moment, you
cannot unmount
> it anymore. You might get a nice kernel panic for your
efforts, though. 
> 
> The FreeBSD disk subsystem was simple not written with
removable devices
> in mind, because they didn't exist back then. Until
that code is fixed
> (which is hard) you _have_ to unmount before you pull
the device out.
> 
> One (not bullet-proof) workaround might be to use the
automounter
> [amd(8)], and have it unmount very quickly after they
stop being
> active. This requires setting both the 'cache_duration'
and
> 'dismount_interval' options in amd.conf(5) to very low
values.
>  
> Roland

So by active you mean device access? Or device physical
connection? If
its simply access, than that would be perfect- user enters
the mount
point, reads or writes a file, amd times out after X secs
and dismounts
the device. Physical could be a bit harder...

Also, what docs/how-to's would you suggest for AMD? I looked
at the man
and some freebsd doc pages, but another viewpoint would
help.
Specifically some more docs on the settings you mention.

Bullet-proof is not exactly necessary- nice, but not
critical.
Suggestions for bullet-proof are very welcome though. What
is the worst
that can happen if dismounting is not entirely successful?
Keeping in
mind that this is mostly a desktop system.

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On Thu, Mar 20, 2008 at 09:55:37PM +1000, Da Rock wrote:

> > > I'm just looking into the removable device
issue for freebsd. I can see
> > > its easy enough to auto mount a removable
device (although I could use
> > > some help getting sd/xd devices working with
my card reader), but the
> > > removal seems to come unstuck.
> > > 
> > > I have some barely literates on my systems,
so I do need to work this
> > > out. Is it possible to use a forced umount to
do this? What are the
> > > options here?

In all honesty, I'm not sure FreeBSD (or any other OS, for
that matter)
is suitable for 'barely literates'. A computer is not a
toaster.

<snip>
> > One (not bullet-proof) workaround might be to use
the automounter
> > [amd(8)], and have it unmount very quickly after
they stop being
> > active. This requires setting both the
'cache_duration' and
> > 'dismount_interval' options in amd.conf(5) to very
low values.
> 
> So by active you mean device access? 

I mean access to the auto-mounted directory, or files
therein.

> Or device physical connection? If
> its simply access, than that would be perfect- user
enters the mount
> point, 

User needs to plug in the device first!

And it is actually worse. Depending on if and how the usb
device was set
up, you need to use the device daX[sY], where X depends on
how many other
da devices are already in use, and the optional Y depends on
how it was
sliced (partitioned in DOS parlance). 

Furthermore, you need to know which kind of filesystem is
used. Most
thumbdrives are msdosfs, but larger ones might be ntfs as
well.

For msdosfs, I use: 
'mount_msdosfs -m 644 -M 755 -o noatime -o sync -o noexec -o
nosuid $DEV $DIR'

> Also, what docs/how-to's would you suggest for AMD? I
looked at the man
> and some freebsd doc pages, but another viewpoint would
help.
> Specifically some more docs on the settings you
mention.

I've never used amd, so I can't help you there. 
 
> Bullet-proof is not exactly necessary- nice, but not
critical.
> Suggestions for bullet-proof are very welcome though.
What is the worst
> that can happen if dismounting is not entirely
successful? Keeping in
> mind that this is mostly a desktop system.

Last time I tried unplugging a USB device before unmounting
it I got a
kernel panic.

Roland
-- 
R.F.Smith                                   http://www.xs4all.nl/~r
smith/
[plain text _non-HTML_ PGP/GnuPG encrypted/signed email much
appreciated]
pgp: 1A2B 477F 9970 BA3C 2914  B7CE 1277 EFB0 C321 A725
(KeyID: C321A725)

On Thu, 2008-03-20 at 14:14 +0100, Rolannessto wrote:
> On Thu, Mar 20, 2008 at 09:55:37PM +1000, Da Rock
wrote:
> 
> > > > I'm just looking into the removable
device issue for freebsd. I can see
> > > > its easy enough to auto mount a
removable device (although I could use
> > > > some help getting sd/xd devices working
with my card reader), but the
> > > > removal seems to come unstuck.
> > > > 
> > > > I have some barely literates on my
systems, so I do need to work this
> > > > out. Is it possible to use a forced
umount to do this? What are the
> > > > options here?
> 
> In all honesty, I'm not sure FreeBSD (or any other OS,
for that matter)
> is suitable for 'barely literates'. A computer is not a
toaster.

True enough. But at least they know how to plug in and
unplug a device-
I just don't know if they'll remember to umount first!

> 
> <snip>
> > > One (not bullet-proof) workaround might be to
use the automounter
> > > [amd(8)], and have it unmount very quickly
after they stop being
> > > active. This requires setting both the
'cache_duration' and
> > > 'dismount_interval' options in amd.conf(5) to
very low values.
> > 
> > So by active you mean device access? 
> 
> I mean access to the auto-mounted directory, or files
therein.

That'd be perfect then.

> 
> > Or device physical connection? If
> > its simply access, than that would be perfect-
user enters the mount
> > point, 
> 
> User needs to plug in the device first!
> 
> And it is actually worse. Depending on if and how the
usb device was set
> up, you need to use the device daX[sY], where X depends
on how many other
> da devices are already in use, and the optional Y
depends on how it was
> sliced (partitioned in DOS parlance). 
> 
> Furthermore, you need to know which kind of filesystem
is used. Most
> thumbdrives are msdosfs, but larger ones might be ntfs
as well.
> 
> For msdosfs, I use: 
> 'mount_msdosfs -m 644 -M 755 -o noatime -o sync -o
noexec -o nosuid $DEV $DIR'
> 

I'm sure I could script something to get around that. That
shouldn't be
too hard, but I take your point: I need to consider nearly
all
possibilities.

> > Also, what docs/how-to's would you suggest for
AMD? I looked at the man
> > and some freebsd doc pages, but another viewpoint
would help.
> > Specifically some more docs on the settings you
mention.
> 
> I've never used amd, so I can't help you there. 
>  
> > Bullet-proof is not exactly necessary- nice, but
not critical.
> > Suggestions for bullet-proof are very welcome
though. What is the worst
> > that can happen if dismounting is not entirely
successful? Keeping in
> > mind that this is mostly a desktop system.
> 
> Last time I tried unplugging a USB device before
unmounting it I got a
> kernel panic.
> 
> Roland

That last point would only occur if the device was still
being written
to- right? I'm sure my users can be trained at least that
far... I will
watch out for that though.

Thanks for the input. I reckon I can get it working
(relatively)
smoothly now.

Don't suppose you know anything about setting up internal
card readers
in laptops at all? Trouble is I don't think it's hooked up
to the usb
bus. Its a Texas Instruments model.

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

Am Fri, 21 Mar 2008 09:40:39 +1000 schrieb Da Rock
<rock_on_the_webcomcen.com.au>:


> That last point would only occur if the device was
still being written
> to- right?

No.
Removing a mounted device will cause a panic, writes pending
or not.

Maybe look at the emulators/mtools port, which gives you
access to
FAT formatted media without mounting them.

Michael



_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

>> On Thu, Mar 20, 2008 at 11:55:32AM +1000, Da Rock
wrote:
>>> I'm just looking into the removable device
issue for freebsd. I can
>>> see its easy enough to auto mount a removable
device (although I
>>> could use some help getting sd/xd devices
working with my card
>>> reader), but the removal seems to come
unstuck.
>>> 
>>> I have some barely literates on my systems, so
I do need to work
>>> this out. Is it possible to use a forced umount
to do this? What
>>> are the options here?

In KDE (same for GNOME and such I figure), removable devices
like usb
keys, cameras, cd/dvd are automounted and appear on the
desktop.
Using the right-click popup menu you can "Safely
remove" or "Eject"
them.

For this to work, you need to have sysutils/hal installed
and configure
x11/kdebase3 to enable hal support (this is the default).

Then you need to give users permission to access necessary
devices.
It's best to create a separate group for that like plugdev
and then
add users to this group. To give a plugdev group access to
devices
create/edit the file /etc/devfs.rules to contain:

--- begin /etc/devfs.rules ---
[local_ruleset=10]
#allow plugdev to access the CAM subsystem (required for
cd/dvd burning and usb mass storage)
add path xpt0 user root group plugdev mode 0660
add path 'pass*' user root group plugdev mode 0660
#only allow root for specific fixed SCSI drives if any
#add path pass0 user root group operator mode 0660
#add path pass1 user root group operator mode 0660
#...

#allow plugdev to access the cdrom
add path cd0 user root group plugdev mode 0660

#allow plugdev to access usb mass storage
add path 'da*' user root group plugdev mode 0660
#only allow root for specific fixed SCSI drives if any
#add path 'da0*' user root group operator mode 0660
#add path 'da1*' user root group operator mode 0660
#...

#allow plugdev to access generic usb devices (cameras/mp3
players using libusb)
add path 'usb*' user root group plugdev mode 0660
add path 'ugen*' user root group plugdev mode 0660
--- end /etc/devfs.rules ---

(You don't need anything special in /etc/devfs.conf. If
you've put
stuff there to get cd burning working for normal users, you
can
remove it. (permission for cd,xpt,pass devices))

In /etc/rc.conf then make sure you have these lines:

dbus_enable="YES"
devfs_system_ruleset="local_ruleset"
hald_enable="YES"
polkitd_enable="YES"

And finally, give plugdev access to hal by editing
/usr/local/etc/dbus-1/system.d/hal.conf
At the end of that file it says:

  <!-- You can change this to a more suitable user, or
make per-group -->
  <policy group="operator">
    <allow
send_interface="org.freedesktop.Hal.Device.SystemPowerM
anagement"/>
    <allow
send_interface="org.freedesktop.Hal.Device.LaptopPanel&
quot;/>
    <allow
send_interface="org.freedesktop.Hal.Device.Volume"
/>
    <allow
send_interface="org.freedesktop.Hal.Device.Volume.Crypt
o"/>
  </policy>

On the second line above, change "operator" to
"plugdev".

Then make sure you have a /var/media directory and /media
linking to it
and nothing related to removable devices in /etc/fstab
(including cdrom).
Reboot your system and if I didn't miss anything, any user
in the
plugdev group should be able to use removable devices quite
easily.
_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"

On Fri, 2008-03-21 at 16:21 +0100, Tijl Coosemans wrote:
> >> On Thu, Mar 20, 2008 at 11:55:32AM +1000, Da
Rock wrote:
> >>> I'm just looking into the removable device
issue for freebsd. I can
> >>> see its easy enough to auto mount a
removable device (although I
> >>> could use some help getting sd/xd devices
working with my card
> >>> reader), but the removal seems to come
unstuck.
> >>> 
> >>> I have some barely literates on my
systems, so I do need to work
> >>> this out. Is it possible to use a forced
umount to do this? What
> >>> are the options here?
> 
> In KDE (same for GNOME and such I figure), removable
devices like usb
> keys, cameras, cd/dvd are automounted and appear on the
desktop.
> Using the right-click popup menu you can "Safely
remove" or "Eject"
> them.
> 
> For this to work, you need to have sysutils/hal
installed and configure
> x11/kdebase3 to enable hal support (this is the
default).
> 
> Then you need to give users permission to access
necessary devices.
> It's best to create a separate group for that like
plugdev and then
> add users to this group. To give a plugdev group access
to devices
> create/edit the file /etc/devfs.rules to contain:
> 
> --- begin /etc/devfs.rules ---
> [local_ruleset=10]
> #allow plugdev to access the CAM subsystem (required
for cd/dvd burning and usb mass storage)
> add path xpt0 user root group plugdev mode 0660
> add path 'pass*' user root group plugdev mode 0660
> #only allow root for specific fixed SCSI drives if any
> #add path pass0 user root group operator mode 0660
> #add path pass1 user root group operator mode 0660
> #...
> 
> #allow plugdev to access the cdrom
> add path cd0 user root group plugdev mode 0660
> 
> #allow plugdev to access usb mass storage
> add path 'da*' user root group plugdev mode 0660
> #only allow root for specific fixed SCSI drives if any
> #add path 'da0*' user root group operator mode 0660
> #add path 'da1*' user root group operator mode 0660
> #...
> 
> #allow plugdev to access generic usb devices
(cameras/mp3 players using libusb)
> add path 'usb*' user root group plugdev mode 0660
> add path 'ugen*' user root group plugdev mode 0660
> --- end /etc/devfs.rules ---
> 
> (You don't need anything special in /etc/devfs.conf. If
you've put
> stuff there to get cd burning working for normal users,
you can
> remove it. (permission for cd,xpt,pass devices))
> 
> In /etc/rc.conf then make sure you have these lines:
> 
> dbus_enable="YES"
> devfs_system_ruleset="local_ruleset"
> hald_enable="YES"
> polkitd_enable="YES"
> 
> And finally, give plugdev access to hal by editing
> /usr/local/etc/dbus-1/system.d/hal.conf
> At the end of that file it says:
> 
>   <!-- You can change this to a more suitable user,
or make per-group -->
>   <policy group="operator">
>     <allow
send_interface="org.freedesktop.Hal.Device.SystemPowerM
anagement"/>
>     <allow
send_interface="org.freedesktop.Hal.Device.LaptopPanel&
quot;/>
>     <allow
send_interface="org.freedesktop.Hal.Device.Volume"
/>
>     <allow
send_interface="org.freedesktop.Hal.Device.Volume.Crypt
o"/>
>   </policy>
> 
> On the second line above, change "operator"
to "plugdev".
> 
> Then make sure you have a /var/media directory and
/media linking to it
> and nothing related to removable devices in /etc/fstab
(including cdrom).
> Reboot your system and if I didn't miss anything, any
user in the
> plugdev group should be able to use removable devices
quite easily.

Thanks for that- I was just looking into that from the
Project Utopia
article. Just a couple of things-

1. You still have to click eject before removing the device.
Is there a
way to skip this and just remove the device?

2. The D-Bus system only works with an X wm doesn't it?

I know it seems contrary, but is there a way I can set this
up so that
it will work from a standard tty? The amd system appears to
allow this,
but it does have its faults as well.

Consider this theory: IF the X windows system is running-
D-Bus and all-
can other background daemons use this system? I guess they
wouldn't need
to concern themselves with this problem as the X windows
will be taking
care of it automatically.

Another thought: do all wm's use the D-Bus? Or is it only
kde and gnome?

Thanks for being a sounding board guys.

_______________________________________________
freebsd-questionsfreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-que
stions
To unsubscribe, send any mail to
"freebsd-questions-unsubscribefreebsd.org"