No permission to access files on storage device Ubuntu 12.04 does not allow me to access Floppy Drive

Created attachment 78381
output of 'udisksctl dump'

When I try to mount a floppy disk (formatted with FAT12) in the internal floppy drive using "udisksctl mount -b /dev/fd0" it gets mounted as root instead of the logged in user. As a consequence I don't have write access.

wolfi@amiga:~> udisksctl mount -b /dev/fd0
Mounted /dev/fd0 at /run/media/wolfi/disk.
wolfi@amiga:~> ls -la /run/media/wolfi/disk
insgesamt 86
drwxr-xr-x 2 root root 3584 1. Jän 1970 .
drwxr-x---+ 3 root root 60 23. Apr 18:07 ..
-rwxr-xr-x 1 root root 83968 16. Okt 2001 slides1.ppt

On the other hand, when I try to mount an USB stick (formatted with FAT32) it does get mounted as the logged in user.

wolfi@amiga:~> udisksctl mount -b /dev/sdc1
Mounted /dev/sdc1 at /run/media/wolfi/Transcend.
wolfi@amiga:~> ls -la /run/media/wolfi/Transcend
insgesamt 16
drwx------ 3 wolfi users 8192 1. Jän 1970 .
drwxr-x---+ 4 root root 80 23. Apr 18:08 ..
drwx------ 18 wolfi users 8192 27. Jän 23:45 Instrumentelle Analytische Chemie Protokolle

I would expect that the floppy disk is also mounted as the logged in user.

The same behaviour occurs with udisks-2.0.0 as shipped with openSUSE 12.3 and a self-compiled udisk-2.1.0.
I also tried an Ubuntu 13.04 LiveCD with the same result, so it's not openSUSE specific.

wolfi@amiga:~> cat /etc/fstab
/dev/sdb2 swap swap defaults 0 0
/dev/sda1 / reiserfs acl,user_xattr 1 1
proc /proc proc defaults 0 0
sysfs /sys sysfs noauto 0 0
debugfs /sys/kernel/debug debugfs noauto 0 0
usbfs /proc/bus/usb usbfs auto,busgid=110,busmode=0775,devgid=110,devmode=0664 0 0
devpts /dev/pts devpts mode=0620,gid=5 0 0
/dev/sdb1 /windows/C ntfs-3g defaults 0 0

wolfi@amiga:~> rpm -q udisks2 gvfs libatasmart4
udisks2-2.0.0-5.4.1.x86_64
gvfs-1.14.2-2.1.2.x86_64
libatasmart4-0.19-2.1.1.x86_64

Created attachment 78382
output of 'udevadm info --export-db' (as root)

Created attachment 78383
output of 'cat /proc/self/mountinfo'

I just noticed that the floppy _is_ mounted as user when I specify the filesystem type with the -t option:

wolfi@amiga:~> udisksctl mount -b /dev/fd0 -t vfat
Mounted /dev/fd0 at /run/media/wolfi/disk.
wolfi@amiga:~> ls -la /run/media/wolfi/disk
insgesamt 86
drwx------ 2 wolfi users 3584 1. Jän 1970 .
drwxr-x---+ 3 root root 60 24. Apr 20:05 ..
-rw-r--r-- 1 wolfi users 83968 16. Okt 2001 slides1.ppt

So the issue seems to be that udisks doesn't correctly identify the filesystem type.

