• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

whats wrong with my fstab?

OrganizedChaos

Diamond Member
debian linux, 2.6 kernal

trying to mount one of my old windows drives to get some stuff off of it. its mounting fine and i can browse it as root but as s user i can't even enter the directory- permission denied. the man page for fstab says i just need to put in the "user" tag. what am i missing?

chmod 777 40A gives back the error message: "read-only file system" but i don't know why, the the "rw" tag in the fstab should make it writable?
 
Odds are, if the drive is NTFS, the NTFS kernel driver is overriding the rw mount. NTFS write isn't quite safe just yet. As for why the user mount isn't working, I'm not quite sure.
 
Here are the options I'm using for a Windows disk that I keep mounted: rw,suid,dev,auto,users,async,gid=6,umask=0002
I'm using rw because it's a vfat volume, and writing works well. For NTFS you probably don't want write access. My understanding of the current state of NTFS writing is that you can't change the file name or size, so you're pretty restricted in what changes you can make, and violating those rules may cause file corruption.
I don't remember the details of why I use suid and dev (they're explained in the man page, so you can see if it's something you want).
Auto just mounts the volume at boot time; you may want to change that to noauto if you only want to mount it manually.
Users (plural) does the same thing as user (i.e., any user can mount/unmount the volume), plus it allows a different user to unmount it than who mounted it. (With user, the same user has to mount and unmount it.)
Async lets the write-back cache do its job, rather than making sure each I/O transfer happens in real time.
THESE LAST TWO ARE THE ONES THAT WILL HELP YOU.
gid=6 sets the group ID to the disk group when the volume is mounted (I'm also using Debian, so it's a safe bet that group 6 is the disk group for you, too). Make sure you're a member of the disk group so that you get group privileges when the disk is mounted.
umask=0002 sets the permissions to rwxrwxr-x. The umask setting is subtractive from the numerical permissions, so this is equivalent of calling chmod 775 (the umask uses an additional 0 to lead off the numbers). In your case, I recommend not setting a write bit for everyone, so perhaps you'd use a umask of 0227, or 0337 if you don't plan on running programs from the Windows drive (with Wine, for example). You can also change that last 7 to a 2 or 3 if you don't mind exposing the disk to people outside the group.

As a side note, the owner of the mounted volume will be the user who mounts it (I think the suid option does that). So if you use the auto option, it will mount at boot time with root as the owner. If you then unmount it and remount it as a user, you will become the owner.

I hope this helps you!
 
All I have in my fstab options for my ntfs drives is
"uid=1000,umask=0222".
The uid defines me access to read it, and the umask defines it as read only. You won't have write access, but you will be able to read it no problem.
 
thanks guys got it fixed. put "uid=1000,umask-0002" in since i only have one user and it did the trick. i'm not to worried about corrupting it, as i understand it it will only become corrupted if the drive is put back into a windows box(or so google tells me).
 
Originally posted by: OrganizedChaos
thanks guys got it fixed. put "uid=1000,umask-0002" in since i only have one user and it did the trick. i'm not to worried about corrupting it, as i understand it it will only become corrupted if the drive is put back into a windows box(or so google tells me).

No, if you're using the NTFS partition as read-only, then it should not become corrupted at any point...
 
Back
Top