I want to be able to run the following script as normal user (as root it runs fine):


dd if=/dev/zero bs=8192 count=128 of=disk.img
mkfs -t ext2 -F disk.img
losetup /dev/loop0 disk.img
mount /dev/loop0
echo aaaa > /mnt/aa
umount /mnt
losetup -d /dev/loop0

To that end, I

1) added appropriate entry to /etc/fstab (only then normal user can run 'mount /dev/loop0' ):

/dev/loop0  /mnt  ext2    defaults,loop,users,noauto      0 0

2) added the user in question to the 'disk' group (only then the user is able to run 'losetup' - /dev/loop0 is owned by the 'disk' group)

Now, hopefully the last problem is that when I run as normal user, I get 'permission denied' error from 'echo'. No wonder, because after mounting, the permissions of the /mnt directory change to 755 root:root, and obviously a normal user cannot create files inside.

How should I create my 'disk.img' so that when mounted it is writeable by the very user that created it?


The proposed 'pmount' solution appears to have the same problem. Reproduction steps:

1) install 'pmount' and add '/dev/loop0' to /etc/pmount.allow

2) run the following as a normal user:


dd if=/dev/zero bs=8192 count=128 of=disk.img
mkfs -t ext2 -F disk.img
losetup /dev/loop0 disk.img
pmount -w /dev/loop0
echo aaaa > /media/loop0/aa
pumount /media/loop0
losetup -d /dev/loop0

You will still get 'permission denied' from echo for the same reason we got it before - the permissions of the /media/loop0/ directory are 755:

[user@server test]$ ls -l /media/
total 1
drwxr-xr-x 3 root root 1024 Jul 22 13:40 loop0
[user@server test]$ ls -l /media/loop0/
total 12
drwx------ 2 root root 12288 Jul 22 13:40 lost+found


I managed to solve this - option 'root_owner' to mkfs.ext3 comes in handy:



uid=$(id -u $WHOAMI)
gid=$(id -g $WHOAMI)

dd if=/dev/zero bs=8192 count=128 of=disk.img
mkfs.ext3 -E root_owner=$uid:$gid disk.img
losetup /dev/loop0 disk.img
mount /dev/loop0
echo aaaa > /mnt/aa
umount /mnt
losetup -d /dev/loop0

Then after mounting the mountpoint is owned by the user who is running the script, and then the user is able to write inside :)

  • 1
    Regarding 2: by adding users to disk group those users can read private data straight from /dev/sda1. – Rinzwind Jul 22 '16 at 11:55
  • Good point; this shouldn't be too much of a problem , because the script will only be run from a Web-based frontend (and the server is in our intranet), and never by actual logged-in users, but maybe you'd have some suggestion how to tighten this up? – Leszek Jul 22 '16 at 12:03
  • Ok. It was just a fair warning. Never know who ends up reading your question and go "oh that is useful" ;-) 1 thing that might be something: you could probably do this in a chroot too. Then you'd have "root" active inside that chroot and wont be bothered with permissions too. – Rinzwind Jul 22 '16 at 12:05

Use pmount instead of mount.

pmount ("policy mount") is a wrapper around the standard mount program which permits normal users to mount removable devices without a matching /etc/fstab entry.

Probably want the ...

-w, --read-write

Force the device to be mounted read/write. If neither -r nor -w is specified, the kernel will choose an appropriate default.

So you can drop the fstab entry and do not need to add the user to the disk group.

It allows mounting anywhere under /media/ if the device is listed in /etc/pmount.allow so it will also solve any permissions problems.

  • One more question actually - see below... – Leszek Jul 22 '16 at 12:23
  • This unfortunately does not seem to work - the same problem as before - see Edit... – Leszek Jul 22 '16 at 12:57

Rinzwind: my stripped-down script I posted in the question above doesn't show it, but there's a problem with the 'pmount' solution.

The problem is that it only appears to be able to mount to /media.

The full script is more complicated: it creates a 500MB large image file (image of a USB pendrive), partitions it into 2 partitions (FAT32 and Ext3) , mounts both to TMPFS (/tmp/loop0p1 and /tmp/loop0p2) and writes a loooot of data inside.

It is important to be able to mount to TMPFS so that this operation is fast - in my experience, doing it inside TMPFS makes this more than 10 times faster than doing it in actual block device in a HD.

/media is not TMPFS...

  • You could make /media tmpfs (not sure if that will mess with other things though :D ). Please don't use answers for questions; edit your question to add more info to it ;) – Rinzwind Jul 22 '16 at 12:25
  • Yes, I could... This server is not used for anything else than producing those USB images from a Web-frontend, so I guess /media will never be used by anything but my script. – Leszek Jul 22 '16 at 12:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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