Re: removable devices auto umounting
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.SystemPowerManagement/ allow send_interface=org.freedesktop.Hal.Device.LaptopPanel/ allow send_interface=org.freedesktop.Hal.Device.Volume/ allow send_interface=org.freedesktop.Hal.Device.Volume.Crypto/ /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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removable devices auto umounting
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.SystemPowerManagement/ allow send_interface=org.freedesktop.Hal.Device.LaptopPanel/ allow send_interface=org.freedesktop.Hal.Device.Volume/ allow send_interface=org.freedesktop.Hal.Device.Volume.Crypto/ /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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removable devices auto umounting
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/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpsjJgfM71mK.pgp Description: PGP signature
Re: removable devices auto umounting
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, Roland Smith [EMAIL PROTECTED] 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/~rsmith/ [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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removable devices auto umounting
On Thu, 2008-03-20 at 08:43 +0100, Roland Smith 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removable devices auto umounting
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/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpKtgnbd7OYY.pgp Description: PGP signature
Re: removable devices auto umounting
On Thu, 2008-03-20 at 14:14 +0100, Roland Smith 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: removable devices auto umounting
Am Fri, 21 Mar 2008 09:40:39 +1000 schrieb Da Rock [EMAIL PROTECTED]: 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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
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-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Properly umounting a USB HDD
Hey all, I've noticed that a 'umount /mnt/portable' properly umounts the drive like it should, but when I hold the drive in my hand and give it a very gentle horizontal spin with my wrist, the reading head / platter.. something, sounds loose, as if the arm wasn't properly docked. Is there any command in BSD that will allow me to properly shutdown a portable disk? System disks don't have this sound at all but I'm not sure what commands do it. Maybe it's a APIC/APM thing? That stuff is greek to me. Thanks! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
umounting /
Is this the only way to unmount the root filesystem: umount -a When I try umount /, I get this error: umount: unmount of / failed: Invalid argument The manpage doesn't give any hints on why that argument is invalid... Dru ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umounting /
Is this the only way to unmount the root filesystem: umount -a When I try umount /, I get this error: umount: unmount of / failed: Invalid argument The manpage doesn't give any hints on why that argument is invalid... You can't un mount root. You can only reassert the mount. jerry Dru ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umounting /
On Thu, 11 Dec 2003, [EMAIL PROTECTED] wrote: Is this the only way to unmount the root filesystem: umount -a When I try umount /, I get this error: umount: unmount of / failed: Invalid argument The manpage doesn't give any hints on why that argument is invalid... From the unmount(2) man page: ... The unmount() function may fail with one of the following errors: ... [EINVAL] The requested directory is not in the mount table. Without reading kernel source I can only speculate that the man page is correct and the root file system is not in the kernel mount table. This is plausible if not actually expected since the root file system is not actually mounted on anything. Even if it were in the kernel mount table, you couldn't unmount it because it would always be busy. If there were any other mounted file systems, at least one of them would have to be mounted on the root and that would make the root busy. If there were no other mounted file systems, then the current working directory of every active process (including the one issuing the unmount() system call) would have to be somewhere in the root and that would make the root busy. You can't unmount the root file system. Even the mere notion makes me feel a little queasy. I have to give you big points for originality. :-) (Why did you *want* to unmount the root? To fsck it or dump it?) Dan Strick [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umounting /
On Thu, Dec 11, 2003 at 11:55:22AM -0800, Dan Strick wrote: (Why did you *want* to unmount the root? To fsck it or dump it?) Forcing it to be remounted read-only may help in such cases. wopr:~# mount -u -o ro -f / wopr:~# mount /dev/da0s1a on / (ufs, local, read-only) /dev/da0s1f on /home (ufs, local, soft-updates) /dev/da0s1e on /usr (ufs, local, soft-updates) mfs:20 on /tmp (mfs, asynchronous, local, nosuid) procfs on /proc (procfs, local) -- Matthew Hunt [EMAIL PROTECTED] * Salvage, like other forms of virtue, is http://www.pobox.com/~mph/ * its own reward. -George Reamerstaff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: umounting /
In message [EMAIL PROTECTED], Dan Strick writes: You can't unmount the root file system. Even the mere notion makes me feel a little queasy. There is an explicit test in the kernel that stops you from unmounting the root file system, I guess as an anti foot shooting measure. If you disable that test then forcibly unmounting / works fine, but normally init will promptly die because the vnode containing its executable has disappeared. The only case I've come across where the ability to unmount / would be useful is for some kind of rescue or install CD that starts off as the root filesystem but wants to switch over to the real root fs allowing the CD to be removed. I've got this to work before by changing init so that it re-execs itself upon receipt of a special signal. Then you can mount the new root directly over /, send the signal to init, and finally forcibly unmount the underlying /. There are some necessary bits for this that are only in 5.x, such as the ability to unmount by filesystem ID rather than by path. Ian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
