Bug 481514 - unhelpful error messages from mount
unhelpful error messages from mount
Product: Fedora
Classification: Fedora
Component: ntfs-3g (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-01-25 16:55 EST by zephod
Modified: 2009-05-12 08:10 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-05-12 08:10:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description zephod 2009-01-25 16:55:07 EST
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

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
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 07:49:53 EST
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 17:57:04 EST
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 18:11:54 EST
I'm a little confused, but I guess the right component is ntfs-3g. Reassigning.
Comment 4 Tom "spot" Callaway 2009-03-05 12:57:06 EST
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 19:02:02 EDT
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.