Bug 81201 - Unable to change permissions on VFAT mounted partitions
Unable to change permissions on VFAT mounted partitions
Status: CLOSED NOTABUG
Product: Red Hat Public Beta
Classification: Retired
Component: util-linux (Show other bugs)
phoebe
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Elliot Lee
Ben Levenson
:
Depends On:
Blocks: 79579
  Show dependency treegraph
 
Reported: 2003-01-06 13:24 EST by Chris Ford
Modified: 2007-04-18 12:49 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-01-13 16:34:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch for src.rpm (1.01 KB, patch)
2003-01-19 06:10 EST, Michael Schwendt
no flags Details | Diff

  None (edit)
Description Chris Ford 2003-01-06 13:24:27 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20021218

Description of problem:
VFAT mounted partitions should be mounted 0755 or at least be able to be changed
to 755, but they are being mounted 0744 and cannot be changed.

Version-Release number of selected component (if applicable):
glibc-kernheaders-2.4-8.3
kernel-pcmcia-cs-3.1.31-11
kernel-2.4.20-2.2
kernel-source-2.4.20-2.2


How reproducible:
Always

Steps to Reproduce:
1.mount -t vfat /dev/hda1 /mnt/win
2.chmod 0755 /mnt/win

    

Actual Results:  chmod: changing permissions of `/mnt/win/' (requested: 0755,
actual: 0744): Operation not permitted


Expected Results:  The permissions of /mnt/win should change to 0755

Additional info:

If I mount the partition uid=500,gid=500 I am able to take ownership of the
mount point and I am able to see the files and directories.
Comment 1 Chris Ford 2003-01-06 13:29:55 EST
I forgot to mention that it changes the date on the mount point to Dec 31 1969
when it is mounted.

[root@dagobah mnt]# ls -al
total 36
drwxr-xr-x    8 root     root         4096 Jan  6 11:31 .
drwxr-xr-x   19 root     root         4096 Jan  2 22:52 ..
drwxr-xr-x    2 root     root         4096 Dec 29 19:29 cdrom
drwxr-xr-x    2 root     root         4096 Dec 29 19:29 cdrom1
drwxr-xr-x    2 root     root         4096 Dec 29 19:29 floppy
drwxr-xr-x   73 cford    cford        8192 Jan  6 11:30 nfs
drwxr-xr-x    2 root     root         4096 Dec 31 11:58 poop
drwxr-xr-x    2 root     root         4096 Jan  6 11:31 win
[root@dagobah mnt]# mount -t vfat /dev/hda1 /mnt/win/
[root@dagobah mnt]# ls -al
total 48
drwxr-xr-x    8 root     root         4096 Jan  6 11:31 .
drwxr-xr-x   19 root     root         4096 Jan  2 22:52 ..
drwxr-xr-x    2 root     root         4096 Dec 29 19:29 cdrom
drwxr-xr-x    2 root     root         4096 Dec 29 19:29 cdrom1
drwxr-xr-x    2 root     root         4096 Dec 29 19:29 floppy
drwxr-xr-x   73 cford    cford        8192 Jan  6 11:30 nfs
drwxr-xr-x    2 root     root         4096 Dec 31 11:58 poop
drwxr--r--   28 root     root        16384 Dec 31  1969 win
[root@dagobah mnt]#

Comment 2 Josiah Royse 2003-01-08 09:03:56 EST
You are on the right track with the ownership, just add the "umask" settings to
the /etc/fstab file also.  For example "umask=000" would be wide open file
permissions.  Check the "mount" man page under "umask" for more info.
Comment 3 Chris Ford 2003-01-08 21:48:21 EST
That is correct about the umask, but the default permissions should be 0755 and
the user should be able to change the permissions of the mounted partition.  At
least that is the behavior up until this point.  And the default and current
umask on the box is 022.
Comment 4 Warren Togami 2003-01-12 17:36:07 EST
I think the component should be changed to "util-linux" instead of kernel
because it works as expected if you downgrade to mount from RH8.0.
 
Comment 5 Michael Schwendt 2003-01-12 18:19:40 EST
> And the default and current umask on the box is 022.

But mount seems to apply something like "-o umask=033" instead of "-o umask=022".
Comment 6 Elliot Lee 2003-01-13 16:34:13 EST
(V)FAT has no support for file permissions, so it's not possible to change the permissions 
of the root directory or any other part of the filesystem.

All I can suggest is to read the options for fat & vfat in 'man 8 mount'... You've already 
been using the umask option, so I suspect just playing with that and the dmask/fmask 
options will get you closer to what you want. As it stands I can't yet see anything that 
counts as a bona fide bug...
Comment 7 Warren Togami 2003-01-13 17:06:49 EST
Would it be a bug that the behavior of mount changed in Phoebe?  mount in all
previous versions of Red Hat Linux would mount it with umask 022 by default, but
it seems to mount vfat with 033 now.  I can think of no logical reason for for
umask 033. 
Comment 8 Michael Schwendt 2003-01-14 05:25:54 EST
Question to Elliot Lee: Why does mount in Phoebe use a _default_ umask=033
instead of the previous umask=022 as in Psyche or older?

It results in directories having permission rwxr--r-- (0744) instead of
rwxr-xr-x (0755). Files are world-readable, directories are not accessible.

Where's any logic behind such a change? I would understand if it were umask=077
(mount user-only access), but not umask=033. That's what this bug is about.
Comment 9 Warren Togami 2003-01-16 22:51:23 EST
Perhaps this should be opened as a new report, with the proper name "why 033
instead of 022".
Comment 10 Michael Schwendt 2003-01-19 06:10:58 EST
Created attachment 89437 [details]
patch for src.rpm
Comment 11 Michael Schwendt 2003-01-19 06:12:46 EST
@ Chris Ford : please re-open this bug-report and change the summary to
something like "wrong umask for mounted VFAT partitions"

@ Elliot Lee : apparently, you misunderstood the bug report - *please* read the
comments from Warren and me.

> util-linux 2.11v
> * mount: set umask (Sebastian Krahmer)

There's an explicit "umask(033);" call in mount.c and umount.c which makes files
world-readable (!) by default, but directories inaccessible. An umask(077) would
make much more sense. Hence I think this *is* a bug. 

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