Member Avatar for linuxnewbie

Hi, I have gone through the previous threads on this topic and still have a problem, and that's why I'm posting this.

I have a dual bootup system, with windowsxp and Red Hat 9. I have tried to mount the 4 windows partitions on linux by 3 ways and am listing the problems:

1. Adding entries like "mount /dev/hda<number> /mnt/win_c" in .bash_profile of users. However, because a normal user doesn't have the permission to use mount command, they don't mount.

2. Adding entries like "/dev/hda<number> /mnt/win_c <vfat or msdos> defaults 0 2" in the /etc/fstab. My problem in this case is that at the time of bootup I get a message saying "FAT32 support is still ALPHA" and it takes around 10 seconds to mount each partition, so around 40 seconds in total. I have a P4 2.4GHz machine and this seems too long.

3. Finally I have settled on adding entries "mount /dev/hda<number> /mnt/win_c" in the /etc/, but this does not give me permission to delete files. Is it possible that this is because of my user permission?

Kindly help.

  • 2 Contributors
  • 1 Reply
  • 280 Views
  • 6 Days Discussion Span
  • Latest Post Latest Post by alc6379

Dani AI

Generated

As described, the right solution is to let the kernel mount the FAT partitions via /etc/fstab but use vfat mount options that (a) stop Linux from trying to fsck FAT at boot and (b) emulate ownership/permissions so non-root users can create/delete files. The long boot pause is usually caused by an attempted fsck on FAT; as pointed out, disable that check and let Windows run chkdsk when repairs are needed. The “FAT32 support is still ALPHA” banner is common on older kernels and is informational rather than an immediate error.

Do not rely on mounting from a user .bash_profile (normal users can’t run mount) or on a plain root mount in rc.local without options (that will make files appear owned by root). Instead, add an /etc/fstab entry that sets the owner and mask for the whole VFAT tree (replace YOUR_UID/YOUR_GID with the numbers from id -u and id -g):

LABEL=WINDOWS_C  /mnt/win_c  vfat  uid=YOUR_UID,gid=YOUR_GID,umask=0022,shortname=win95  0 0

To test immediately without reboot, remount with the same options:

mount -o remount,uid=YOUR_UID,gid=YOUR_GID,umask=0022 /mnt/win_c

Then confirm with mount | grep /mnt/win_c and ls -l /mnt/win_c. If you want ordinary users to be able to mount/unmount manually, add the user (or users) option to the options list or create a narrowly scoped sudo rule for the mount command. Use umask, or fmask/dmask, to tune file vs directory permissions; avoid umask=000 on multi-user systems. For repairs, run Windows’ chkdsk rather than Linux fsck.

Member Avatar for alc6379

I don't ever recall having that problem with my vfat partitions when running Red Hat 9. Try changing the line:

/dev/hda<number> /mnt/win_c <vfat or msdos> defaults 0 2

to

/dev/hda<number> /mnt/win_c <vfat or msdos> defaults 0 [b]0[/b]

I'm betting that the 2 is causing fsck to run on those partitions, thus accounting for that bootup time. You really don't ever want Linux fscking your FAT32 partitions, especially not as old a version as Red Hat 9.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.