[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ale] Samba setup
On Aug 4, 2005, at 9:21 AM, Michael Trausch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Mark Wright wrote:
>> I added a root passwd to the smbpasswd file and then made sure I
>> myself. I did put a UID for myself on the system. After I did
>> this I
>> have changed the failure message (which I forgot to mention in the
>> original post) Now I am getting a message that says a "machine
>> does not exist."
>> That helps. There is a script that is supposed to create this.
>> Here is
>> the log data from this failure.
>> [2005/08/03 20:30:08, 0] rpc_server/srv_samr_nt.c:_samr_create_user
>> _samr_create_user: Running the command `/usr/sbin/useradd -s
>> /bin/false \-d /dev/null l200772$' gave 1
>> useradd: unable to lock password file
>> "unable to lock password file?" What is that for? More reading.....
> You need to create the Machine Trust Account on the domain controller.
> Also, ever user that you want to authenticate, must have a UNIX logon
> and a Samba logon. You do not need to explictly create their home
> - -- only their extra fileshares that they would use for the
> purpose of
> filesharing, and make sure that it has a reasonable umask so that they
> can actually "share".
> The Machine Trust Account (both in UNIX and Samba) has a $ in it. So,
> for a computer named "fd0man"
> To create the Machine Account:
> "To add machine account, use your system script, most likely
> adduser. If
> your system does not support user names with $ (i.e. FreeBSD), you
> edit your password database to add it manualy. So on FreeBSD, use
here is the machine account script that SAMBA had as default in smb.conf
add machine script = /usr/sbin/useradd -s /bin/false \-d /dev/null %u
> And in Samba: smbpasswd -a -m <machine-name>$
> "The system accounts for machines do not need login shell neither home
> dir, so use false as login shell and /dev/null as home dir.
> After adding system accounts, you must use smbpasswd to add Samba
> machine account. There you can use $ in usernames."
> Now, some of the other quirks that I've found -- I use a mostly
> setup (it's secure and it works).
> ** If you need extra drives, then give them those drives via a logon
> script (or scripts) in the \\SERVER\netlogon share.
> ** The user that is the Domain Administrator, at least in Samba
> 2.x, not
> sure if this is still true in 3.x, because I haven't tried to go
> it with my network, must be 'root'. This means that Windows NT
> "Administrator" user name can't be a domain administrator. But
> that's okay.
> You can map Windows system groups to UNIX groups. If you want a
> user to
> be a Windows Administrator on the local machines when they login to
> them, you can set that. Same for Power User and all of that -- it's
> handled directly on Samba. If you do not do this, I believe they all
> default to Administrators.
> You have the [homes] section defined, as well as the multiple user
> definitions. This is redundant -- they will get two shares
> available to
> them, however, Windows NT/2k/XP will connect to the [homes] share --
> that's the one offered as the user's "network home", which will
> hold the
> Windows profile (and be mapped as Drive Z:).
> In reference to the above, I'd recommend that you remove your
> [Profiles] section and store that in each user's UNIX home directory.
> This keeps things centralized, and that's their system accountable
> space, anyway. This makes it easier because then the share for the
> "roaming profiles" is always available right with the user's
> automatically mapped Z: drive. (\\server\homes\profile or something
Not sure what you are recommending. The user definitions at the end
of the testparm output were created by the SAMBA scripts. Is this
redundant with the [homes] section "on"?
> like that.)
> I would recommend that you create a seperate drive/share so that they
> can share their files amongst each other and keep their home
> private. Please note that their home directories will also contain
> their registry settings and so forth from Windows. You don't want
> everying having access to that. That's just silly. Put that
> command in
> your logon.bat in your Netlogon share.
I will do this when I get the domain authentication working. I am
going to recommend a backup strategy that uses external drives as the
shared data folders.
I am thinking that one firewire drive could be the shared folder and
I could use rsync to copy it to a second drive that could be removed
to a secure location. With three spare
drives this could provide off site disk backup of their data each week.
> Lastly, I would recommend that you upgrade this setup to Samba 3 -- it
> has more up-to-date support for systems on the network, and as your
> userbase there migrates upward towards Windows XP, you won't have any
> issues with the Samba server running 3.0. It does a great job.
It is SAMBA 3
> - Mike
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
> Ale mailing list
> Ale at ale.org
NASA Maintenance Specialist
Mark_Wright at NASAsupport.com
"Whatever It Takes"
-------------- next part --------------
An HTML attachment was scrubbed...