A very lightweight volume manager

scire · 2009-12-10 18:38:54

Just compiled kernel-2.6.32, and was wondering why my stuff was automounting all of a sudden...
after about 20 minutes of looking through hal's automount rules, autofs, and everything else I had tried but didn't work, I realized that I had skvm daemonized! skvm -d confirmed that it's working like a charm!

Thanks for a such a great tool, I've been wanting something like this for a loong time!

scire · 2010-01-05 16:58:06

Sorry for the double post, but I've got a quick question here.
Using skvm-hg, latest release.
(NOTE: Skip to bottom of post for condensed version)

My drives aren't always mounting to the correct directory, and it seems to depend on what order I plug them in.
I have one drive labeled "Green" and one drive labeled "MARC", they are also of different formats (ext and vfat, respectively). For some strange reason, if I plug in my Green drive before MARC, it gets mounted at /media/MARC, and then when I plug in MARC, it gets mounted at /media/Green. I'm not sure why this might be happening, but my thoughts are that it is due to the fact that skvm adds fstab entries by device name (/dev/sdb1, etc). Is there any way that I can have fstab entries added by UUID instead?

(A side remark/half-question/alternative: Looking through the code, it looks like skvm looks in fstab for the entries by UUID to see if they exist first. I had them in my fstab before, however they were still being readded to fstab by fsname (ie. /dev/sdb1). Is it supposed to be mounting based on what already exists in fstab, or simply following the rules set in skvm.c?)

Thanks very much!

Edit: I have just tried adding UUIDs to my fstab, and now they seem to be mounting properly. My fstab entry is:

UUID=e10d5053_11e0_43ed_8166_0e5ae0cbc760 /media/Green ext2 rw,noatime,noexec,nosuid,nodev,users  0  0

Now I am getting the following error when I try umount as user:

umount: /media/Green mount disagrees with fstab

Edit #2: SKVM is detecting the UUID entry in fstab, so it is not adding its own entry, however it is still adding the mountpoint to mtab using the fsname, when it should be added using the UUID in order to have identical entries in both fstab and mtab. Looking at the source for skvm, it doesn't seem like there is a simple way to do this, though I am in no way an advanced coder. Any way to fix this?

