pn] I'm trying to set up Samba on a Linux Red Hat 6.1 machine. Other machines on my network are NT4 and Win98. I generally followed a NHT, except that I have a domain using user-level access for shares instead of a share-level access. I couldn't get it to work, and tried diagnosing it using the document at http://us1.samba.org/samba/docs/DIAGNOSIS.html. Several tests are not working as expected. pn] Before I post the details, is this the correct list for me to get some help? Thanks in advance for being nice to this newbie. ----- Peter Nosko
[Peter Nosko]> Before I post the details, is this the correct list for me to get > some help?Yes indeed. Peter
[Peter Nosko]> No responses after a couple of days. Maybe it isn't after all. Or > am I being impatient? :>It's the right list, no doubt about it. You might also try the newsgroup comp.protocols.smb, though I haven't looked in on them for the past couple years. The problem is that your question is at once vague and difficult. Vague in that you didn't actually post your smb.conf file -- this can help a great deal. Difficult in that there are so many things that can go wrong with a new Linux install, in terms of networking in general as well as Samba in particular. I have been on this list for several months, and your experience so far is not unusual. Many questions get answered, many do not.> I don't know much about setting up DNS (yet), so all my machines areSamba basically doesn't need DNS for anything, so don't worry about it.> I generally followed the NHF at > http://www.linuxnewbie.org/nhf/intel/network/samba/samba1.htmlI see at least one typo on that page. (Well, on samba2.html.) The config file parameter nterfaces = ... should be "interfaces".> I started following the troubleshooting checklist at > http://www.linuxnewbie.org/nhf/intel/network/samba/samba1.htmlWhat checklist? Is it something that doesn't show up in Lynx?> Test 4 returned my internal network address (192.168.2.0) instead of > the IP address of the Linux/Samba machine (192.168.2.3). Test 8 got > me what I mentioned above (error #59), so I didn't bother with test > 9. Test 10 is a GUI version of test 9.Since I can't see the checklist, please be more specific. Also, do post (or at least send me) your smb.conf file.> Also, I've seen stuff about a compatibility issue between NT4/Win98 > encrypted passwords and Samba. If I'm trying to do something that > isn't yet fully supported, please let me know. If so, I'd welcome > suggestions for alternatives.Well, you have basically three choices: "encrypt passwords = yes" and "security = user" means you have to maintain a separate password file, `smbpasswd' (I don't know where Red Hat puts it; Debian uses /etc/samba/), instead of just using regular user passwords from /etc/passwd. "encrypt passwords = yes" and "security = domain" means that you don't maintain the passwords locally at all; you designate an NT machine -- preferably a domain controller -- to authenticate users for you. Note that if you have "security = domain", you also have to fill in "password server = YOUR_NT_DOMAIN_CONTROLLER" and make sure you join the domain. (See the docs for the `smbpasswd' command for how to join a domain.) "encrypt passwords = no" means you just use your Unix password list for Samba authentication. But then if you are using Win95B or later, or NT4SP3 or later, you have to apply a registry hack to your clients so that they will allow sending unencrypted passwords. See the docs directory for these registry snippets.> BTW, I've already downloaded RH6.2, and if that's part of thep> solution, I'm ready to install it. I doubt it. Peter
[cc back to samba@samba.org because this info might be of general interest] [Chris Mauricio]> If I use "encrypt passwords = yes" and "security = user", then each > user on my NT Domain who wishes to access a share on the linux box > must have a username and password equivelant to the one on the NT > domain. ( right? ) If I do that, then they ALSO have a valid login on > the linux box ( right? ) So that means in theory, they could telnet > into the box, or I should disable some script somewhere to prevent > this. ( right?)Yes, but there are ways around it. "encrypt=yes" "sec=user" means the Samba server authenticates users. Each user must have an entry in /etc/passwd -- Samba uses this for the person's real name, home directory, UID, GID and /etc/group for other groups. The user *also* has to have an entry in /usr/local/samba/private/smbpasswd -- or wherever you designate smbpasswd to live -- to determine the actual password used. Basically, when you're in "security=user", the Samba server acts as though it's just in a workgroup, not a domain -- UNLESS you also use "domain logons=yes" in which case it behaves as either a PDC or BDC. I have no direct personal experience with Samba as DC, however. I wouldn't try it with 2.0.x.> if I use "encrypt passwords = yes" and "security = domain" , then > automatically, NT auths the users, maintains the passwords, so here > is the part that I am not clear on: How do I set either user A, B, C > to access the samba share, and deny others from the domain, if NT is > the one doing the auth?With "sec=domain", you must also have "password server = SOME_SERVER" where SOME_SERVER is an NT domain controller (or a Samba DC...) -- or possibly an NT workstation with local accounts you want to use, but that won't work as well and requires knowing what you are doing. Well, actually, you can use "password server = *" (some versions of Samba) and it will broadcast for one, just like NT does, but that's not recommended because it makes it easier for an attacker to spoof you. In any case, Samba is no longer in control of the passwords. However, Samba is *still* in complete control of the UID, because you can map any NT user to any Unix user. Use the "username map=FILENAME" parameter.> related question: How do I set permissions on certain files within > the public share, ( 'A' can read, 'B' has no access, 'C' can read/ > write ) if NT is maintainig the passwords? If the user doesn't exist > on the linux box, I can't readily set permissions can I ?The user *must* exist, either way. That paragraph above where I described the duties of /etc/passwd -- it also applies to "sec=domain". The only things /etc/passwd are not used for in this case are password and login shell. (Login shell doesn't mean much to SMB, after all.) After the username is substituted in from your username map file (if you have one), the resulting Unix user must be in /etc/passwd. Thus he will have a UID and at least one GID. Thus you can use the regular Unix permissions mechanisms to restrict access however you wish. HTH. Peter