fstab mounts Windows share but read only.
 

In attempt to access my home shared folder on my Windows 2003 Server / Active Directory domain, I've stuck following entry in my /etc/fstab file:

//server/share$ /home/username/domainshare smbfs credentials=/home/username/.credsfile,workgroup=windows.domain.com,defaults 0 0

I can view the folder, subdirectories, and contents, but everything is "Read Only". Is there a parameter I'm missing in the fstab file? I didn't find anything obvious in the man page.

Try the 0 0 0 0 mask.

Just to be sure I understand you, you're suggesting I add two more zeroes at the end?

yeah,, thats right!!

no, that's wrong.
to the options section would apply that mask, but I don't think that will help you much.
The problem you are having is your mounting it as root so only root would have rw permissions, you can fix this by changing the line to

After trying both suggestions individually and together, the line in /etc/fstab now looks like

//server/share$ /home/username/domainshare smbfs credentials=/home/username/.credsfile,workgroup=windows.domain.com,uid=[username],gid=[username],umask=0000,defaults
0 0

and I still am unable to make changes to this directory or the files in it. More specifically, attempts to delete a file from the command line return:

rm: cannot remove 'filename': Permission denied

Attempts from the Nautilus GUI give me:

Error while deleting

"/home/username/domainshare/filename" cannot be deleted because you do not have permissions to modify its parent folder.

Are there changes I need to make to other files or to the share on the Windows server?

what do you get if you do
"ls -l [filename]" on one of the files you can't delete?

ls -l filename
-rwxr-xr-x 1 65535 65535 0 Jul 21 16:19 filename

well no wounder you can't delete it, for some reason the share is mounted with user ID 65535 (although I dont know why)
Try unmounting the share
and then try mounting it from the command line
and see if that outputs anything and check the permissions again.

you can also try replaceing smbfs with cifs and see if thet helps

What's the difference between prefacing a command with sudo vs. entering su and the password then entering each command and exiting?

I entered the "sudo umount" command and was prompted for a password. I entered the root password and got a "Sorry, try again." After three failed attempts I was returned to a $ prompt. I tried again with the same results. I know I'm keying it in right; it's the same password I use for Admin on my Windows system, it works for "su", and on the fifth and sixth attempts I keyed it in with a single finger, one character at a time.

I tried again with my user password and received "username is not in the sudoers file. This incident will be reported." Unfortunately, on subsequent attempts I now receive this message instead of a password prompt.

sudo uses YOUR password, it's used so you can give some users admin rights (to some or all commands) without giving out the root pass.
Sudo also preserves your environment, so you can run GIUs ar root without logging in as root (gksu, kdesu etc. are wrappers for su or sudo depending on how it's setup, on ubuntu its a wrapper for sudo).
Because in ubuntu the root account is disabled by default (though most users enable it right after install, like me) sudo is used to run administrative tasks by asking for the users password and only works if the user is setup in the /etc/sudoers file. sudo really replaces su as you can get a login shell with "sudo -i"

checkout "man sudo"

Thanks for the sudo answer, but as I noted I get a "username is not in the sudoers file. This incident will be reported." response when I use my password. Would entering the umount and mount commands after entering su and the root password accomplish the same thing, or must I troubleshoot the sudo problem before I can make progress on the read-only share problem?

This is a Red Hat 9 installation, not Ubuntu, if that makes any difference. Since I'm trying to do all of this from the command line, I'm not sure the distro would affect the process.

All you have to do to resolve the sudo problem would be to add yourself to the admin group, but yes, su followed by the umount & mount commands would work fine. I just like sudo for the convenience since I have it setup so I dont need to enter my password (don't do that unless you have a strong password and know who has access to your box).

so su
Password:
umount /home/username/domainshare
mount //server/share$ /home/username/domainshare -t smbfs -o \
credentials=/home/username/.credsfile,workgroup=windows.domain.com,uid=[username],gid=[username],umask=0000
ls -l /home/username/domainshare/filename

if the user/group are the same unmount it again and use "cifs" insted of "smbfs"

The umount command works cleanly. After entering it, the share disappears.

After keying in the mount command and pressing Enter, the cursor dropped to the next line and has remained there. No error messages, no # or $ prompt, just a cursor blinking at the beginning of a blank line. Hitting Enter a couple of times generates two more blank lines.

If I open a second command window I can cd to the share and view the contents, but

$ rm filename
rm: cannot remove 'filename': Permission denied
$ ls -l filename
-rwxr-xr-x 1 username username 0 Jul 21 16:19 filename

And I've still got the first window open with blinking cursor.

that is strange, it seems that mount isn't finishing whatever it's doing for some reason. Is the share on the server setup to give you read-write access or just read-only?
Also when you mount with "-t smbfs" it's not mount that's working it's smbmount, smb protocol is quite old and is only really here for compatability, cifs is the newer version (I think from XP up windows works with cifs), so maybe see what happens when you try cifs