Bug 481514 - unhelpful error messages from mount
Summary: unhelpful error messages from mount
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: ntfs-3g
Version: 9
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Tom "spot" Callaway
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-01-25 21:55 UTC by zephod
Modified: 2009-05-12 12:10 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2009-05-12 12:10:07 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description zephod 2009-01-25 21:55:07 UTC
Description of problem:
If a filesystem type that is unknown to mount is passed with the -t flag, mount produces the error message like this:

/bin/sh: /dev/sdb1: Permission denied 

It would be much more helpful if the error message said something like "unknown type"

Version-Release number of selected component (if applicable):
$ rpm -q --whatprovides mount
util-linux-ng-2.13.1-8.3.fc9.i386


How reproducible:
Every time

Steps to Reproduce:
1. Edit /etc/fstab to add a line similar to this:
/dev/sdb1    /mnt/c_drive       fuse  rw,nosuid,nodev,allow_other,blksize=4096    0 0 
Use a valid device and mount point
2. As root run
mount /dev/sdb1
3.
  
Actual results:
# mount /dev/sdb1 
/bin/sh: /dev/sdb1: Permission denied 

Expected results:
# mount /dev/sdb1 
unknown filesystem type

Additional info:

Comment 1 Karel Zak 2009-01-26 12:49:53 UTC
in such case mount(8) calls /sbin/mount.fuse or directly uses the type in mount(8) syscall. In both cases it's not mount(8) that generate the error. The mount(8) has not clue that type is (un)known for the kernel. The mount(8) follows kernel only.

Please, try "strace mount ...." and check if the mount(8) calls /sbin/mount.fuse.

Comment 2 zephod 2009-01-26 22:57:04 UTC
I meant to say that the line in /etc/fstab looks like this:

/dev/sdb1               /mnt/c_drive            ntfs-3g rw,nosuid,nodev,allow_other    0 0 

which results in /proc/mounts having this line:

/dev/sdb1 /mnt/c_drive fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,blksize=4096 0 0

and so to answer your question:

# strace mount /dev/sdb1
...
stat64("/sbin/mount.ntfs-3g", {st_mode=S_IFREG|0754, st_size=40056, ...}) = 0
...

Comment 3 Karel Zak 2009-01-26 23:11:54 UTC
I'm a little confused, but I guess the right component is ntfs-3g. Reassigning.

Comment 4 Tom "spot" Callaway 2009-03-05 17:57:06 UTC
I'm really not sure I understand what the bug is here. fstab does know what the filesystem is, its ntfs-3g, as you've specified. Also, the strace on the mount call without -t clearly shows it executing /sbin/mount.ntfs-3g (which is provided by the ntfs-3g package).

So, something else is failing here. I'm wondering if it is the "allow_other" option... I don't see it in the mount manpage (or in the ntfs-3g specific "mount.ntfs-3g" manpage).

Comment 5 Szabolcs Szakacsits 2009-05-11 23:02:02 UTC
There are two issues here.

1. Originally fstab has 'fuse' fstype without a real file system type and mount without -t was called. This usage makes no sense. /sbin/mount.fuse was called with bogus mount values and according to the FUSE specs, /dev/sdb1 tried to be executed as the FUSE file system which failed because /dev/sdb1 typically has no execution permissions. Everything worked as expected and documented, including the error message.

2. Then the 'fuse' fstype was changed to 'ntfs-3g' in fstab and mount(8) correctly called /sbin/mount.ntfs-3g. I nowhere see any error here. Mount must have worked fine.

Then based on the strace output, the bug was reassigned to ntfs-3g for case 1. 

Tom is right, ntfs-3g has as much to do with this "bug" as the ping command.


Note You need to log in before you can comment on or make changes to this bug.