Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm trying to take advantage of the "group" option for fstab entries and not having any success. From the mount man page:

Normally, only the superuser can mount filesystems. However, when fstab contains the user option on a line, anybody can mount the corresponding system. ... If any user should be able to unmount, then use users instead of user in the fstab line. The owner option is similar to the user option, with the restriction that the user must be the owner of the special file. This may be useful e.g. for /dev/fd if a login script makes the console user owner of this device. The group option is similar, with the restriction that the user must be member of the group of the special file.

I'm testing with a loopback mount using a 1GB file /blergh with an ext4 filesystem on it. That file is owned by root:disk with permissions 664. I have a mount point /media/blergh owned by root:disk with permissions 775. I have an fstab entry like so:

/blergh /media/blergh ext4 loop,rw,noauto,group 0 2

Running mount /media/blergh as root works fine. Running it as myuser gives the error: mount: only root can mount /blergh on /media/blergh. The output of /usr/bin/groups as myuser is myuser disk so the group membership is there. If I change group to user in the options, myuser can mount the filesystem.

What am I doing wrong? Why isn't the group option working?

(Note: for reasons I don't want to get into here, I do not want to solve the problem of enabling myuser to mount this filesystem by using sudo.)


Edit 20-MAY-2013:

Additional testing with a real block device suggests the problem lies with loop rather than group. I created a new 1GB EBS volume attached as /dev/sdg, owned by root:disk, permissions 664. I created this fstab entry for it:

/dev/sdg /media/sdg ext4 rw,noauto,group 0 0

Same as before, just no loop since it does not apply here. I created a mount point for this filesystem at /media/blerg, owned by root:disk, permissions 775. As before myuser is a member of the disk group. Using this test setup mount /media/sdg as myuser works fine, as does umount /media/sdg.

share|improve this question
    
Are you sure you are in the group? If you run groups myuser it will display the groups myuser is a member of from the groups file. If you run groups (no argument) as myuser it will show the current groups the process has. If these differ, you will need to log out and in again to get the new groups applied (or use newgrp(1)) –  camh Apr 17 '13 at 23:32
    
The group membership is absolutely there. I edited it into /etc/group myself, and the groups command confirms it. –  Noah Yetter Apr 18 '13 at 4:05

2 Answers 2

I have a similar problem with the option user. Not solved yet. My approach to solving is to create variants of the situation to see whether they work, and possibly make something emerge.

Is your problem only with that one file /blergh ? Can you reproduce it with another file ? Or with that file located somewhere else, or with different permissions, or with different ownership. (of course, testing depends on how much control you have over the system).

Can you test the problem with the option owner to see whether it works ... assuming you can reproduce it on another file, or change temporarily ownership ? What about option user.

Is your problem for both mounting and umounting, or for only one of them ? If mounting does not work, you could attempt mounting as root and umounting as myuser. (in the case of my own problem, mounting works, but umounting does not)

Side note: I believe this kind of mount is called "loop" in the Linux world, "loopback" having to do with networking devices.(ref. http://en.wikipedia.org/wiki/Loop_device)

Added after the first comment and the question editing

If owner does not work either, that means that all ownership mecanisms are affected, since owner is easier to check than group. Is it the case that owner works for real block devices, like group does ?

Have you tried specifying explicitly the loop device in the loop option, choosing one that is not used : ...,loop=/dev/loop7,... ? You might even try to change the ownership or group of the loop device (though I am not sure how wise or useful it can be). ls /dev/loop* gives the available loop devices.

Another possibility is to remove the option loop altogether from your /etc/fstab entry. On many systems it is no longer needed, and is done implicitly by mount. What system are you using, btw ?

share|improve this answer
    
With my loopback test, user works perfectly, but owner does not work at all. What I did find though is that my problem with group seems confined to loop and does not manifest with real block devices. I will edit my question with further details. –  Noah Yetter May 20 '13 at 19:22
    
@Noah Yetter -- did you try my last suggestions added above ? Did you find a solution ? By the way: I have the soloution to my problem with option user but I do not believe it would help you. –  babou May 23 '13 at 7:30

I think you are missing a very important detail here. From the man page as quoted (and emphasized) by you:

The group option is similar, with the restriction that the user must be member of the group of the special file.

Note my emphasis on "special file". If you refer to the following explanation about group option:

group Allow an ordinary (i.e., non-root) user to mount the filesystem if one of his groups matches the group of the device. This option implies the options nosuid and nodev (unless overridden by subsequent options, as in the option line group,dev,suid).

This means that the device or special file that you are trying to mount as myuser should have the same group ownership as that of user myuser.

Here's an example:

Let's assume there's a device /dev/sda5 on a system, which is mounted on /builds directory:

# ls -l /dev/sda5
brw-rw---- 1 root disk 8, 5 Jun 15 21:20 /dev/sda5
# grep sda5 /etc/fstab
/dev/sda5       /builds reiserfs        group,defaults 1 2

Also, there are 2 users on this same system: foo and srinidhi

# id foo
uid=1005(foo) gid=100(users) groups=100(users),33(video)
# id srinidhi
uid=1000(srinidhi) gid=100(users) groups=100(users),16(dialout),6(disk),10(wheel)

User srinidhi (who is part of group disk) tries to mount /builds:

srinidhi@linux:~> mount /builds/
srinidhi@linux:~> echo $?
0

Now, let's see what happens when foo tries to mount /builds:

srinidhi@linux:~> su - foo
foo@linux:~> mount /builds/
mount: only root can mount /dev/sda5 on /builds
foo@linux:~>

Since foo is not part of disk group, mount fails.

Coming back to your case, you should make sure that group ownership of /blergh should either be myuser or disk. Simply set the correct group ownership and your original /etc/fstab entry should start working:

# chgrp myuser /blergh

Now try running mount /media/blergh as myuser.

Note: Ownership of mount point (here /media/blergh) does not affect mount.

share|improve this answer
    
I did not miss that. The user attempting to mount is a member of the "disk" group, which is the owning group of the file. Further, as I stated in my edit, it appears that the fstab "group" functionality only works for special files and not loop mounts. –  Noah Yetter Jul 30 '13 at 16:18
    
Sorry, I missed the part where you mentioned ownership and permissions of /blergh. So I did some digging inside sources of util-linux and if I'm reading the sources right, then the "owner" and "group" matches aren't done if the file doesn't start with /dev/. So if you first run losetup loop0 /blergh and then use /dev/loop0 /blergh.. in /etc/fstab, everything works as you would expect. –  Srinidhi Jul 30 '13 at 20:39

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.