(In reply to comment #3)
> I just noticed that the floppy _is_ mounted as user when I specify the
> filesystem type with the -t option:
>
> wolfi@amiga:~> udisksctl mount -b /dev/fd0 -t vfat
> Mounted /dev/fd0 at /run/media/wolfi/disk.
> wolfi@amiga:~> ls -la /run/media/wolfi/disk
> insgesamt 86
> drwx------ 2 wolfi users 3584 1. Jän 1970 .
> drwxr-x---+ 3 root root 60 24. Apr 20:05 ..
> -rw-r--r-- 1 wolfi users 83968 16. Okt 2001 slides1.ppt
>
> So the issue seems to be that udisks doesn't correctly identify the
> filesystem type.

Well, we can't identify it ahead of time as it would create a lot of noise and there's no way to check if a new medium has been inserted. We should probably special-case /dev/fd* and always just assume that it's vfat...

(In reply to comment #4)
>
> Well, we can't identify it ahead of time as it would create a lot of noise
> and there's no way to check if a new medium has been inserted.

Aha. Thanks for the explanation, makes sense.

> We should probably special-case /dev/fd* and always just assume that it's vfat...

Yes, I think that would be the best thing to do.

As it is now, you can't really use the floppy drive in graphical environments like KDE and GNOME, although they do have a nice floppy icon in their filemanagers...

I'm having this exact same problem but with an ext4 partitioned disk. Ext4 partitions are just used on internal disks, they can be used on external ones too. But when this happens, this is the mounts I get:
/dev/sdc1 on /run/media/r3pek/6ef9a3f5-26fc-41eb-baa8-1f344b419725 type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)
/dev/sdd1 on /run/media/r3pek/7E11-ECF4 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,

sdc is an external ext4 formated 1TB HD
sdd is a 1GB pen drive

both were user-mounted via udisks2 but it happens that the user can't create anything under sdc1's mount point, but it can on sdd1's. And this is why:
$ ls -lh /run/media/r3pek/
total 8.0K
drwxr-xr-x 4 root root 4.0K Jul 3 17:55 6ef9a3f5-26fc-41eb-baa8-1f344b419725
drwx------ 7 r3pek users 4.0K Dec 31 1969 7E11-ECF4

Permissions should be enforced when creating the mountpoint, so that the owner of that directory is the user who requested the mount. Of course this should only be done for removable harddrives to prevent the user to mount the local filesystem and change anything in it.

(In reply to comment #4)
> (In reply to comment #3)
> > I just noticed that the floppy _is_ mounted as user when I specify the
> > filesystem type with the -t option:
> >
> > wolfi@amiga:~> udisksctl mount -b /dev/fd0 -t vfat
> > Mounted /dev/fd0 at /run/media/wolfi/disk.
> > wolfi@amiga:~> ls -la /run/media/wolfi/disk
> > insgesamt 86
> > drwx------ 2 wolfi users 3584 1. Jän 1970 .
> > drwxr-x---+ 3 root root 60 24. Apr 20:05 ..
> > -rw-r--r-- 1 wolfi users 83968 16. Okt 2001 slides1.ppt
> >
> > So the issue seems to be that udisks doesn't correctly identify the
> > filesystem type.
>
> Well, we can't identify it ahead of time as it would create a lot of noise
> and there's no way to check if a new medium has been inserted. We should
> probably special-case /dev/fd* and always just assume that it's vfat...

What about trying to identify it, directly before the mount? Or is that what you meant anyway?

Created attachment 90559
Patch to try to mount filesystems as calling user first.

This seems to be a regression, where udisks wouldn't try to mount filesystems as the calling user first. This can be tested with any entry with the user keyword and a fat filesystem. In my case an usb dongle.

UUID=10B3-837F /media/cruzer vfat rw,nosuid,nodev,relatime,user,showexec,utf8,errors=remount-ro 0 0

Mounting the device with udisks results in the filesystem mounted as root.

I've attached a patch to fix the problem. Please review.

Hello David.
This patch works only with this entry in /etc/fstab

/dev/fd0 /media/floppy0 auto rw,user,noauto 0 0

this is a partial fix of a problem, as for usb floppy drives it is necessary to add record in fstab that is inconvenient for users.

Created attachment 99930
[PATCH 1/2] Introduce new build dependency on libblkid

Created attachment 99931
[PATCH 2/2] Probe media that hasn't been probed by udev yet.

(In reply to comment #9)
> Hello David.
> This patch works only with this entry in /etc/fstab
>
> /dev/fd0 /media/floppy0 auto rw,user,noauto 0 0
>
> this is a partial fix of a problem, as for usb floppy drives it is necessary
> to add record in fstab that is inconvenient for users.

Alright, I've added two patches to use libblkid to probe for the filesystem prior to mounting it. These are supposed to be used in addition to the one before.

Please review.

Thanks,
David

Created attachment 99941
[PATCH 2/2] Probe media that hasn't been probed by udev yet.

Sorry, forgot to rework error handling in the second patch before submitting.

Here's the correct version.

I applied these three patches.
Without entry in fstab: When I try to get into a floppy through Thunar it says: "Message did not receive a reply (timeout by message bus)." And service udisksd ends.

(In reply to comment #14)
> I applied these three patches.
> Without entry in fstab: When I try to get into a floppy through Thunar it
> says: "Message did not receive a reply (timeout by message bus)." And
> service udisksd ends.

I can confirm this problem here after applying the 3 patches to the current version 2.1.3.
Running "udisksctl mount -b /dev/fd0" with the removed fstab entry just gives:
Error mounting /dev/fd0: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)

udisksd apparently crashes, it disappears from the process list temporarily, and is restarted again immediately.

With the following fstab entry in place it works and indeed mounts the disk as user, not root as before:
/dev/fd0 /media/floppy auto noauto,user,sync 0 0

I installed debuginfo packages now and attached gdb to udisksd, I get the following backtrace:
Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fa21ffff700 (LWP 2865)]
0x00007fa230cae849 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00007fa230cae849 in raise () from /lib64/libc.so.6
#1 0x00007fa230cafcd8 in abort () from /lib64/libc.so.6
#2 0x00007fa231297f0d in ?? () from /usr/lib64/libglib-2.0.so.0
#3 0x00007fa2312b52f7 in g_assertion_message ()
   from /usr/lib64/libglib-2.0.so.0
#4 0x00007fa2312b535a in g_assertion_message_expr ()
   from /usr/lib64/libglib-2.0.so.0
#5 0x000000000041fc05 in probe_fs_type_prior_to_mount (error=0x7fa21fffe778,
    block=0x2510220) at udiskslinuxfilesystem.c:623
#6 calculate_fs_type (error=0x7fa21fffe778, given_options=0x25bb4d0,
    block=<optimized out>) at udiskslinuxfilesystem.c:746
#7 handle_mount (filesystem=0x25102b0, invocation=0x7fa2240031c0,
    options=0x25bb4d0) at udiskslinuxfilesystem.c:1448
