Quote:
|
Cant you do it by adding a row similar to this in /etc/fstab
|
Yes, I could, but because my first box is multi-boot, from the perspective of the second box I never "know" which OS I might boot into (Windows or Slackware). Thus, a script that tests which OS is running on that first box is easier. Usually I boot into Windows (NT4), but not always. A script run from
rc.local makes more sense.
Quote:
|
For added security, you may wish to keep your username and password locked in a .smbpasswd file and then use the "credentials=" fstab option to reference the .smbpasswd file. Make sure you chmod .smbpasswd 600 otherwise you defeat the whole purpose.
|
I do exactly that in my script and already have configured a credentials file. My mounts are automatic from within the script and there are no errors with actually connecting and mounting. At this point I apologize because with hindsight I realize that I posted my question too soon. After further investigation I have additional information to add to this puzzle.
Apparently I can modify files as would be expected by the
gid of
users. The actual problem is more subtle and initially threw me off-path in my search for an answer.
I have a script in which I copy files from one operating system to another and I use the file date stamp as my means for synchronizing. Originally I used the script only to sync files in my multi-boot box between Windows and Slackware. I used a shared FAT32 partition to move files between the two environments. Worked well.
I then tried using the same script between my two boxes. The original shared FAT32 partition was now a Samba mount point on box two as opposed to a "simple" mount in my multi-boot box.
When I ran this script to sync files between the two boxes, the copying actually was working, but I got fooled for a while thinking otherwise because of the error messages I was receiving. I was using the
touch command to modify the file date stamps to ensure files stayed synced. The
touch command kept failing and for a while I believed the copy process was failing. In actuality, the copy process worked just fine and only the
touch command was failing.
After I understood what was actually happening I performed some additional tests. The
touch command, or the
cp -p command, will always fail with a Samba mount if the user attempting to use
touch or
cp -p is not the same user identified as owning the mount point. Hence, the
gid option becomes useless with respect to the
touch or
cp -p commands.
If the user attempting to use
touch or
cp -p with a Samba mount is the same as that identified by the mount command
uid, then the user will be able to successfully perform the commands.
The script worked in my multi-boot box because I mounted the shared FAT32 partition with the
uid of my normal login account. Thus, the
touch command always succeeded. I had forgotten that tidbit.
In my environment, where I am the sole user of these two particular boxes, I can "cheat" and mount the Windows shares using the
uid of my normal login account. That account and root then will have no problem using
touch or
cp -p. Any additional accounts I create on my box are out of the loop, however.
That latter observation leads me to conclude that in a true multi-user environment, all but two users will always be left out in the cold with respect to modifying file date stamps---although they still can modify files on Windows shares.
Windows does not understand
uid and
gid in the same sense as does 'nix systems, and Samba should not be enforcing that environment on Windows shares. Even if the mount command needs to create the illusion of a
uid and
gid, Samba should be ignoring
uid if the share is actually a Windows system. If native Windows allows me to modify file date stamps then Samba should honor that system design. And this does not happen.
Although arguably I have a solution available for my personal usage, I try hard to approach my systems from a multi-user perspective. Perhaps my need is peculiar, perhaps not, but regardless, this is a problem in a true multi-user environment.
Does anybody see a valid work-around to this problem?
. User B decides to use Box 2 and logs in at a different console/terminal. User B wants to modify some of those commonly used files on Box 1 but can't because the uid is assigned to User A. Same problem as previously, only a different user now owns the files.