Condensed version:
1. skvm was mounting the wrong things to the wrong places due to not removing fstab entries, caused since /dev/sdx is not necessarily going to be the same drive as it was before.
(eg. fstab entry is created for "/media/MARC" at /dev/sdb1, then when unmounted, that entry was not removed, and then plugging in a different usb drive, it becomes /dev/sdb1 and is then mounted under /media/MARC despite it's own label.
2. I added entries to my fstab by UUID. These are being detected, and are mounting in the proper places.
3. Though they are being mounted properly by UUID, they are still being added to /etc/mtab under their fsname (/dev/sdx), and not by UUID.
4. Is there any way to either fix this UUID problem (which seems a bit difficult through skvm.c and my limited coding abilities? OR, is there any way to *ensure* then when I call umount, it will be removed from fstab? OR, is there another solution?

Thanks again, and sorry for what has become an extremely loopy message.

Last edited by scire (2010-01-05 18:01:11)

JezdziecBezNicka · 2010-01-07 19:27:32

Does anyone else feel skvm is worth mentioning on the wiki?

el mariachi · 2010-01-14 22:28:11

skvm is mounting my usb pendrives correctly but without write permission. How can I change that?

Last edited by el mariachi (2010-01-14 22:29:14)

ninian · 2010-01-14 23:00:50

el mariachi wrote:

skvm is mounting my usb pendrives correctly but without write permission. How can I change that?

Sounds the same problem as I had - see http://bbs.archlinux.org/viewtopic.php? … 62#p655562

bolgimo · 2010-01-24 06:55:05

I can't get code working to apply different mount options depending on the fstype; i'm trying to achieve the following:

1. someone connects a storage device to the media server
2. device is mounted with permissions 775 root:storage, which gives users in the storage group rw access, but everyone else has read-only.

this gives me the functionality of human users allowed to write to the disk either on the machine, or through sshfs or smb, but remote media playing devices and other sub-sentient users that read /media remotely are limited to read only.

when manually mounting the disks i have used fs-independent options to achieve this; but these options cause skvm to segfault when attempting to mount fstype with an unsupported option; eg:-

- ext2/3/4 disks: uses device permissions
- ntfs disks: gid=storage,umask=002;
- fat/vfat: gid=storage,umask=002;
- usbfs: devgid=storage,devmod=664;

i've been trying to modify skvm with no success:

#define DEFAULT_MNT_OPTIONS "nosuid,nodev,users"
#define NTFS_MNT_OPTIONS ",gid=storage,umask=002"
#define VFAT_MNT_OPTIONS ",gid=storage,umask=002"
#define USBFS_MNT_OPTIONS ",devgid=storage,devmod=664"

if (device->fstype == "ntfs")
    device->opt = strcat (DEFAULT_MNT_OPTIONS, NTFS_MNT_OPTIONS);
if (device->fstype == "vfat" || device->fstype == "fat")
    device->opt = strcat (DEFAULT_MNT_OPTIONS, VFAT_MNT_OPTIONS);
if (device->fstype == "usbfs")
    device->opt = strcat (DEFAULT_MNT_OPTIONS, USBFS_MNT_OPTIONS);

would it be possible for someone to patch skvm to read config in from /etc/skvm.rc in such a way that it would accept per fstype mount options; ie

#
# skvm.rc fstype mount options file
#
default noexec,nosuid,nodev

# fstype options
ntfs    ,gid=storage,umask=002
fat     ,gid=storage,umask=002
vfat    ,gid=storage,umask=002
usbfs   ,devgid=storage,devmod=664

or should i not be trying to modify skvm for this purpose and changing something else such as udev or hal or policykit?

Last edited by bolgimo (2010-01-24 07:36:12)

orschiro · 2010-01-27 07:30:04

Hello guys,

I have some essential question in order to use skvm the right way.

1) I changed the skvm.c to have user access and rebuilded it with makepkg -fi. This is my line:

#define DEFAULT_MNT_OPTIONS "noexec,nosuid,nodev,users,rw,sync"

But I still have no user write access. Why that?

2) How does unmounting work? Can I simply disconnect my usb/removable device or cd/dvd or do I have to manually unmount it? Even though there was write access onto the device? Or is it enough that I added the sync option in skvm.c?

Now I just use the sync command before I eject the stick.

3) Is it possible to mount luks-encrypted removable usb devices?

For that I'm using a udev rule. It's nice how smoothly skvm integrates with udev.

4) I tried skvm with a cd. It is shown up in /media and I can access it but I can't eject it until I manually unmount it. Can this be automated?

Just do the following steps:

rmmod sr_mod
rmmod cdrom
modprobe cdrom lockdoor=0
modprobe sr_mod

5) Can I use skvm beside udev that udev is managing removable devices and skvm just my cd/dvdrom-device?

That's working flawlessly.

Last edited by orschiro (2010-02-01 18:16:04)

Runiq · 2010-02-14 13:12:57

bolgimo wrote:

(…) I've been trying to modify skvm with no success:

#define DEFAULT_MNT_OPTIONS "nosuid,nodev,users"
#define NTFS_MNT_OPTIONS ",gid=storage,umask=002"
#define VFAT_MNT_OPTIONS ",gid=storage,umask=002"
#define USBFS_MNT_OPTIONS ",devgid=storage,devmod=664"

if (device->fstype == "ntfs")
    device->opt = strcat (DEFAULT_MNT_OPTIONS, NTFS_MNT_OPTIONS);
if (device->fstype == "vfat" || device->fstype == "fat")
    device->opt = strcat (DEFAULT_MNT_OPTIONS, VFAT_MNT_OPTIONS);
if (device->fstype == "usbfs")
    device->opt = strcat (DEFAULT_MNT_OPTIONS, USBFS_MNT_OPTIONS);

What error did you get? I'd like to do this myself, but I'm nowhere near as fluent in C as you as it seems.

bolgimo wrote:

would it be possible for someone to patch skvm to read config in from /etc/skvm.rc in such a way that it would accept per fstype mount options; ie
#
# skvm.rc fstype mount options file
#
default noexec,nosuid,nodev

