A sample /etc/samba/smb.conf file that worked for me
    workgroup = ABLAB
    server string = %h server (Samba, Ubuntu)
    #name resolve order = host
    log file = /var/log/samba/log.%m
    max log size = 1000
    syslog = 0
    panic action = /usr/share/samba/panic-action %d

    security = user
    encrypt passwords = yes
    passdb backend = smbpasswd
    username map = /etc/samba/smbusers

    comment = Home directory of Chris
    read only = no
    valid users = xed
    path = /home/xed
Use $ testparm to check the validity of a Samba configuration file.

Starting on Centos

/etc/init.d/smb start
sudo chkconfig smb on


Package: net-fs/samba

  • Samba wiki page. To the point; start here.

  • Samba Guide wiki page. Useful for Samba printers (but who the heck does that?).

Note that there are kernel options that must be agreeable to Samba. Something like this.

File Systems --->
    [*] Network File Systems --->
        [*] CIFS support (advanced network filesystem, SMBFS successor)--->
            [*] CIFS Statistics
                [*] Extended Statistics
            [*] CIFS Extended Attributes
                [*] CIFS POSIX Extentions
            [*] SMB2 and SMB3 network file system support

Notes on Samba Authentication Issues

After a lot of research here’s what I think. Samba is doing two things. 1. It is a file transfer protocol, it moves files. And, 2. it decides who can do this, it authenticates. As an authentication mechanism, it’s very flexible. Too flexible. It can keep it’s own users, groups, etc, or it can pass along authentication requests to the underlying system (to PAM, for example). The problem is that when you let Samba use it’s own user database, the records for the passwords are stored in hashes that are different from that which PAM uses. This means that if you want to use PAM (the Linux accounts) you have to enable Samba to pass the passwords in clear text to PAM so that PAM can hash them and compare with what’s in PAM’s database. This works fine in a trusted environment where the chances of someone sniffing passwords off the wire is small, but it is a terrible idea on the wild internet.

There is another way. One possibility is getting an LDAP server set up. With that working, both PAM and Samba can be configured to use the same "directory" of users and hashes (securely).

Perhaps the simplest way to set up is to use smbpasswd, Samba’s own special way of what amounts to keeping an /etc/passwd file. This involves setting up a temporary "directory" (i.e. list) of users in the Samba style (on the Samba server, there will essentially be a separate "password file"). This will require people to have/set a different password (which could be the same).


In the past I used smbpasswd but apparently some things have changed and now there’s a thing called pdbedit. At first I had trouble with this command.

$ pdbedit -v -a -u xed
new password:
retype new password:
Failed to add entry for user xed.

It took a while to figure this out but it turns out that this cured it.

useradd -s /bin/false -u 11111 -N xed

For many situations this problem wouldn’t even come up, but this was on a storage server with no user accounts. It seems that if there are no Unix accounts, there can be no Samba accounts. At the very least, in my case making Unix accounts allowed the Samba accounts to be possible.

I couldn’t figure out how to make pdbedit change Samba passwords, but smbpasswd did still work fine for that.


In smb.conf you need this:

passdb backend = smbpasswd

To add Samba users (totally different from Linux PAM users):

:-< [nike][/etc/samba]$ sudo smbpasswd -a xed
New SMB password:
Retype new SMB password:
startsmbfilepwent_internal: file /etc/samba/smbpasswd did not exist.
File successfully created.
Added user xed.

Looks like you must have a corresponding Unix account to set the smbpasswd or you get "Failed to modify password entry for user …" So much for the independent authentication mechanisms.

Also you may want to map Samba users to Linux users with whatever was specified here:

username map = /etc/samba/smbusers

Usually contains something like

xed = "xed"
jack = "jack"

Note that the real password file seems to live (CentOS7) here.


If it’s zero, you haven’t added your user.


Testing the local host to see if the server is on.

smbclient -U% -L localhost

This works for testing the exports.

smbclient -U xed // -c ls

If there are no passwords.

smbclient //pelican/pelicanc -N

where "pelican" is the name of the host and "pelicanc" is the name of the share as set in W95.

If you want to use backslashes for some reason, double them up -

smbclient \\\\pelican\\pelicanc -N

The "-N" option bypasses the password prompt.

When in smbclient, FTP commands often work. To exit, "q" works.

I had big big problems for too long because I was screwing up the syntax. Don’t put a trailing slash on the end of the share name!!!!!!


smbclient //parrot/parrotc/*

This is correct:

[~]$ smbclient //parrot/parrotc

To list what Samba thinks it’s offering:

$ smbclient -L localhost

(Password here seems optional.)


smbmount //pelican/pelicanc/ /mnt/pelican -n

This will mount the share "pelicanc" to path /mnt/pelican -n should be used to mount shares that do not need a password

I had trouble mounting a smb share as non-root. I used su and then had to explicitly call out where smbmount was:

/usr/sbin/smbmount .....

smbumount seems to be for non-root users who use smbmount. To unmount the smb file system as root, use ordinary umount:

umount /mnt/pelican

If you have trouble mounting because of a host name too long error, "my hostname name too long as a netbios name: cardinal.windmills" try this:

smbmount //canary/canaryc /mnt/pelican -n -c cardinal

I don’t understand what the deal is, but this makes it work out.


I think on a Mac if you’re in the Finder, you can do a Command-K (or maybe "Go" → "Connect To" if you like menus) and then enter something like this in the "Server Address:" box:


Click the "Connect" button and you’re using your local file manager to move files in and out of the samba server.