[global] 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 [xedhome] comment = Home directory of Chris read only = no valid users = xed path = /home/xed
Starting on Centos
/etc/init.d/smb start sudo chkconfig smb on
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
$ 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 //xalab.example.edu/xedhome -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!!!!!!|
THIS IS WRONG
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:
smbumount seems to be for non-root users who use smbmount. To unmount the smb file system as root, use ordinary umount:
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.