# fstype options
ntfs    ,gid=storage,umask=002
fat     ,gid=storage,umask=002
vfat    ,gid=storage,umask=002
usbfs   ,devgid=storage,devmod=664
or should i not be trying to modify skvm for this purpose and changing something else such as udev or hal or policykit?

I think the configure options should stay in the source for now, one thing after another. And no, I think skvm is the right place to apply these changes, because it does all the mounting after all.

dauerbaustelle · 2010-03-15 23:12:12

Here: http://github.com/jonashaag/skvm-pmount you can find a fork of skvm that uses pmount. Should be ran as non-root, I guess.

Works great for me! :-)

Runiq · 2010-03-16 12:04:44

Thanks for the link, I'm gonna look into it.

Runiq · 2010-03-28 12:21:38

Would it be possible to use either labels or UUIDs (in that order) in the fstab entries instead of /dev/sd*?

I regularly leave my external drives plugged in when I shut down, so the fstab entry doesn't get removed on booting back up. When I realize that I didn't unplug the drive, tuck it out and later plug in a new one, the first drive's fstab entry wasn't removed, and since the new drive is e.g. /dev/sdb1, it gets mounted under the same directory as the drive before it.

dimigon · 2010-03-28 18:50:02

Yes you can use both labels and UUIDs, but it is not skvm's job to automount stuff on boot. Skvm should be removing its mounted fstab entries when it receives a SIGTERM.

Last edited by dimigon (2010-03-28 18:51:16)

Runiq · 2010-03-28 19:24:13

I don't want to automount on boot, so that's no problem. The problem would be that skvm doesn't really remove its fstab entries before shutdown. It does remove them when I unplug the stick normally, though (before a reboot).

Say I plug in a USB pendrive. Skvm mounts it and creates an fstab entry for "/dev/sdb1", even though the pendrive is labeled. I unmount it and restart the computer without unplugging the pendrive. After booting, I unplug the pendrive – the fstab entry that was created by skvm before the reboot wasn't deleted before shutdown. I plug in a second pendrive, which gets assigned to /dev/sdb1 as well. Since the fstab entry from the first pendrive is still present, skvm mounts the new drive under the mountpoint of the first one.

dimigon · 2010-03-28 20:02:43

Hi,

Are you on a x86-64 system? Make sure your system is up to date. Skvm should have mounted your drive using its label by default. Skvm should have removed all /etc/fstab entries upon system shutdown. There was an issue with x86-64 systems (possibly something to do with HAL/DBUS) that in consequence prevented skvm from removing the mounted devices from /etc/fstab.

You do not generally have to unmount the device manually if you are about to reboot. I'll do some testing myself.

*UPDATE*
I did exactly the same thing and skvm removed the /etc/fstab entries as expected. (NOTE: I am on a x86-64 system).

Last edited by dimigon (2010-03-28 20:11:31)

tomk · 2010-03-28 21:16:13

Apologies for asking this - it's probably somewhere in the thread, but it is a long thread - but why is skvm adding/removing stuff in /etc/fstab? fstab is static, and is meant to be created/amended by the user only.

man fstab wrote:

The file fstab contains descriptive information about the various file
systems. fstab is only read by programs, and not written; it is the duty
of the system administrator to properly create and maintain this file.

man fstab

dimigon · 2010-03-29 01:50:08

Yea, that is right, fstab should only be modified by the system administrator.

Nevertheless at the time I wanted to be able to unmount volumes without being root and I did not want to use pmount for that. It is a bit hackish I agree. Basically, using pmount or gnome-mount should be enough to avoid touching the fstab file. I've also had a version of skvm that did everything using HAL requests, however it felt as if libhal was not very stable or well documented and I dropped it.

As far as I know there is a fork of skvm that uses pmount for everything. I don't know however if it still modifies the fstab file.

Last edited by dimigon (2010-03-29 01:55:31)

dauerbaustelle · 2010-03-29 14:47:01

It doesn't. this is the only modification done to the original skvm code.

