SMB, CIFS, Samba, Windows File Sharing notes

From Helpful
(Redirected from Samba)
Jump to: navigation, search

Stuff vaguely related to storing, hosting, and transferring files and media:

Note: This is a throw-together of reading and research. Not all of it is necessarily true.


On the protocols and ports

These are primarily notes
It won't be complete in any sense.
It exists to contain fragments of useful information.

(Note that SMB/CIFS, not being open standards, and due to interesting history, work out as de-facto standards)


The original protocol is SMB, from IBM and around the late eighties. We now retroactively call this SMB1, in comparison with the newer versions.

Updated/extended for OS/2 and NT by IBM and later MS ("SMB version 2" (which is not SMB2), "CIFS" (verify))

CIFS was a rename by Microsoft and SNIA (~1996?), basically refers to the NT4 implementation, which was a bit of an update to core SMB1. The two are equally old, so from today's view these are much the same.

There were apparently further dialects of the core and earlier windows versions that didn't really get well-known versions/names(verify) You can find stray references to these by microsoft, and samba.

There was some attempt to standardize it openly that didn't pan out.

Since the windows implementation is the easiest measure of 'is your implementation compatible with things?', so effectively mostly Microsoft controls it.

SMB2 and SMB3 are more recent (Microsoft) updates to the protocol, and are generally more efficient.

SMB2 was a rewrite, based on people writing down how SMB worked (around 2007?) (verify)

Since ~Samba3.6, VistaSP2, server2008
scales better, has better async, larger read/write buffer, all leading to better performance


since Windows 7; server2008r2
mostly some performance features(verify)

SMB2.2 seems to have effectively been a beta for 3.0(verify)


added failover, encryption, multichannel, DRMA
has been around long enough that you can demand it now
Since Samba4, ~Windows8, server2012


since ~Windows8.1, server2012r2

SMB3.1 (and 3.11?(verify))

Since ~win10, server2016

(or more broadly, 1.0, 2.0, 2.1, and 3.0)

Apple adopted SMB recently basically by adopting Samba and focusing on SMB2. When Samba switched licenses, Apple decided to switch to their own flavour called SMBX.

Samba is the main *nix implementation of SMB, which also supports most of CIFS, and a good deal of SMB2 and SMB3. (note that in *nix context, CIFS kept meaning 'newer SMB', so mount.cifs is the thing you use to mount all SMB these versions - negotiation is part of it)

So now we have CIFS variably meaning:

the NT4-era implementation,
any windows variant
any flavour later than core SMB1 / the nineties

Which is why various people avoid the term, just to avoid confusion.

See also:

  • mount.cifs man page
  • smb.conf man page


SMB1 originally worked on top of a NetBIOS layer, mainly ran over IPX.

To run NetBIOS-style SMB over TCP/IP you need one of a few combining flavours, all of which have footnotes, so you rarely want this if you can avoid it.

Which you can avoid, because flavours since CIFS can be run directly over TCP, This has a few footnotes (mostly due to NetBIOS history), but fewer.

Related ports on TCP:

  • File serving:
    • 139/TCP is NetBIOS session: connection handshake, authentication, and main data transfer. Not required, you can run over 445 only (avoiding NBT)
    • 445/TCP indicates the NetBIOS-less TCP/IP service.
