Re: Mount linux filesystem

From: FyRE (FyRE_at_toktik.demon.ku.oc.x)
Date: 04/30/04 

Date: Fri, 30 Apr 2004 10:03:39 +0100

On Fri, 30 Apr 2004 12:11:17 +1000, "Stuart J. Browne"
<stuart@promed.com.au> wrote:

>
>"FyRE" <FyRE@toktik.demon.ku.oc.x> wrote in message
>news:dmvv80hkvjg4cqu8q8pmfi1np4rllktp34@4ax.com...
>> On Wed, 28 Apr 2004 16:59:42 +1000, "Stuart J. Browne"
>> <stuart@promed.com.au> wrote:
>>
>> >
>> >"FyRE" <FyRE@toktik.demon.ku.oc.x> wrote in message
>> >news:07iu80tsbb9q35pd5gdqv6datehccrt0f9@4ax.com...
>> >> On Wed, 28 Apr 2004 11:05:56 +1000, "Stuart J. Browne"
>> >> <stuart@promed.com.au> wrote:
>> >>
>> >> [...]
>> >>
>> >> >'smbmount' (the last time I looked at least) was incapable of mapping
>> >PDC
>> >> >based UID's/GID's to it's child-mounted structures, or enforce
>> >> >user-specific UID's to said structure.
>> >>
>> >> You need to use winbind in conjunction with the samba pam module to
>> >> remap.
>> >>
>> >> >It mounts as a given UID/GID, and continues writing as that pair.
>Not
>> >good
>> >> >in my opinion.
>> >>
>> >> Not sure what you mean here. You can of course smbmount a share with
>> >> forced details. I use a Linux workstation most of the time, and
>> >> usually mount shares as my normal user. However, I can remount as
>> >> Administrator whenever I need "full" access. Similarly, Windows users
>> >> connecting to Linux smb shares assume their correct UID/GIDs when
>> >> reading and writing to the share, accessing printers etc. You can also
>> >> override this in the samba config to force all files in a share to be
>> >> owned by user X, group Y if you wish.
>> >
>> >Was thinking of using the following:
>> >
>> > mount -t smbfs //server/share /local/path/
>> >
>> >and having UID 38 create a file in /local/path/ somewhere, and the file
>be
>> >created with UID 38 instead of whatever smbmount forced it to be
>(usually
>> >the uid/gid of the person that did the mount).
>>
>> Maybe try mount -t smbfs -ousername=someUserName,password=somePassword
>> //serverName/share /local/mountPoint, or the smbmount tool, which uses
>> a similar syntax? ;-)
>
>That forces all things to be created with owern 'someUserName', and not by
>the user who created it, thus why it isn't the best for centralized shares.
>
The example there was intended to force the uid/gid! In the usual
scenario, with multiple Windows clients connecting to a centralized
share, the user who logs into the Windows machine (on the domain)
creates files as their own UID, and their primary GID. We don't tend
to have 20 people logged into a single Windows machine at the same
time, but even if we did (and it were possible), then the UIDs/GIDs of
those users would still be enforced - unless over-ridden at the share
itself.

Even if multiple users were connecting from a single *nix box, then
they'd simply have their own (auto)mount points in their home
directories, or they could use a GUI browser to wander about the
shares, authenticated by the PDC. Samba is designed to handle a great
many simultaneous connections, so this is no problem at all. If you
wanted all files created by user with UID 10071 to be mapped to UID
38, or UID 73, or whatever, you can do that too! There's also the
problem of file locking, which Samba enforces, but NFS cannot - this
is pretty critical in an environment where 100 people may be using the
same spread***; especially with programs such as Excel which cache
changes, and alter chunks of the binary data within a file at a time -
having 2 people doing this will obviously destroy a file.

If you have very simple needs, and a unix only environment, then NFS
is fine, but since Windows is on 95%+ desktops, then it's not quite so
useful in a business environment. NFS is also not so secure, as the
client enforces security - if a user can reboot a unix client machine,
and enter single user mode to alter their details (UID/GID), before
connecting to the NFS, they can freely access anyone elses files. 

-- 
FyRE < "War: The way Americans learn geography" >