I'm having problems using that with my Android phone, however. It seems like skvm doesn't recognize the phone correctly, maybe because the mass storage thing is activated *after* plug-in (manually by the user).

dimigon · 2010-03-29 18:40:05

Hey,

I have not done any testing on the Android. If you can narrow it down to the problem and come up with a fix, I'd be more than happy to accept a patch.

Last edited by dimigon (2010-03-29 18:41:41)

dauerbaustelle · 2010-03-29 22:49:05

Hm, I think I was wrong, skvm seems to work with my Android phone. Unmounting does not work perfectly because you can unmount your phone without pulling the USB cable (via Android menu). I think this is easily fixed listening to another event ("unmount" rather than "unplug"). If I can help you regarding an implementation for that, just tell me. :-)

Furthermore I wonder how I can modify the /media/$label that skvm choses without modifying the partition label (which is, at least for Windows file systems, impossible without losing data). I see that this has something to do with hal, but exactly how do I configure it? :-)

skottish · 2010-03-31 02:00:48

dimigon wrote:

As far as I know there is a fork of skvm that uses pmount for everything. I don't know however if it still modifies the fstab file.

I haven't looked at the code, but it looks like the fork doesn't touch fstab anymore:

http://github.com/jonashaag/skvm-pmount

dimigon · 2010-05-12 11:22:04

Hey all,

I can confirm that skvm can mount devices at boot time on x86(have not tested x86-64 yet). I've not touched a single line of code, it must have been something when I upgraded my arch system (either dbus or hal or whatever).

Last edited by dimigon (2010-05-12 11:22:42)

orschiro · 2010-05-23 07:43:46

Hello dimigon,

is there also a hal independent version of skvm possible since hal is more or less deprecated?

Regards

dcc24 · 2010-05-23 11:41:51

orschiro wrote:

Hello dimigon,
is there also a hal independent version of skvm possible since hal is more or less deprecated?
Regards

I just discovered this thread (yeah, I know) and I'd like a hal-independent version as well. Is this a work-in-progress or out of question atm?

gladstone · 2010-05-23 11:43:48

You should check out Udev rules

orschiro · 2010-05-23 13:25:09

Udev currently only works for usb devices but not for internal dvd drives.

Hence my question.

Arch Linux

#101 2009-12-10 18:38:54

Re: A very lightweight volume manager

#102 2010-01-05 16:58:06

Re: A very lightweight volume manager

#103 2010-01-07 19:27:32

Re: A very lightweight volume manager

#104 2010-01-14 22:28:11

Re: A very lightweight volume manager

#105 2010-01-14 23:00:50

Re: A very lightweight volume manager

#106 2010-01-24 06:55:05

Re: A very lightweight volume manager

#107 2010-01-27 07:30:04

Re: A very lightweight volume manager

#108 2010-02-14 13:12:57

Re: A very lightweight volume manager

#109 2010-03-15 23:12:12

Re: A very lightweight volume manager

#110 2010-03-16 12:04:44

Re: A very lightweight volume manager

#111 2010-03-28 12:21:38

Re: A very lightweight volume manager

#112 2010-03-28 18:50:02

Re: A very lightweight volume manager

#113 2010-03-28 19:24:13

Re: A very lightweight volume manager

#114 2010-03-28 20:02:43

Re: A very lightweight volume manager

#115 2010-03-28 21:16:13

Re: A very lightweight volume manager

#116 2010-03-29 01:50:08

Re: A very lightweight volume manager

#117 2010-03-29 14:47:01

Re: A very lightweight volume manager

#118 2010-03-29 18:40:05

Re: A very lightweight volume manager

#119 2010-03-29 22:49:05

Re: A very lightweight volume manager

#120 2010-03-31 02:00:48

Re: A very lightweight volume manager

#121 2010-05-12 11:22:04

Re: A very lightweight volume manager

#122 2010-05-23 07:43:46

Re: A very lightweight volume manager

#123 2010-05-23 11:41:51

Re: A very lightweight volume manager

#124 2010-05-23 11:43:48

Re: A very lightweight volume manager

#125 2010-05-23 13:25:09

Re: A very lightweight volume manager

Board footer