Posted on 2002-04-20
Last Modified: 2013-12-15
Looks like you get one of these each year...about this time!  Well, I've read two previous answers, but I guess I want my hand held on my specific situation.

First: setup includes 1 Linux (RedHat 7.2) server, 2 pcs, both running Win98.  TCPIP is fine: everybody can ping everybody. smbclient is apparently fine: Linux box can print to HPLJ on one pc.

However, minimal problem is evident in that that pc can't "see" the network to even set up the printer that's on the Linux box.  (At one point it could/did, but when I tried to get file visibility all round I messed up ...probably, a bunch of things.) Network Neighborhood sees NOTHING, not even the workgroup.

At least for the moment, I have no need for any security within this network, so would gladly settle for "share" level access for Samba.  

I had messed with password encryption, some months ago; I think that's what killed all access. Then I tried to undo it.  I no longer have any idea which kind of encryption exists on the Linux box. How do I find out? Which works better? Which is easier to set up?

I also messed with user-level security for samba and tried to undo that.  

The Linux user "guest" was a casualty of this efforts.  It's gone. If I reinstitute, what password do I assign? How to do none? Just CR on password request?

No, I never did add the registry line on the (1st) PC
to make it NOT encrypt passwords.

The second PC is new; it has had nothing more done to it than it takes to get network connectivity. (Not yet even internet connectivity, which the older pc has thru the Linux box, just fine.) For the moment, it doesn't expect any password on bootup. When I try to setup the Linux box's printer on it, it simply sees nothing on the "entire network". No error msg.

I'm pretty sure ipchains is set ok.  Can't figure out how to  capture the output of ipchains -L to paste here. Any howto?

I'll post the smb.conf file here, tho I'm sure it is only secondarily part of the problem.  Can you help me untangle passwords? (user mjustman exists on both Linux and the older PC, with same (mixed case) password.)

smb.conf =

# Samba config file created using SWAT
# from rosalind (
# Date: 2002/03/03 18:20:57

# Global parameters
     workgroup = MYGROUP
     netbios name = EQUIPOISE
     server string = Samba Server
     security = SHARE
     ssl CA certFile = /usr/share/ssl/certs/ca-bundle.crt
#     debug level = 2
     log file = /var/log/samba/%m.log
#     max log size = 0
     socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
     preferred master = Yes

     dns proxy = No
     username = mjustman, guest
     guest account = guest
     hosts allow = rosalind
     printing = lprng

     comment = Home Directories
     path = /home   #3/2
     writeable = Yes
     guest ok = Yes

     comment = All Printers
     path = /var/spool/samba
     guest ok = Yes
     printable = Yes

     path = /tmp
     writeable = Yes
     guest ok = Yes

     path = /common
     writeable = Yes
     guest ok = Yes
        browseable = yes

Bottom line:  What to attack first? What queries to use to diagnose? What strategies do you recommend?

Beyond that, a series of steps would be helpful!

Thanks loads

Marilyn Justman

Question by:mjustman
  • 4
  • 3
LVL 40

Expert Comment

ID: 6959703
My recommendation is to start by changing the Global section of your smb.conf file to look like:

    workgroup = MYGROUP
    netbios name = EQUIPOISE
    server string = Samba Server
    security = user
    encrypt passwords = yes
#     debug level = 2
    log file = /var/log/samba/%m.log
#     max log size = 0
    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
    preferred master = Yes
    dns proxy = No
    printing = lprng

Then use smbpassword to set the SMB encrypted password for mjustman (smbpasswd mjustman) and restart Samba.

If we're lucky removing the ssl stuff from Samba will allow the PC to see the server. If not make sure that the PC is in the same workgroup.

If you still can't see it, try temporarily dropping the firewall (/etc/init.d/ipchains stop) and check again. If the server is then visbile you'll know that the firewall rules need modification.

If your firewall is using RH 7.2 native configuration the rules will be in /etc/sysconfig/ipchains (or iptables). Otherwise the rules are likely to be in /etc/init.d/ipchains or /etc/init.d/itpables.


Author Comment

ID: 6960071
Ok. Can't try this for about an hour (something about WORK?)...but I'll get back, probably today.


Marilyn J.

Author Comment

ID: 6960740

Baby steps. Baby success.
Changed smb.conf per your example.
Ran smbpasswd samantha (because she was a newer, cleaner user than mjustman).

Got response:
getsmbfilepwent malformed password entry (UID not number)
about 50 times
then a comment to the effect that nothing done.

Rebooted linux.
Rebooted pc and logged in with samantha's login.

Aha!  Now network neighborhood SEES equipoise.  (This is the baby success.)  Does this mean I don't have to worry about ipchains?

