permissions on FAT32 partition [solved]

[Trio3b]

Dual boot MDV 10.2 and Wxp

hda1 - NTFS with Wxp

hda2 - FAT32

 

hdb1 -/ MDV 10.2

hdb6 -/home

 

Created new device on MDV desktop using GUI. /dev/hda2 mounted at /mnt/win_d on desktop, named it FATshare so I can work on files from Wxp and MDV.

 

Moved some files from hdb6/home to hda2 because hdb is a small disk. Fairly certain I was able to read and write to this device. Now however, I am able to copy FROM but not MOVE FROM or WRITE TO the hda2 dev. "Access denied".

I have tried security in MCC at standard AND high.

Have tried setting permissions in MCC for /dev and for /mnt but no dice.

Have tried to set permissions for /mnt/win_d using chmod in console. Also, files in this device are readonly. If I drag them back out of this device onto desktop then the permissions change, allowing me to work on them.

 

Read in another post that umask in fstab should be set to 0. Did that and worked temporarily but now back to no access even tho umask=0.

 

Here's fstab:

This file is edited by fstab-sync - see 'man fstab-sync' for details

/dev/hdb1 / ext3 defaults 1 1

/dev/hdb6 /home ext3 defaults 1 2

/dev/hdc /mnt/cdrom auto umask=0022,user,iocharset=iso8859-1,sync,codepage=850,noauto,ro,exec,users 0 0

none /mnt/floppy supermount dev=/dev/fd0,fs=ext2:vfat,--,umask=0022,iocharset=iso8859-1,sync,codepage=850 0 0

/dev/hda1 /mnt/win_c ntfs umask=0022,nls=iso8859-1,ro 0 0

/dev/hda2 /mnt/win_d vfat umask=0,iocharset=iso8859-1,codepage=850 0 0

none /proc proc defaults 0 0

/dev/hdb5 swap swap defaults 0 0

 

Now error is "could not enter win_d"

 

 

This has to be a permissions setting that I am missing somewhere.

 

Any help appreciated

Thanks

 

[moved from Software by spinynorman]

[arctic]

Does this line work on your box?

/dev/hda2 /mnt/win_d vfat umask=0,user,iocharset=iso8859-1,codepage=850,rw 0 0

[Trio3b]

Does this line work on your box?

/dev/hda2 /mnt/win_d vfat umask=0,user,iocharset=iso8859-1,codepage=850,rw 0 0

<{POST_SNAPBACK}>

 

Seems while trying to change permissions to solve this problem I added a custom permission in MCC for /mnt/win_d, and when I removed it, all is back to normal , but I did not add this permission until after the problem arose in the first place.

The fstab for the FAT partition appeared like this during problem :

/dev/hda2 /mnt/win_d vfat umask=2022,user,iocharset=iso8859-1,codepage=850,noexec 0 0

so I changed it to :

/dev/hda2 /mnt/win_d vfat umask=0,user,iocharset=iso8859-1,codepage=850 0 0 where it remains, but this did not work until I removed the aforementioned permission in MCC permissions.

 

fstab entry for the FAT partition at this point is exactly as you suggest, minus the rw, which I will try this weekend.

Would you say that things get squirrely in permissions and networking when using a combination of GUI and CL?

Thanks

[arctic]

Would you say that things get squirrely in permissions and networking when using a combination of GUI and CL?

Probably yes. AFAIK, you can change everything from the CLI but once you use the MCC, the draktools will load some default configurations that definitely work in case you messed up your files with the CLI. It is a safety-feature, in order to make you system usable in an emergeny situation. But I don't know if it will result in party overwritten files or completely restored one. At least this is what I had read but I am not 100% sure about the whole matter.

[AussieJohn]

My fstab is as follows and I have used it for about a year now and have never had trouble reading and writing to a vfat (fat32) partition. Troubles have only arisen when this was altered in any way.

 

/dev/hda6 /exchange vfat umask=0,iocharset=iso8859-15,codepage=850 0 0

 

Keep in mind that this can only be edited to read this way while in root mode which can easily be done by typing ....kdesu konqueror... in Konsole, entering your root password which will open Konqueror in root mode so you can go to /etc/fstab.

Unless you make the changes in root mode and select save then your changes will not be kept. There should not be any difference between changes made by the CLI and what you find in MCC if you have logged out and back in.

Cheers. John.

Edited December 10, 2005 by AussieJohn

[Trio3b]

So far the removal of the MCC custom permissions entry seems to have quieted things down, although haven't figured out the reason for the change in the first place.

Thanks to all