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:
[192.168.101.79:LEC-2010P /mnt/Winshare/bmc_v2_9277/
/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,sui
and the credentials are in this file:
cat /etc/sambapasswords
username=john
password=Johnspassword
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.
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:
[192.168.101.79:LEC-2010P /mnt/Winshare/bmc_v2_9277/
/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,sui
and the credentials are in this file:
cat /etc/sambapasswords
username=john
password=Johnspassword
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.
ASKER
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?
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?
ASKER
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.
thus:
-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?????????????
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.
thus:
-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?????????????
ASKER
I have continued to hack at the mounted samba share.
This APPEARED to work:
mount -t cifs //BPCLT28/workspaces /mnt/Winshare \
username=rudolph,dir_mode=
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.
HELP!!!!!!!!!!
This APPEARED to work:
mount -t cifs //BPCLT28/workspaces /mnt/Winshare \
username=rudolph,dir_mode=
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.
HELP!!!!!!!!!!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
See http://www.comptechdoc.org/os/linux/usersguide/linux_ugfilesp.html but the example there has a small "s" instead of a "S"
Can't really comment on the rest of your question.