Bug 481514

Summary: unhelpful error messages from mount
Product: [Fedora] Fedora Reporter: zephod
Component: ntfs-3gAssignee: Tom "spot" Callaway <tcallawa>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: kzak, szaka, tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-05-12 12:10:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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.