...

So it seems to assert in udiskslinuxfilesystem.c:623, which is:
gassert (block == NULL);

Created attachment 100040
[PATCH 2/2] Probe media that hasn't been probed by udev yet.

(In reply to comment #16)
> ...
>
> So it seems to assert in udiskslinuxfilesystem.c:623, which is:
> gassert (block == NULL);

Yeah, that really should have been, (block != NULL). That should teach me not submit patches without reading over them a second time after a good night's sleep.

Anyway, thanks for testing the both of you, and sorry for crashing your udisks. I think this time I got it right.

OK, with updated patch it works. But there is a problem:

$ udisksctl mount -b /dev/fd0
Error mounting /dev/fd0: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Failed to open device /dev/fd0 for filesystem probing.

$ udisksctl mount -b /dev/fd0
Mounted /dev/fd0 at /media/nikts/disk.

The diskette is always mounted only with the second attempt.

(In reply to comment #18)
> OK, with updated patch it works. But there is a problem:
>
> $ udisksctl mount -b /dev/fd0
> Error mounting /dev/fd0: GDBus.Error:org.freedesktop.UDisks2.Error.Failed:
> Failed to open device /dev/fd0 for filesystem probing.
>
> $ udisksctl mount -b /dev/fd0
> Mounted /dev/fd0 at /media/nikts/disk.
>
> The diskette is always mounted only with the second attempt.

I can confirm this here: It works now, but only on second attempt when there's no fstab entry (with an entry it works immediately).

But I don't think this is related to the patch or udisks2.
I see the same behavior with "mdir". After inserting a new disk, "mdir" fails with:
Can't open /dev/fd0: No such device or address
Cannot initialize 'A:'
Running it a second time works. Also after running mdir once, "udisksctl mount" works and vice versa. So this rather seems to be a kernel issue I think.

> But I don't think this is related to the patch or udisks2.
> I see the same behavior with "mdir". After inserting a new disk, "mdir" fails with:
> Can't open /dev/fd0: No such device or address
> Cannot initialize 'A:'
> Running it a second time works. Also after running mdir once, "udisksctl mount" works and vice versa. So this rather seems to be a kernel issue I think.

Same behaviour on kernel 3.14.
Floppy mounts from the first attempt on a kernel 3.2.

(In reply to comment #20)
> > But I don't think this is related to the patch or udisks2.
> > I see the same behavior with "mdir". After inserting a new disk, "mdir" fails with:
> > Can't open /dev/fd0: No such device or address
> > Cannot initialize 'A:'
> > Running it a second time works. Also after running mdir once, "udisksctl mount" works and vice versa. So this rather seems to be a kernel issue I think.
>
> Same behaviour on kernel 3.14.
> Floppy mounts from the first attempt on a kernel 3.2.

Thanks for testing.

I couldn't reproduce the problem here, but I'll try with a newer kernel next week. Unfortunately I only have access to an actual floppy drive about once a week.

BTW, what kind of distribution and destop environment are you two using?

> BTW, what kind of distribution and destop environment are you two using?

Debia Wheezy, XFCE.

(In reply to comment #21)
> BTW, what kind of distribution and destop environment are you two using?
openSUSE 13.1 with kernel 3.11.10 and KDE 4.13.1 here.

> I couldn't reproduce the problem here, but I'll try with a newer kernel next
> week. Unfortunately I only have access to an actual floppy drive about once
> a week.

I can reproduce the issue (both) in VirtualBox with openSUSE Factory (kernel 3.14), so a physical floppy drive is not really necessary.

I will test with other kernel versions as well in the next days...

kernel 3.12.9.1 - works normally.

Kernel 3.13.10 - works normally.
Possibly it is regression in a kernel 3.14

(In reply to comment #24)
> kernel 3.12.9.1 - works normally.
(In reply to comment #25)
> Kernel 3.13.10 - works normally.

I tried some kernels as well, here are my findings:
It works fine (on first attempt) with the 3.7.10 kernels from openSUSE 12.3.

It still works fine with the 3.11.6 kernel shipped with openSUSE 13.1.
But it fails with the 3.11.10 kernels available in the official update repo.

Anyway, I guess you/we can stop trying different kernel versions now:
> Possibly it is regression in a kernel 3.14
This is the commit that causes it:
https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git/commit/?h=for-next&id=7b7b68bba5ef23734c35ffb0d8d82079ed604d33

I built openSUSE 13.1's 3.11.10 kernel (the latest one that has this problem) _without_ that commit (it was backported by openSUSE), and it works fine now.

Here is the accompanying bug report that lead to this commit:
https://bugzilla.novell.com/show_bug.cgi?id=773058

Not sure how to proceed now.
I think a bug report against the kernel would be in order, as this not only affects udisks.
(as mentioned, mdir and blkid show the same behavior)

I guess I'll start with reporting it to openSUSE, as they are "responsible" for that change.
But this will have to wait until after the weekend.

> Anyway, I guess you/we can stop trying different kernel versions now:
> > Possibly it is regression in a kernel 3.14
> This is the commit that causes it:
> https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git/commit/
> ?h=for-next&id=7b7b68bba5ef23734c35ffb0d8d82079ed604d33
>
> I built openSUSE 13.1's 3.11.10 kernel (the latest one that has this
> problem) _without_ that commit (it was backported by openSUSE), and it works
> fine now.
>
> Here is the accompanying bug report that lead to this commit:
> https://bugzilla.novell.com/show_bug.cgi?id=773058
>
> Not sure how to proceed now.
> I think a bug report against the kernel would be in order, as this not only
> affects udisks.
> (as mentioned, mdir and blkid show the same behavior)
>
> I guess I'll start with reporting it to openSUSE, as they are "responsible"
> for that change.
> But this will have to wait until after the weekend.

I've got to the same commmit by using 'git bisect' independently. I haven't looked into it yet, however. I guess a bug report to util-linux might be good too.

(In reply to comment #27)
> I've got to the same commmit by using 'git bisect' independently. I haven't
> looked into it yet, however. I guess a bug report to util-linux might be
> good too.

No need for any further bug reports.
This has been fixed already:
https://lkml.org/lkml/2014/5/28/297

It has been backported to openSUSE's 3.11.10 kernel and will be part of the next kernel update there.
I tried it out, and floppy disk access now works at first attempt again, be it with mdir, blkid, or the patched udisks (with or without an fstab entry for the floppy drive).

And yes, the patches still work fine and fix the issue reported here, i.e. the floppy does get correctly mounted as user, no matter whether there is an fstab entry or not.

Ah, cool. Thanks for monitoring the situation on that front.

Is this patch in Udisks yet?