But: attempt to set up network printer failed.  Wants password for \\equipoise\IPC$  (think that's right). Won't be happy with anything I give it, including samantha's, root's, etc.

Next step?

Not incidentally, since I've obviously screwed up passwords...I somehow (probably manually) changed mjustman's password to read "500:501" where everybody else has (and she used to have) the same exact number on both sides of that colon.  Should I change it back?  How many places might I have propagated it to?  Should I change all of them? (Are they all in /etc/samba? that's easy.  Where else?)


Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

LVL 40

Accepted Solution

jlevie earned 200 total points
ID: 6960968
Lets deal with the password file first.

By default linux will create user accounts such that each user will be their own group. And if not told to do otherwise the UID (first number in the password file) will be the next free UID beginning at 500. So, the first account you created (mjustman) got UID 500 and an mjustman group was created with  a numerically equal GID (500). The next user will be UID=501, GID=501, etc. The reason for doing this is to increase the security of a user session by having each user be in their own group. To share files between users you have to add other users to your group and then they have to do a newgrp to "join" your group... kinda of a hassle but arguably more secure.

So if you look at /etc/group you should see an entry like:


And the GID (500 for you) should be the second number in your entry in passwd.

Another thing that you need to know is that normally both /etc/passwd and /etc/shadow are used for Linux authentication. The user info is in passwd and the user's encrypted password is stored in shadow. The last time I checked, Linux required those two files to have a line-to-line correspondence by username. If you've futzed around with either of the files that may no longer be the case and there could be problems.

So the next thing that you need to do is to check your passwd file against the group file and fix any problems with the GID's. Then check to be sure that the shadow file matches, by username, the lines in passwd.

Then we need to be sure that each user's home dir has the correct ownership. Again, since the user and group will have the same name by default you can do:

# chown -R mjustman:mjustman /home/mjustman

and similar commands for each other user.

Now as to the error that you got above. I tend to forget that not everybody reads the man pages before trying a command...

To add a user name to the SMB passwd file one uses:

# smbpasswd -a username

without the -a option smbpasswd will try to change the password for a user that already exists. In this case samantha apparently isn't in the SMB passwd file. Also remember that each and every Samba user must also be a Linux user of the same name (case is important).

On your PC's you'll need to have them configured to login and the username and password used to access windows must be exactly the same as you've set those users up in Linux and the SMB password file.

When all that's straightened out I believe you'll be able to access your Linux printer(s) and each windows user will have access to their home dir and other shares.

Hmm, upon looking closely at your smb.conf I see that you need to delete "path = /home   #3/2" from the [homes] definition. Samba knows how to associate each user's home dir with [homes].

Author Comment

ID: 6961735
Perfectly happy, like nothing was wrong!  (Don't you hate when computers put on that supercilious smile after you've been sweating bullets?  Teachers, at least, say "nice work", or SOMETHING.)

And all I did (I had switched mj back to her own group earlier) was to run smbpasswd with the -a switch.  (Still got the scary error messages, tho.).  Passwords and group were fine.
There's some residual junk around, but I THINK I can now clean that up by myself.

oh: even tho I'm closing this, I've got one more question:  The pcs are sharing files, too.  How do I see those from equipoise, and how can he push/pull these (let's assume they're ascii or ps files) over to his hard drives?  If that's not a one-liner, say so, and I'll make a new official question.

THANK YOU  THANK YOU  Equipoise thanks you. Rosalind thanks you.  Even Stewball will thank you soon....!

Marilyn Justman

note: as racehorses, both equipoise and rosalind were famous for their even tempers and dependable performance. I was hoping the names would have a good effect....;)
LVL 40

Expert Comment

ID: 6961770
Have a look at the man page for smbmount. With that utility you can access a volume that's been shared by a windows box.

Not quite a one-liner, but...

Horses and computers do have some points in common. Both can handle large loads and both have been known to bolt or panic when confronted by the unexpected...

Author Comment

ID: 6961799
Thanks again! Over and out for now.

Marilyn Justman

Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Automating a script for user accounts LINUX 14 70
How to have a cron job run until a condition is met 12 56
AWS CLI - Issue with name display 2 51
Linux VM 6 54
Daily system administration tasks often require administrators to connect remote systems. But allowing these remote systems to accept passwords makes these systems vulnerable to the risk of brute-force password guessing attacks. Furthermore there ar…
Over the last ten+ years I have seen Linux configuration tools come and go. In the early days there was the tried-and-true, all-powerful linuxconf that many thought would remain the one and only Linux configuration tool until the end of times. Well,…
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:
Connecting to an Amazon Linux EC2 Instance from Windows Using PuTTY.

863 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

27 Experts available now in Live!

Get 1:1 Help Now