cannot modify files on Windows share mounted on Linux

I am so frustrated with all the arcane nonsense wrapped around samba I could scream.
I asked a question recently on this forum for which I never got an answer.
It involved not being able to browse to Linux shares from Windows as named shares and affiliated LONG LONG (VERY LONG) delays encountered by a Windows source control application called Accurev when it tries to host workspaces directly on Linux.
So after a year of searching for a solution, it suddenly occurred to me that maybe I am going at this wrong. So I tried mounting a Windows share on Linux. This way I could use Windows to directly host my source, source control it from there and let Linux access the files on the Windows share.
I spent 2 or 3 hours trying half a dozen recipes for mounting a Windows share through samba until I finally got one to work. YAAY.
I was so excited I almost wet myself :-)
But then I cd'd to my build directory and typed "make clean" to remove all the object files from my gcc project and it failed because, although I can see them all, I cannot modify ANY files on the share.
I did everything Windows would allow me to do to make these files public by changing the sharing attributes.
But from Linux, when I try this:

ls -l B*.c

and get this result:
-rwxrwSrwx 1 rudolph root 15323 Oct 28 13:43 Bop.c

All the permission bits seem to indicate write access is allowed, but what in blazes does 'S' mean??????
Is this preventing me from writing these files, or is there some other ogre hiding in the woods of XP that is thwarting my attempts?

Here is my mount command:
mount /mnt/Winshare

Here is fstab:
[ /mnt/Winshare/bmc_v2_9277/bmc/controller]# cat /etc/fstab
/dev/VolGroup00/LogVol00 /                       ext3    defaults        1 1
LABEL=/boot             /boot                   ext3    defaults        1 2
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap                    swap    defaults        0 0
//BPCLT28/workspaces /mnt/Winshare cifs user,uid=500,rw,noauto,suid,credentials=/etc/sambapasswords 0 0

and the credentials are in this file:

cat /etc/sambapasswords


And by the way, all the password references in all these recipes refer to the Windows username and Windows Password, not the Linux password?? Yes?

Our Windows domain is an Exchange Server.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

dbruntonQuid, Me Anxius Sum?  Illegitimi non carborundum.Commented:
S is possibly group permissions.

See but the example there has a small "s" instead of a "S"

Can't really comment on the rest of your question.
fklein23Author Commented:
Thanks dbrunton, By the time I got your answer, I had already found some info about the sticky bit.
Furthermore it looks like that's my problem.

But what eludes me still is: what can I do from the Windows end to turn the sticky bits off?
fklein23Author Commented:
I read that if I mount the partition with this option:

mount  -o nosuid //BPCLT28/workspaces /mnt/Winshare

Then the sticky bit would not be imported from the share.

This didn't work. The sticky bit remains persistently ON.

-rwxrwSrwx 1 rudolph root 15604 03-15-2010 14:00:05 Bop.c

From Linux I can't chown the file and cannot chmod it either (even though I am running as root) when nI look at it through the share.
In fact the files originated in Linux, were owned by root (in the root group) and were copied to Windows and then shared back to Linux.

I looked at the share from a Windows explorer and found that although I could share the files out to the Windows user, 'rucolph', I could not turn off the readonly attribute from Windows.

With this new and "improved" ADS version of Windows, (XP Pro on my laptop and Exchange Server with ADS on the domain server) I can't share out to "everyone" only to selected users. So I select the same user that my mounted partition shows as its user and password combo.

So from Linux, I see the owner appears to be the Windows user (rudolph) and the group is root.
Was I supposed to use root and root's password in my mount command?? I used rudolph.

By starting out with files owned by root, copying them to Windows, sharing them back to Linux and viewing them through a mounted Windows share on samba, the owner became rudolph, instead of root, and now I am simply lost in terms of who controls ownership and permission rights here. I am just completely disgusted that this is so ridiculously difficult and arcane.

Anybody out there know how to untangle this mess?????????????

fklein23Author Commented:
I have continued to hack at the mounted samba share.
This APPEARED to work:

mount -t cifs //BPCLT28/workspaces /mnt/Winshare \

This should make all directories drwx
and all files rw-

Now when I look at these files with ATTRIB (from the Windows viewpoint), I get NO attributes turned ON.

When I look at is from Linux, it looks OK, too:

ls -l temp.C
-rw-rw-rw- 1 root root 1710 10-14-2009 17:31:14 temp.C

cd ..
ls -l .
drwxrwxrwx 1 root root     0 04-15-2010 22:44:31 .

(... and some other files we don't care about!)

But now, if I try to edit or delete temp.C, I get

# rm temp.C
rm: remove regular file `temp.C'? y
rm: cannot remove `temp.C': Permission denied

However, now windows CAN delete this file, but Linux can neither delete nor modify them, even though the Linux shell sees the files as read/write

I have tried to spoof the system by mounting as user=root and user=rudolph
The results are the same.

Note that even when I mount, specifying user=rudolph, Linux STILL says that the owner and group for the files are both root.

I am running out of things to try.


fklein23Author Commented:
I have resolved the issue by simply going with the flow.

None of the suggestions thus far have made it possible to write to these files.

Although I still can't write to these files, I changed my Makefile so that when make executes, it writes object and executable files generated by the build process to a writeable directory OUTSIDE of the mounted Windows share. This allows me to work around the problem with the side-effect of the overall system being more robust (because Linux cannot accidentally write to the source, and multiple copies of source code cannot proliferate, since the workspace is only on the developer's laptop (and the source control database))


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.