Re: [suse-linux-uk-schools] Re: SAMBA setup
From: "Alan Davies" <staff.asd@birkenhead.wirral.sch.uk> To: suse-linux-uk-schools@suse.com Subject: Re: [suse-linux-uk-schools] Re: SAMBA setup Date: Tue, 5 Dec 2000 10:16:55 +0000 (GMT)
On Mon 04 Dec, Gary Stainburn wrote:
smbmount //server/share /mnt/mountpoint
Sorry. I wrongly assumed that you'd used the normal unix 'mount'
command
before and understood mountpoints.
I would like to say - publically - that I am very greatful for the help received. I realise that thinking down to my level requires considerable effort!
In keeping with this idiom, everything starts from a root (/) partition. Other partitions are connected (mounted) at specific points on this root partition. The boot partition (/dev/hda5 on my system) is mounted on /boot, thus once mounted, you access that partition by 'cd'ing into /boot.
Getting it to do this was my problem.
Mount -t smb and smbmount work similarly, but allow you to do the same with a remote Win9x share. It mounts the remote service as part of the local system's directory tree structure. For example, I have a
directory
on my local system called /mnt/smb. If I mount a remote SMB service, I put it there so I always know what I've done with it (although running mount without arguments would tell me that anyway).
Hope this makes things a little clearer for you.
So - creating a 'mountpoint' is effiectively creating a link to an already exisiting directory entry (it doesn't produce that direcotry entry for you?)
I had mistakenly assumed that smbd and nmbd were running be default - as smbclient worked fine. I know understand that smbclient works independently and in the opposite direction to those daemons. (I know know about the extra options for ps command...)
So I now hvae swat running, smbd, nmbd running and my LINUX box appears in the browse list of by NT domain. smbmount now works and I can connect to my NT share and/or home directory on NT system.
Which all brings me to the final problem...connecting to the LINUX box from a remote station. (smbclient //localhost/test -U% works fine)
My test samba config file is:
[global] log level=1 max log size = 1000 socket options = TCP_NODELAY IPTOS_LOWDELAY guest ok = no workgroup=BHEADS (my NT Domain name so that it appears in the right browse list) [homes] browseable = no map archive = yes [printers] path = /usr/tmp guest ok = yes printable = yes min print space = 2000 [test] browseable = yes read only = no guest ok = yes public = yes path = /test
Entering the share from the brwose list on the NT server brings up a logon/password box (which surprises me - as I thought guest logon was ok).
Using a LINUX username and password The subsequent error message on the NT box reads 'The account is not authorised to login from this station'
Is this a problem with encrypted passwords? I add the line 'encrypt passwords= yes' to my smb/conf file (as per page 73, Reilly) and ....testparm doesn't like it.
Later in Reilly it states 'encrypted passwords = yes' which it also doesn't like.
What should it be? Perhaps I should ask NT to do password authenication..
The hosts.deny file only contains a http-rman: all line.
-- Alan Davies Head of Computing Birkenhead School
I might not be understanding your problem correctly, however problems I had with getting into a share samba was offering were solved by: At linux prompt adding a user with the same name as the user I was logged into windows as. # useradd <windows-user-name> Then in swat I would goto the 'passwords' section and put that username in, with password equal to my windows password and then 'add new user' and 'Enable User' the user. Then a 'reload' of the daemons.. however you do this.. even a physical machine restart *shudder* .. but then I can access the linux share via a windows machine. Hope this helps. --Azrael _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com
I might not be understanding your problem correctly, however problems I had with getting into a share samba was offering were solved by:
At linux prompt adding a user with the same name as the user I was logged into windows as. # useradd <windows-user-name>
Then in swat I would goto the 'passwords' section and put that username in, with password equal to my windows password and then 'add new user' and 'Enable User' the user.
I was hoping to avoid this kind of solution...duplicating of passwords, etc. and the problems of keeping them syncronised. Currently we are only 'playing' with Linux to investigaate its potential. If it came to replacing our NT domain with it - I would want to consider the loss of redunancy as we currently have two Backup Domain controllers (not yet supported by SAMBA/LINUX) in different locations around the school campus so that in the evern of network failure/server failure logon can still be accomplished. -- Alan Davies Head of Computing Birkenhead School
I was hoping to avoid this kind of solution...duplicating of passwords, etc. and the problems of keeping them syncronised.
If it came to replacing our NT domain with it - I would want to consider the loss of redunancy as we currently have two Backup Domain controllers (not yet supported by SAMBA/LINUX) in different locations around the school campus so that in the evern of network failure/server failure logon can still be accomplished.
I'd love to know more about this can of worms. We have only one password file for all systems, all email, web, servers, platforms etc. The only place where passwords are replicated are on the local hard drives of w95 and w98 machines where it seems to be necessary for "mount network drive" to work, and this need to log onto the desktop with the same username and password as that used on the Unix system is very tedious and a serious security hole. NT clients don't need it. w98 and NT clients need "EnablePlainTextPassword". The "browsing" feature of Windows, that "network neighbourhood" thingy, is something that seems completely unnecessary, and here it works in fits and starts, browse lists are never the same, but luckily they seem to perform no function apart from enabling pupils to copy mp3 files between each other's machines. One of our Samba servers is configured, I think, as a PDC, but it and the whole domain concept seems here to be an issue only to my Windows technician, who keeps on muttering that he can't see various machines on network neighbourhood and can't understand why not. I can't understand that or why, either, I say just put the server name in the "mount network drive" box and forget about whether or not you can see it. To summarise, we have about 150 Windows machines here accessing Samba, and I have made no deliberate provision for PDC's or BDC's and have not yet seen a need to do so. It seems unnecessary. For what would I need it? -- Christopher Dawkins, Felsted School, Dunmow, Essex CM6 3JG 01371-820527 or 07798 636725 cchd@felsted.essex.sch.uk
On Tue 05 Dec, Christopher Dawkins wrote:
I was hoping to avoid this kind of solution...duplicating of passwords, etc. and the problems of keeping them syncronised.
If it came to replacing our NT domain with it - I would want to consider the loss of redunancy as we currently have two Backup Domain controllers (not yet supported by SAMBA/LINUX) in different locations around the school campus so that in the evern of network failure/server failure logon can still be accomplished.
I'd love to know more about this can of worms. We have only one password file for all systems, all email, web, servers, platforms etc. The only place where passwords are replicated are on the local hard drives of w95 and w98 machines where it seems to be necessary for "mount network drive" to work, and this need to log onto the desktop with the same username and password as that used on the Unix system is very tedious and a serious security hole. NT clients don't need it. w98 and NT clients need "EnablePlainTextPassword".
I can't see why it is necessary to replicate usernames/passwords to W95/98. I'm not keen on the same username/password for NT as UNIX. NT clients don't need "EnablePlainTextPassword" in recent (or even not so recent) versions of SAMBA - as I understand it. I don't enable them. But I do add 'encrypt passwords = Yes' to the global part of smb.conf ...now that I am beginning to make sense of this. I'm not clear about how I intend to manager linux/NT passwords with smbpasswd yet. Perhaps the answer is go all the way to an LDAP server.
The "browsing" feature of Windows, that "network neighbourhood" thingy, is something that seems completely unnecessary, and here it works in fits and starts, browse lists are never the same, but luckily they seem to perform no function apart from enabling pupils to copy mp3 files between each other's machines.
Copying Mp3 files is a pain. They do their best to hide them (rename extensions..bury them in zip files...split them up..... Eventually I redrew battle plans and resorted to putting up a 'shared' common directory - which was to be the ONLY place for work 'not created' by them. I have to say our Network Neighborbood works fine. But we do have a PDC and BDCs which run 24x7 and therefore ensure they are browse masters. Without such a designation you may find that browse master moves from station to station with elections...and if its turned off..you may loose sight of stations - temporarily.
One of our Samba servers is configured, I think, as a PDC, but it and the whole domain concept seems here to be an issue only to my Windows technician, who keeps on muttering that he can't see various machines on network neighbourhood and can't understand why not. I can't understand that or why, either, I say just put the server name in the "mount network drive" box and forget about whether or not you can see it.
It does look as if SAMBA will now do NT domain stuff almost completely - lacking replication and BDC support. I'm not ready to go all this way - yet. You may need to 'make it' a browse master in the 'global' part of smb.conf
To summarise, we have about 150 Windows machines here accessing Samba, and I have made no deliberate provision for PDC's or BDC's and have not yet seen a need to do so. It seems unnecessary. For what would I need it?
A Domain is a workgroup where authentication is carried out on behalf of clients by the PDC/BDCs. This is even for shares which may exist on clients, and printers which exist on clients - without needing to create users/passwords on local machines. Of course its a bit more than that...roaming/mandatory profiles, directory replication (particularly of policy files) - I didn't mention policies..., UserDB redunancy, logon scripts, and other bits that tend to get handled by the Domain. There is also quite a useful feature of local and Domain wide groups...and Domains can be made to 'trust' one another either one or both ways allowing for (in our case for staff administration) multiple domains. Whether or not the whole thing is worth the effort in another thing... And to think that I have to get to grips with Active directories of W2000 next... -- Alan Davies Head of Computing Birkenhead School
participants (3)
-
Alan Davies -
Azrael Angel Of Death -
Christopher Dawkins