Windows after Win2K (Directory Server), and Samba version 3 and later typically provide this.
A CIFS-or-later client will typically try 445 and fall back to 139
  • Nameservice:
    • 137/UDP is the NetBIOS nameservice (NBNS), which usually broadcasts on the local subnet
    • (137/TCP - reserved (convention of marking udp+tcp variant of a port as the same thing), (or actually used by NBNS/WINS?(verify)
    • 138/UDP is NetBIOS datagrams, apparently used only by the nameservice, not for bulk data transfer(verify)

  • Also:
    • 135/TCP is used by MS RPC (the Microsoft DCE Locator, like a portmapper), apparently used in some situations where you want domain controllers.
or more specifically, microsoft services that rely on this (such as? remote assitance?(verify) some spooling?(verify))
Newer Sambas can also serve this, but this is not necessary for a simple fileserver.

On name resolution and network browsing

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

NetBios Name Service (NBNS) is NetBIOS's name service. Particularly since nothing uses native NetBIOS anymore, we now effectively talk about NBNS as part of NBT (NetBIOS over TCP/IP). See also RFC 1001, RFC 1002. Samba's implementation is nmbd, Microsoft's is WINS.


looks at a resolution cache (expires on the term of minutes)
looks at LMhosts, analogous to the hosts file for DNS (does not expire)
in windows this sits in %SYSTEMROOT%\SYSTEM32\DRIVERS\ETC
in linux it sits in the samba config directory, often /etc/samba or /usr/local/samba/lib
contacts WINS server; clients that have one set up will register and query there
fallback is broadcast-based
since WINS servers are not very common, broadcasts are common (and are still a fallback when one is configured)
(which is why it has been been likened to a group of drunk people in a dark room trying to communicate primarily by shouting. On larger networks, you want to contain that as much as you can :)

The idea of browse lists is to lower the need of continuous broadcasting: one (or more) node(s) node collects all announcements they have recently heard, collate this into a list, and tell anyone who requests it of them.

Clients can ask for this list when they want to show neighbouring nodes, a list that is both faster and more stable than broadcasting continuously (though it may not notice new nodes as quickly).

You can make servers on multiple subnetworks exchange browse lists. The point is that the broadcasted things they collect can stay local, but hosts on other subnets (that people can connect to via unicast perfectly well) will be known as well. While setting this up involves some study, it is often a better idea than letting NBNS broadcasts pass through all of a large network.

See also:


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Nodes need to be able to find each other. A WINS server helps here, as does having a browser master.

Use of WINS in a samba server means:

  • wins support = yes
    , which means "become server", OR
  • refer to an existing WINS server,
    wins server =
    to act as a relay to it.

Note that when a samba server acts as a WINS server and it gets a request for a name it doesn't know, it will try to resolve it with DNS as a fallback. If you know this will never work and want that lookup to fail faster, you can set: (verify)

dns proxy = yes

As to the (local) browser master, this is a node that keeps the track of the browse list, which lists the workgroups and nodes currently (or at least recently) available.

On a network with a browser master, only presence advertisements are broadcast, which the browser master collects, and nodes query the browser master.

On a network without a browser master, clients falls back on broadcasting "who's there" questions, which on larger setups can flood the network, and are less snappy since you have to wait some time for a response, instead of just downloading a short list from the browser master.

Exactly which node is a browser master (and you want exactly one) is not so important. It helps if it's an always-on server, of course. An existing file/login server is often the easiest candidate.

for ease, the browser master is automatically elected, based on 'OS levels', basically a server's self-described ability to be good at it.

Windows service send a score based on the windows variant (all Windowses since 95 can become browser masters).

Samba has a default, but you can force it to win such elections - an OS level of 20 or 30 seems to win over workstation versions of windows but not a NT/2K domain controller, ~65 wins over all Windows versions.


  • You can disover whether there is a WINS/nmbd by trying to resolve the master browser with nmblookup -M somenode. It will say something like "querying mbserver on" (verify)
  • local master = no
    opts you out of a browser election
  • preferred master = yes
    gives you some advantage (in what way?(verify)), and asks for an election in thirty seconds(verify). Only do this on a single machine, or it may trigger an election every thirty seconds, which is bad for the service as a whole
If you specify the last, you usually also want
domain master = yes
, particularly if there is no windows domain controller around. (verify)

  • domain logons = yes
    allows samba to act as a primary domain controller for windows 2K/XP/NT (and domain logon server for win9x).

On Samba security

Serving subnets, and IP-based access control

By default, samba serves on all broadcast-capable interfaces available at process startup (except, using their configured IP/subnet details.

To serve only specific networks or subnets (usually to the end of avoiding sharing with the internet) specify what you want to serve on:

bind interfaces only = True   
# meaning "instead of binding on (a.k.a. ALL), use..."
interfaces =  eth1 
#an interface name implies use of its current configuration

Additionally, or perhaps instead, you can whitelist (this implies 'no one else') hosts and nets based on IPs, using e.g.

hosts allow = 192.168.1.  192.168.2.  127.         # or the synonym, 'allow hosts'

You can also blacklist ('everyone else allowed' implied, not generally a good idea):

hosts deny = 10.                                 # or the synonym, 'deny hosts'

Probably the simplest is an "allow these nets, deny all others" setup:

hosts deny = ALL
hosts allow = 127.

Note: Using interfaces is network-level in that you don't listen to some things, while using host deny is Samba itself disconnecting connections - it would still allow a DoS, and perchance some exploit. You may want to mirror the rules in your firewall just to be sure.

The usable IP host/net styles are:

  • single IP:
  • Subnet by bitmask value:
  • Subnet by bitmask width (CIDR style):
  • Subnet by octet omission: 127. or 192.168. or 10.

security models (security=share, user, and such)

security = something
setting sets the basic security model, which mostly controls how and when connection authentication will be handled.

It also affects the user mapping.

(It is also communicated to the client, and will affect the way it communicates with the server, but this is a somewhat secondary detail)


(the default)

  • Requires authentication at connection time; incoming share requests will only work after successful authentication
  • Uses local user map and smbpasswd
  • Authenticated users have full access, unless the share has exceptions
  • Nice when you (can) use the same usernames on the clients as on the server, or when you don't mind updating the mapping samba keeps in a file.
  • Doesn't do passwordless 'allow-anyone' guest shares,
  • ...however, you can force logins by non-existing users to authenticate as the guest account, which is almost the same thing (just a little harder to debug when people mistype their usernames). This involves a setting what the guest account is and a of map to guest = Bad user, global settings.

(Does this mean you don't get any share access because guest ok=no by default, or does it mean you get full access by default because you're authenticated? (verify) I have seen guest ok=yes used globally in a security=user setup, so if that made sense it suggests the former)


(used to be the default in times of lore)

  • Initial connection without password,
  • Uses local user map/smbpasswd(verify) (when login necessary)
  • Requires authentication at share-use-request time
  • ...except on passwordless shares, those that use
    guest ok=yes
    (and its functional synonym,
    ) because in this case the server maps you to what you have set as the
    guest account
  • With passwordless (guest ok) use, user mapping is complex and somewhat unpredictable. Basically:
    • using only guest ok=yes means samba tries many things as a unix unsername (request user if supplied, logon user if login done earlier, service name, client netbios name, and more) before falling back to the guest account. This is a rather inexact
    • guest ok=yes plus guest only=yes means forced mapping to the guest account (a global setting pointing to a unix username [which is probably loginless]).


  • Like user, except the authentication is checked by another SMB server (samba, a windows PDC, etc.).
  • Useful for central password management
  • considered somewhat outdated; see the below
  • If your network isn't not robust or the server not always on, this can sometimes lead to strange rejections


  • Acts as a member of a windows domain, and authenticates against a domain controller (a winNT/win2k/win2k3 PDC, or a samba PDC)
  • will only work once the node is properly part of that windows domain (use samba's
  • Still requires a mapping to unix usernames


  • Samba server as acts as member of ADS (Active Directory Services) realm
  • Requires kerberos

Further notes:

  • only guest
    is synonymous with
    guest only
  • While there are details in behaviour, server, domain and ADS need you to specify the name/IP of a compatible LDAP server such as Active Directories server, which can include Samba, or a windows Primary or Backup domain controller. You can specify fallbacks: password server = first [fallback], or apparently '*' to locate it, if this samba server is part of the domain.
  • printer shares are exception cases (TODO: figure out) but not for everything - you may still want to use the invalid-default-to-guest trick.

User stuff

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

To access a host or share, you need to authenticate for a session.

Shares may have their own, user-specific read and write permission/restrictions.

Keep in mind that even if the share allows something, underlying filesystem permissions also apply. That is, the filesystem is accessed as the effective *nix user that samba has been to map to. It's not unusual to trust the authentication and tweak user details to have the filesystem part allow everything. See also #User mapping).

Authentication (samba users)

Whenever you start a new session with a SMB server, you have to authenticate on it.

Samba can be configured to authenticate in a few ways.

You can't make samba use unix accounts directly, mostly because the way passwords are hashed is different. (you could do a bunch of script-fu to get very close, though)


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

The thing where passwords are stored, that you samba need to access.

To tell samba to use something other than the default (a local file):

passdb backend = something

The file-based methods (tdbsam, smbpasswd) don't really let you run multiple samba servers. In theory you could, but you would need to worry about synchronizing changes to these these files, about concurrent writes, and such.

The networked backends tend to scale much better (though it can depend. I've worked well-known LDAP software that behaved terribly)


(used to be the default)

a local plain-text file (at something like /etc/samba/private/smbpasswd).

Smbpasswd scales badly to a large amount of users. You'ld want tdbsam

Not to be confused with the
executable, which can update this file, and apparently also tdbsam(verify). Its main uses:
  • smbpasswd olduser
    changes a password
  • smbpasswd -a newuser
    adds a user, and essentially assumes it already has a unix account
  • smbpasswd -d user
    disables a user. Re-enable with
    smbpasswd -e
  • smbpasswd -x user
    removes a user from smbpasswd file.

(currently the default)

Similar to the smbpasswd backend, but uses a different file (passdb.tdb) which is a simple binary file-based database.


Uses a networked LDAP server.

You would probably use it for its centralized account management, and allows integration with existing LDAP / ADS servers. Full integration can be a complex pain, but basic access control tends to be easy enough.


This is often the easier option when you don't have or want existing LDAP, but still want centralization. Need not be much more than "create a table, allow samba to get to it".

The basic hook-in looks something like:

passdb backend = mysql:foo
foo:mysql user = mysql
foo:mysql password = kjdshgkjdfhgsdk
foo:mysql database = samba

The foo there is a samba-specific namespace(verify), apparently to avoid ambiguity on complex setups.


...and more

underlying users

After a client authenticates, samba needs a local (unix) username.

This largely because it runs one daemon process for each such (effective) user, as the unix user that is mapped to.

That local user merely needs to exist - it's not necessary to be able to login / shell to that account, so it need not have a password or home directory.

Common solutions include:

  • map everything to one user. This is simple to do, good enough for one or two clients, sluggish for concurrent use and way too slow for serious setups. (Primarily because parts of the protocol is sequential(verify))
  • in a large house or so, you can create users for housemates by hand
    • ...and possibly a guest (all guests will be served by one process, but hey).
  • if you use networked authentication, you may well want to create local users based on it

The samba guest account is a bit of a special case, and usually maps to a unix account such as 'nobody', 'ftp', or 'guest' if that exists, and are usually chosen to be passwordless/shell-less accounts, so that it can't be used as regular *nix login.

You can make samba fall back to the guest account, which can be nice for some public shares.

Note that such security minimalism may be double-edged. For example, 'nobody' usually does not have printing rights, which sometimes makes public printer sharing a little more complex.

Further notes:

  • Some clients (notably windows) will automatically try the login information for the user currently logged into windows.
    • Between my laptop an my server this means I never have to type the password. It's not so useful for housemates unless you trust each other with your passwords...

other user details

When you do want want separate user mapping (for auth and smb-process reasons), but wish to avoid filesystem permissions related to users and groups, you can force access to a share to use a particular user and group:

force user  = house
force group = house


The permissions of new files are goverened by

  • create mask (a.k.a. create mode) (defaults to 0744)
  • directory mask (defaults to 0754)
  • force create mode (defaults to 000)
  • force directory mode (defaults to 000)

What happens is basically a bitwise ((value & create mask) | force create mode))

inherit owner

By default, the owning user of new files comes from the share's (or is that session's?(verify)) effective user ID.

If instead od thius you want user and group to be copied from parent directory, use:

inherit owner = yes

Keep in mind that this may not play well with force user's effect.

guest, IPC$

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

IPC$ is an endpoint for RPC messages to a server. It is used to transfer the share list, among other things. Windows clients uses IPC$ for more things than various other clients do.

The IPC$ share is built-in in samba in that it exists (with some defaults) without being mentioned in smb.conf. You can add this entry if you want to change its details, e.g. its security settings. The ipc$ share does actually have a path, which defaults to a temporary directory (TMPDIR if it is in the environment, otherwise /tmp(verify)).

For example, when you have user-level security, only authenticated users can view the list(verify), which is not always what you want if you want some of your shares to be guest-accessible.

You can for example require that only known users can get at your share list

Samba's guest account is often used to allow public access to the IPC$ share. You can also log into a session as guest. You can also set samba to treat incorrect logins as guest logins (some practical caveats to that, though)

Domains 'n things


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Domain controllers

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


password level
username level
allow case insensitivity in passwords and/or username, by generating case-change permutations (defaults set it to 0, strict case sensitivity).

Setting this value high can solve problems such as DOS sending all-uppercase usernames and windows uppercasing the first character - but slows initial connections where such variation is unnecessary (and is a minor brute-forcing tool for hackers, that handles case variations). The number represents what?(verify). This is deemed a debugging tool.

You can also use this feature hackily, to map several windows users to one unix user - pseudogroups of a kind.

map to guest = never
disables the feature of making bad logins map to the guest user. This feature tends to be annoying and a little opaque behaviour to users as it sort of half works; at least failure will lead to complaining and hopefully an eventual proper setup.
  • By default,
    null passwords = no
    , meaning you cannot have a zero-length password. This is a good security thing, but for a home network where you have windows accounts without passwords this may be useful to disable. (verify)

Samba configuration

The easiest configuration is to use SWAT, a web interface that is aware of possible options, and has per-item links to the documentation.

Where and how

Samba configuration consists of editing /etc/samba/smb.conf, but is infamously complex because of a mass of (oftne implicit) details.

Try SWAT, (Samba Web Administration Tool) which exist to lighten the burden of samba setup, by at least having a fairly sensible layout, and links to a HTML version of the documentation.

SWAT is a web service usually served through xinetd. If not configured automatically on installation, you need to do something like edit /etc/xinetd.d/swat and make sure you have an entry like:

service swat {
  protocol = tcp
  socket_type = stream
  port = 901
  disable = no
  user = root          
  wait = no                #means multi-threaded, xinetd accepts connections
  server = /usr/sbin/swat

user is the effective user. Make this the most restricted user that can edit /etc/samba/smb.conf, preferably not root.

Firewall the port so that you can only reach port 901 yourself (preferably only through localhost, or perhaps a private IP range), then run /etc/init.d/xinetd reload to restart xinetd with swat enabled (your distro may require you to do more work than that; you'ld have to check with it), and point your browser to http://localhost:901 (or wherever you set it up).

Of course, many of us like to figure out all the details by reading manuals and editing the file yourself.

To those, I would recommend looking at the testparm command, which parses the configuration, reports unknown/deprecated parts of your configuration, and outputs the effective configuration, which can be handy in debugging.



workgroup = homelan
security = user
encrypt passwords = yes
guest account = guest      #or nobody

#browsing stuff
wins support = yes
os level = 30

workgroup, realm

On standalone servers, workgroup is the the workgroup to show in the browsing list.

With security=domain this is the NT domain, and has stricter requirements such as that you need to join it using

Realm is analogous to domain, but for kerberos, so and important when you use ADS(verify).

encrypt passwords

encrypt passwords is on by default, as it should be.

Tells clients not to bother sending plaintext passwords, which is good for security and required by various versiong of windows (as clients), and only only windows 95 and 3.1 will have trouble with the default 'yes,' so you basically always want this to be yes.



Resolving: NetBIOS names must be resolved to IP for samba to work over IP. Options:

  • host: gethostbyname(), which will be /etc/hosts and DNS, or NIS.
  • wins: WINS server, as configured
  • lmhosts: netbios variation of /etc/hosts (and with similar limitations)
  • bcast: local subnet broadcast (a la ARP)

You may want to avoid the DNS lookups 'host' introduces. Or you may specifically want them, to look up things not on the local segment - which also possible via wins and lmhosts, but has to be configured that way.

On small LANs, wins and bcast are enough. lmhosts tends to be both ineffective and safe as usually only those who know what they are doing touch it. In larger networks, you have to read up on subnet communication, broadcasting and what gets routed anyway; I'm not going into that right now.

Serving subnets, and IP-based access control

By default, samba serves on all broadcast-capable interfaces you may have (except, with their configured IP/subnet details. To serve specific subnets -- usually to avoid sharing with the internet -- specify what you want to serve on:

interfaces =
interfaces = eth1

((verify) the last - presumably it would mean using the interface's current IP config)

Additionally, or perhaps instead, you can whitelist (this implies 'no one else') hosts and nets based on IPs, using e.g.

hosts allow = 192.168.1. 192.168.2. 127.         # or the synonym, allow hosts

You can also blacklist ('everyone else allowed' implied, not generally a good idea):

hosts deny = 10.                                 # or the synonym, deny hosts

The IP styles are:

  • single IP:
  • Subnet by mask:
  • Subnet by bits:
  • Subnet by octet omission: 127. or 192.168. or 10.


Samba will rotate logs into a single backup file. If you want to avoid losing things, set max log size (in kilobytes) much higher.

You can log things per share or machine by using %S and %m in the log file filename.

To make a log for each host that connects, use %m in the hostname (note: can appear by IP and netbios name separately, apparently due to resolution?(verify)).

To split per share, use %S.

# e.g. per host:
log file = /var/log/samba/%m.log
# or to log everything into one file:
log file = /var/log/samba/smbd.log

Higher log levels mean more information. I consider this only useful for debugging, as excessive logging can slow samba down.


  • 1: failures, errors, major login messages
  • 2: warnings, general startup/configuration messages, file opens
  • 3: detailed startup/configuration messages, authentication mapping checks, various protocol-related messages
  • 4: more user and auth related messages, for config debugging, bug reports
  • 5: more debugging: directory opens, some debug parsing for message types, function call trails of some general-purpose functions
  • 6 to 10 are used almost exclusively to leave a trial of function calls and for protocol hacking. 10 actually dumps packets in hexadecimal.

You can set a global log level, and/or per debug class:

# say,
log level = 3 passdb:5 auth:10 winbind:2
# or
log level = 2 passdb:0 auth:2 winbind:0 sam:0 rpc:0 ads:1


# You can additionally use the syslog, with a different threshold.
# When logging details to samba logs, I tend to make make only errors go to syslog (1), or nothing:
syslog = 0
# ...or tell samba to log syslog only (and not the its own logs)
syslog only = true

Note that
is a newer, more precise way of doing both of the above, and it deprecates syslog.

A (basic) share

A minimal share definition looks something like

path = /data/directory/to/share


  • To not list a share in browsing, set browseable = no. (Disables listing it, has no other effect on access)
  • To add a user friendly name for browsing, add comment = Big data directory.

Users and rights

By default, all authenticated users have write access to all shares.

In some cases you may want to restrict that, for example, whitelist users that can access a particular share:

valid users = friend1, friend2, @friendgroup

...or blacklist (usually not a useful solution) with:

invalid users = @stupidheads

If you use both, entries in invalid override those valid (useful behaviour when there is overlap between groups and users in those groups).

You can control read-only/read-writeness of a share, in general and for specific users.

For example, you can set a share read-only by default, but allow specific people write access:

The first part is to use one of these four fully synonymous options:

read only = yes
writeable = no
writable = no
write ok = no

...followed by whitelisting people who can write:

write list = user1, @group

This is useful to create a share one person can write and other people can read.


  • Using
    read list
    write list
    will not imply putting these users in
    valid list
  • The write list overrides the read list for items that are on both lists.
  • In small home LANs can could consider just adding users (implied valid) and letting it be all-writable. On slightly larger networks whitelisting users is generally sensible, on larger yet groups can become useful.
  • yes, you can blacklist too. It's generally not what you want, and you can figure that out yourself.

Unix-level permission

The samba server itself is just another process accessing the filesystem, so abides by file ownership and such.

This is one reason there is an smbd process for each session - you access as the applicable user.

Related options:

  • create mask (a.k.a. create mode) - bitmask to apply to files created through samba.
    • note that it's AND mask (not umask style, which would specify what to take away)


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

You will need to set the printing system that's running on the server, e.g.

printing = cups

As an alternative to making entries in smb.conf yourself, you can tell samba to read your /etc/printcap file for sharing:

load printers = yes

The share must have:

printable = yes

This seems to refer to full writability to it as a spool, even when read only=true. I'm not sure about these details yet.

CUPS cooperates well with samba to allow more than lineprinting: You can tell windows (and linux) clients they're talking to a PostScript printer, and CUPS (or is that ghostscript?(verify)) will figure out the translation from PS to what the printer needs.

Apparently windows (XP and probably later/others) can deal with an URI like smb://user:pass@server/printershare


If you don't want to print and want to keep your logs clean of constant messages like:

[2007/02/07 01:01:38, 0] printing/print_cups.c:cups_cache_reload(85)
  Unable to connect to CUPS server localhost - Connection refused

...then try the following in your [global] section, which tries to disable and hide all printing features:

#Part of this is probably redundant.
load printers = No
show add printer wizard = No
printcap name = /dev/null
printing = bsd

Special variables


%a   architecture (e.g., Samba, WfWg, WinNT, Win95, UNKNOWN)
%I   IP address   
%m   NetBIOS name
%M   DNS name


%u   unix username
%g   primary group of %u
%H   home directory of %u
%U   requested client username (not always used by Samba)
%G   primary group of %U


%S   current share's name
%P   current share's root directory
%p   automounter's path to the share's root directory, if different from %P


%d   process ID
%h   DNS hostname
%L   NetBIOS name
%N   home directory, from automount map
%v   samba version


%R   SMB protocol level
%T   date and time

Config file check

will give you warnings and errors about the basic setup of your smb.conf

In some cases it can be much more informative to get all the feedback of running smbd in the foreground, with something like
smbd -Fi
(though presumably a higher log level will get you much the same(verify)).

Speed tweaks

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

For reference: my cheap home gigabit computer-switch-server setup usually gives 60..80MByte/sec, .

This isn't quite up to the speeds of NFS (or FTP, HTTP, or other things that tend to saturate the line), probably because of some extra overhead in SMB/CIFS. Also, don't expect a single connection (= single user, see also notes on unix-mapped users below) to use the full line speed, due to how TCP works.

You can check the speed limit of your network setup (networking hardware, drivers, and network settings) with something like netio or ttcp. (Note that since there is no disk latency, IOPS, and whatnot, you shouldn't expect serving of files to always be this fast) If this is less than the theoretical link speed, you may want to investigate/tweak that.

On links that have very high speeds, and/or latency of milliseconds or more, TCP window size details enter into things -- however, in recent kernels, the auto-tuning often works very well, and almost always better than some values you copy verbatim from the 'net.

Samba network settings


Name resolution

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Initial connection slow


Apparently, Windows (XP, probably others) will by default use the WebClient service, which tries WebDAV connections that back read/write Web Folder functionality, used by a few downloadable tools, and by IE's "Open as Web Folder" feature.

Most people don't actually need it, and disabling this service can make browsing a lot faster.

Additionally, windows (particularly since XP and 2000) will check for existence of a few things, including Scheduled Tasks and Printers.

Particularly the 'Scheduled tasks' is something few people care for. To stop this check completely, introduce yourself to registry editing, find


and remove:


There are other things you may not need. For example, in a lot of setups you won't use your housemates' printers. If so, you can also remove:


Browsing speed

Directory metadata (general)

Thumbnails (windows)

Windows loves updating and reading Thumbs.db. It will dive into child folders of the one you are displaying to see whether it can use Thumbs.db (or folder.jpg) to show content examples. Files that don't have entries will be opened, processed, and have entries created in Thumbs.db.

When you want thumbnails at all, this is a good thing: without it, all image files would have to be opened and processed each time, which will take more transfer, more disk IO, more client CPU.

Using Thumbs.db can still easily mean a dozen or two file accesses over the network (particularly if you have a lot of subdirectories), even if you're just doing a save-as and browsing to a network drive.

Some people like disabling their thumbnail caching to avoid cluttering network drives, in which case each thumbnail has to be generated every time (but this time only in thumbnail view) (note that if you have multiple clients to a share, it is easier to veto out the filenames on the server side)

Note that windows will not create (and possibly not update(verify)) Thumbs.db on samba shares under certain conditions. If this is a problem, the following seems to fix it (TODO: figure out why).

nt acl support = no

On client caches


vfs objects = readahead

This will detect a client doing reads in blocks of 512KB, and will hint the kernel to read ahead that much.

Apparently this includes Windows Vista.

You can alter the offset to detect, and the amount to read ahead.



mount.cifs options

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


  • username=username
  • user=username (same as username)
note this is different from the "Allow mounting by ordinary user" meaning this typically has.
  • uid=uid - for files where the server does not provide ownership, locally view files as this user (defaults to 0). Can be a UID or username.
  • forceuid - apply the above behaviour to all files on the share
  • gid=gid and forcegid are analogous to the above
  • domain= or dom=
(apparently not the same as prepending dom/ to the username(verify))
  • credentials= or cred=

permission stuff

  • perm (default), noperm - do local permission check (on top of the ACL check always done remotely)
  • file_mode=arg
  • dir_mode=arg
  • rw or ro

  • noacl - don't use POSIX ACL operations, even if the server supports them.
mostly relevant when target is samba, not windows?
  • nounix - disables the CIFS Unix Extensions, namely POSIX acls, POSIX locks, POSIX paths, symlink support and retrieving uids/gids/mode from the server.
probably only necessary to work around bugs in remote Unix Extensions behaviour

See section INODE NUMBERS for more information.

See also:

Getting windows to remember network logins

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Window shas a key/credential storage it can use - for things like domain logins, mounted drives, and such.

May cause lockout - when the actual password is changed, and the client doesn't prompt you if the stored one fails. Sometimes removing passwords makes things work again.

This is probably not horribly secure (anyone on your computer can use it)

In XP, run:

control keymgr.dll

(Also under Control Panel → User Accounts → Advanced → Manage Passwords)

In Windows 7, look for "Credential Manager"

Getting windows to forget current sessions

This is mostly relevant when you have authentication problems.

A recurring problem case for me is where after failed authentication (e.g. when the auth server didn't work at the time, or when you have the same username but a different password, or whatnot), it won't disconnect that failed session -- and because it always (re)uses one session, you now can't use or change that session.

You want to disconnect it, but there's no GUI way of doing so. In a command line (Win-R,
), run:
net use * /delete /y

This is the most brute-force way. You can specify the specific share, but * is a lot easier. I've seen people run this a bunch of times in sequence, probably to be more convincing to windows.

Authentication/encryption options

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Note that encryption is only about encrypted authentication -- content is never encrypted.

It looks like lanman security protocols come down to

  • LM (and LMv2?)
  • NTLM (now a.k.a. NTLMv1)
    • OS clients: WinNT, Win98, 2000, ME, XP (not in 95)
    • Servers: Samba in recent versions (which?), JCIFS ?

  • NTLMv2
    • Clients: Windows support since , enabled/default since Vista/7
    • Servers: Samba support since 3.3?
    • NTLMv2 may be referred to as 128-bit encryption, which only NTLMv2 can do(verify)
    • Better security than LM and NTLM(v1) -- but can only be used when everything involved supports it.

Beyond that you can as use Kerberos v5

If client and server can't agree on which to use, you'll see a NT_STATUS_LOGON_FAILURE in Samba logs.

It seems that by default, samba will allow all.(verify) Once you start messing with auth settings, you better know what you're doing.

NTLMv2 seems to also interact with the security= setting, in that

  • security=domain - works (verify)
  • security=server - doesn't work (verify)
  • security=user - ?


  • XP typically used NTLMv1 (or LM) (verify)
  • Vista and 7 use NTLMv2 by default. They will require it and reject all earlier variants (NTLM(v1) and LM), which is good for security but sucks for interoperability - it effectively locks itself out of many servers, NASes, embedded devices, and hosts with old configurations. You may not even see such hosts(verify), or get "The specified network password is incorrect" when you know it's correct.(verify)
    • you can allow the older variants in "Manage advanced sharing settings" (or is that only for sharing?))(verify) The settings to make windows more flexible seem to vary not only with windows version, but also its exact flavour (home, premium, whatnot). ( values (verify), and in the fact that the policy editor is absent from some)


  • supports NTLVv2 since 10.5 (verify)

Hiding certain files

...mostly for windows, which by default does not show hidden files (I personally always change that; I see these, but shaded)

hide files = /folder.jpg/Thumbs.db/*.tbn/

Blocking certain files by name

For example, to stop Macs from storing metadata and resource forks:

veto files = /._*/.AppleDouble/.DS_Store/

Linux client side

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Samba supports symlinks, but there are a bunch of details.

Seems to be tied to CIFS Unix extensions (as defined by HP[1])

It looks like symlinks are resolved to files on the server when those extensions are not supported (or off on a samba server), but are symlinks treated as such by the client when they are on(verify).


  • links within the exported tree are always allowed (and enabled by default - see follow symlinks)
  • links outside can be restricted (and there are differences between relative and absolute symlinks)

Relevant settings:

  • follow symlinks
    (share-level setting) allows you to enable/disable following of symbolic links. By default is enabled (symlinks are followed). No means more checks, so is slightly slower.
  • wide links
    (share-level setting) controls whether server-side links that are followed by the server will be resolved or blocked if they point outside the shared file tree. If enabled, symlinks can be followed to anywhere on the host (still due to file permissions, of course). Setting this to no means more checks so is slightly slower.
  • unix extensions
    (global setting)
    • some clients work better when not trying to use these extensions
    • in this context it mostly matters that it allows links (and also allowing clients to create symlinks on the server)

Wide links used to be enabled by default, but since a 2010 security update it is disabled by default, and also automatically disabled if you have unix extensions enabled (also default). (The reason for this change is that it's a potential security problem to both be able to have both host-wide symlink following and the ability of clients being able to create symlinks on the host - you could go path guessing. It means that admins need to lock down the filesystem before even thinking about enabling this.)

"Bad access attempt: /some/path is a symlink outside the share path"

...and, more to the point, your current configuration does not allow the server to follow symlinks that point outside of the shared path.

The immediate setting you care about is wide links (share-level) (...also follow symlinks, but it's on by default, and you'll probably notice having specifically disabled it). See also #symlinks

If your problem is that things stopped working (in 2010) you're probably seeing the new defaults from the the security update mentioned above. if you use and need wide links, you'll probably want to set unix extensions=no - and of course set wide links=y on the shares where you want it, because its new default is disabled.


(Most of this has to be verified:)

  • add lfs to smbmount to support writing files larger than 2GB (a client thing?)

  • Samba mounts (as well as NFS) may be broken after hibernation. Apparently, you can avoids this by making the hibernation umount these shares before (and remount them after resuming) This is something your distro should probably fix.

  • "Domain server" is ambiguous and can refer to two things samba can act as
    • "windows 9x workgroup Domain server" or
    • "NT Domain server"
    • Both domain servers can be both(verify):
      • "Local master browser", is the node on a subnet that manages what response there is to network browsing.
      • "Domain Master Browser" collates lists between SMB nets. You may already have a PDC doing this.

To sync a browse list with a master browser (by IP or the subnet it is in)

remote browse sync =

Announce to what end?

#usually to a whole subnet
remote announce = 
  • PDC: Primary Domain Controller.

You can do things like be an LDAP-backed domain controller and more, roaming profiles on both 9x and NT-style windowses, PAM authentication, on-the-fly homedir creation and more.


  • Text
    • smbclient
  • Graphical:
    • KDE: smb:/
    • Nautilus: smb:///
    • Smb4K


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Some name types

0x00 WORKSTATION       (advertized by all NetBIOS/SMB hosts)
0x20 SERVER            (when serving anything - usually file server)
0x1B DOMAIN_MASTER     (domain master browser, DMB)
0x1C                   (Domain controllers)
0x1D MASTER_BROWSER    (local master browser, LMB),
                        related to __MSBROWSE__, browse lists

Different requests may/must be point-to-point (unicast) or broadcast:

  • A workgroup exists when there is a LMB for it (on the subnet)
  • LMBs must be broadcast for (WINS/nmbd will not store 1D names)
  • DMBs must be resolvved via nmbd/WINS (broadcasting will will not work)
  • ...but note that LMB and DMB are regularly the same thing.

See also:

Samba URLs

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed

(In windows as a client)

Usually actually means "Even though I just asked you for a login / you just tried 'connect using a different user name', it can't have worked because there is currently another session to that server"

Windows uses one session to a SMB host, and SMB supports only one user per session, so windows can use only one login per host - at a time. You cannot use a different username/password until you disconnect all sessions.

Which means this is also about timing - the first user/password combination that is used will apply while the connection/session lasts. Existing sessions regularly come from current (or past) network drive maps.

Possible workaround include:

  • See whether you can avoid the need for multiple sets of credentials to the same server (if this applies, disconnect all before connecting as the user you want to use)
  • Disconnect any current sessions before trying another
    • use any explorer window → Tools menu → Disconnect Network Drive, OR
    • via the command line using
      net use
      to shows you the mounts, andsomething like
      net use N: /delete
      to remove one or
      net use * /delete
      to remove all.
  • Since windows uses unique logins per host, you can cheat by pretending one host is multiple hosts -- accessing the server once by IP, by aliased names, or even using aliased IPs.

See also:

Hanging samba

In some cases, samba may hang on share access. This seems to be caused by having previously had some connectivity errors.

Programs seem to lock on this, usually on stat()-ing a samba mounted entry (most programs and OS file operations stat before they do other things).

When I try to unmount, it tells me it's busy; when I try to force an unmount:

umount2: Device or resource busy
umount: //hostname/data: not found
umount: /mnt/data: Illegal seek

I don't know what's wrong, exactly. Perhaps a lsof/fuser may help diagnose, but I haven't seen this problem happen in a while.

"Network name cannot be found"

Unless you the IP variant (and DNS-based names), and you get this error on all share re-mounting and/or browsing, then NBNS probably is not working.

If it happens selectively on shares, look at your logs. It may be that the underlying directory does not exist, or that the permissions do not allow samba to access it.

"Can't become connected user!"

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

This seems to have multiple causes and be multiple similar errors, at least:

  • one from smbd/service.c:make_connection that means you can't log in at all, and the next log message will probaby say so.
The reasons seem related to authentication setup, client and/or server capabilities/policies(verify).
  • one from smbd/service.c:make_connection_snum, which usually means everything works, but apparently indicates the (transparent background re)connection falls back to something that works.

"The alias ... can't be opened because the original item can't be found"

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

A general OSX error message. If this happens for accesses on (already mounted) network shares, this is likely because the server stores (sym)links, and OSX is trying to support CIFS Unix extensions, leading it to resolve symlinks on the wrong system.

Apparently this cannot be disabled in OSX, so the easiest fix is to instruct the server to globally disable unix extensions:

unix extensions = no

...though this may not be an option for you as you may rely on other features from those extensions.

(Note this error may appear in other contexts, in which case the above diagnosis and solution may not apply. For example, if it happens on login, it's probably related to connection encryption(verify))

client mount error only from specific hosts

mount error(13): Permission denied

and, with some options

mount error(5): Input/output error

The weirdness for me was that this worked on all but one workstation.

This turned out to be that the workstation was running the most recent kernel (4.13), which changed the defailt dialect to 3 (/ highest agreed?(verify)) (dmesg mentioned "No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.")

...combined with that it required the domain for the server to actually authenticate me against LDAP. So where I had:


the following worked (also for most other versions, but it and I seem less confused when I add it):


NT_STATUS_NO_SUCH_USER from some clients=

This can mean the authorizing client does not specify a realm/domain (and others do, implicitly or explicitly), which means the server won't look in it, so won't find that user.

from some clients, with identical fstab

It seems that e.g. the *nix CIFS mounter can pick up the realm/domain from network config (verify). So only when it's not configured there do you need to explicitly add it to the mount options:


create_connection_server_info failed: NT_STATUS_ACCESS_DENIED

Has various specific causes.

Set the auth loglevel to 2 or higher and look for the more detailed error that precedes this one.

In my case, that error was:

user 'username' (from session setup) not permitted to access this share (ipc$)

...and the reason for that was that I had a valid users list on ipc$ (...that didn't include this particular user).

mount error(5): Input/output error

Can be various things. Things to try include:

  • vers=3.0
  • If domains are relevant, specify domain=domname instead of as part of the username

mount error(13): Permission denied

Likely means 'authenication failed'

I mostly get this wrong in the context of domains, not authenticating with a domain (or the right one). In that case, add
to the mount options.

Another possible reason is that the security mode is a more restricted set on the server end, and the one yo use is disabled. This most often happens when client or servers aren't exactly the most recent. (e.g. one end doesn't speak ntlmssp, or one end has disabled ntlm)(verify)

mount error(127): Key has expired

Seems to usually mean the password has expired. In which case logs will mention

Status code returned 0xc0000071 STATUS_PASSWORD_EXPIRED

The server, if samba, will mention something like:

domain_client_validate: unable to validate password for user username 
in domain DOM to Domain controller Error was NT_STATUS_PASSWORD_EXPIRED.

auth retries

Oplock break failed for file

What the different [username] -> [username] are in check_ntlm_password lines

Yet to read


Microsoft has DFS, Distributed File System.

There are two distinct parts:

  • logical namespace
shares on different hosts are exposed under the same namespace
  • file replication
A share can be backed by multiple servers, and the replication copies new files on one to others

They are tied to AD, and the mentioned namespace and shares are stuck on the domain name rather than a server name.

As of this writing (now a while back), none of that is done by samba except the share redirection, meaning the only real use is having multiple samba servers serve the same content (and even then, locking might be a a problem).

See e.g. [2]

If you want proper Dfs, look at wan accelerators, or perhaps a full-blown windows server setup.