SMB, CIFS, Samba, Windows File Sharing notes
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.
Versions
SMB/CIFS, not being open standards, works out as a de-facto standard, or rather a bunch of them with some interesting history.
Samba considers itself an interoperability thing between *nix and windows (file sharing, printing, active domain),
but to many people it is primarily just the *nix implementation of SMB, spanning most features from most SMB versions.
(even for the most recent versions the mounter is still called mount.cifs, but it'll negotiate the best version both sides support - perhaps it never got renamed not to break things? perhaps people though of CIFS as meaning 'newer SMB' for a long time? not sure.)
Some history The original protocol is SMB, from IBM and around the late eighties. We can retroactively call this SMB1.
This was updated/extended for OS/2 and NT, by IBM and later MS (who called it "SMB version 2" (which is not SMB2) and "CIFS" (verify))
CIFS was a rename by Microsoft and SNIA (~1996?), and refers to the NT4 implementation, which was a bit of an update to core SMB1. But from today's view, SMB1 and CIFS are equally old and outdated.
(Note that later, we have CIFS being used to variably mean 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.)
There were some 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 in microsoft and samba docs and code.
There was some attempt to make it an open standard, which didn't pan out.
Since the windows implementation is the easiest measure of 'is your implementation compatible with things?', effectively Microsoft now controls SMB protocol.
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 VistaSP2, server2008, Samba ~3.6
- scales better, has better async, larger read/write buffer, all leading to noticably better performance
SMB2.1
- since Windows 7; server2008r2
- mostly some performance features(verify)
SMB2.2 seems to have effectively been a beta for 3.0(verify)
SMB3.0
- added failover, encryption, multichannel, DRMA
- has been around long enough that you can demand it now
- Since ~Windows8, server2012, Samba 4
SMB3.02
- since ~Windows8.1, server2012r2
SMB3.1 (and 3.11?(verify))
- Since ~Windows10, server2016
SMBX:
- Apple adopted SMB by taking adopting Samba and focusing on SMB2.
- ...but when Samba switched licenses, Apple decided to switch to their own flavour, called SMBX.
See also:
- mount.cifs man page
- smb.conf man page
On the protocols and ports
Transports
Modern versions all run directly over TCP. (this has a few footnotes, mostly due to NetBIOS history, but relatively few).
SMB1 worked on top of a NetBIOS layer, and usually over IPX.
Yes, you can get that style to transfer through IP. In a few different ways, even, but all of them have so many footnotes that you really don't want this, unless maybe for a specific retro-computing project.
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.
On name resolution and network browsing
NetBIOS's name service is called NetBIOS Name Service (NBNS).
Which is a more general thing than samba.
And since basically nothing uses native NetBIOS anymore, when we say NBNS we now often actually specifically mean NBNS as part of NBT (NetBIOS over TCP/IP).
See also RFC 1001 and RFC 1002.
Samba's implementation is called nmbd,
Microsoft's is WINS.
NBNS
- looks at a resolution cache
- expires on the term of minutes
- looks at LMhosts, analogous to the hosts file
- 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 if configured; clients that have one set up will register and query there
- sends and listens to broadcasts
- since WINS servers are not very common, this fallback to broadcasts is common (and are still a fallback when one is configured)
- (...which is why NBNS has been been likened to drunk people in a dark room trying to communicate by shouting. On larger networks, you want to contain that as much as you can :)
(semi-sorted)
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 implies "become server", OR
- refer to an existing WINS server, wins server = 192.168.3.1 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
Browse list - lists the workgroups and nodes currently (or at least recently) available.
Browser master - a node that keeps track of the browse list, known to clients to be doing that
- On a network with a browser master
- nodes broadcast their presence, which the browser master collects
- nodes wanting to look up query the browser master
- clients may use that for their own caches -- so changes may still take a while to propagate (verify)
- on a network without a browser master
- clients falls back on broadcasting "who's there" questions, which
- clients will not give up quickly, assuming a node response may take a while, so non-existing names will take some time to say "nope"
- on large setups all these broadcasts can flood the network
- clients falls back on broadcasting "who's there" questions, which
Some clients also use this list to show neighbouring nodes, which is faster, and sometimes more stable, than broadcasting continuously (though it may not notice new nodes as quickly).
You can make servers on multiple subnetworks exchange browse lists - though it's mostly admins managing larger networks that need to think about this.
This makes sense when clients can unicast to these other subnets fine - but firewalls block broadcasts from always going to all of your large network
While setting this up involves some study, it makes the network much quieter without losing any functionality (at most some delays in resolving newly joined hosts).
Exactly which node is a browser master (and you want exactly one) is not so important, beyond it being an always-on server. 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.
Notes:
- 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 192.168.1.255." (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).
See also:
- http://samba.org/samba/docs/man/Samba-HOWTO-Collection/NetworkBrowsing.html
- http://www.comptechdoc.org/os/windows/ntwsguide/ntwsnfinding.html
- http://technet.microsoft.com/en-us/library/cc767893.aspx
- http://teamapproach.ca/trouble/Browser.htm
- http://www.duxcw.com/faq/network/brreq.htm
- http://en.wikipedia.org/wiki/NetBIOS
On Samba security
Serving subnets, and IP-based access control
By default, samba serves on all broadcast-capable interfaces available at process startup (except 127.0.0.1), using their configured IP/subnet details.
To serve only specific networks or subnets specify what you want to serve on:
# "instead of binding on 0.0.0.0 (a.k.a. ALL), use..." bind interfaces only = True interfaces = 192.168.1.0/16 127.0.0.1 eth1 133.133.133.133/30 #an interface name implies use of its current configuration
Additionally 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 secure idea):
hosts deny = 10. # or the synonym, 'deny hosts'
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: 133.133.133.133
- Subnet by bitmask value: 133.133.133.133/255.255.255.248
- Subnet by bitmask width (CIDR style): 133.133.133.133/30
- Subnet by octet omission: 127. or 192.168. or 10.
The 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)
user
(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,
- ...except you can still functionally fake those, e.g. by saying that logins with non-existing users map 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, public) 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]).
server
- 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
- (Snoopable?(verify))
domain
- 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 net utility)
- Still requires a mapping to unix usernames
ADS
- Much like domain (verify)
- 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
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)
Backends
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 I've worked with well-known LDAP software that behaved terribly)
smbpasswd
(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 smbpasswd 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.
tdbsam
(currently the default)
Similar to the smbpasswd backend, but uses a different file (passdb.tdb) which is a simple binary file-based database.
ldapsam
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.
mysql
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.
others
...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
- permissions
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$
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) even when not 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
net
Domain controllers
Other/notes
password level and 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.
Global
Basics
[global] 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 net (verify).
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.
Tweaking
Resolving
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.
Logging
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.
Generally/roughly:
- 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
Syslog:
# 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 logging is a newer, more precise way of doing both of the above, and it deprecates syslog.
A minimal share definition looks something like
[sharename] path = /data/directory/to/share
Notes:
- 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.
Notes:
- Using read list or 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)
Printing
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
Disabling
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
Client's...
%a architecture (e.g., Samba, WfWg, WinNT, Win95, UNKNOWN) %I IP address %m NetBIOS name %M DNS name
User:
%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
Share:
%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
Server:
%d process ID %h DNS hostname %L NetBIOS name %N home directory, from automount map %v samba version
Other
%R SMB protocol level %T date and time
Config file check
Running testparm 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
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
Client-wise
Name resolution
Initial connection slow
(windows)
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
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\RemoteComputer\NameSpace\
and remove:
{D6277990-4C6A-11CF-8D87-00AA0060F5BF}
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:
{2227A280-3AEA-1069-A2DE-08002B30309D}
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
Unsorted (speed)
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.
Semi-sorted
Clients
mount.cifs options
Auth
- 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:
- https://www.samba.org/samba/docs/man/manpages-3/mount.cifs.8.html
- https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-nfs-client-config-options.html
Getting windows to remember network logins
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, cmd.exe), 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
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
Windows:
- 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). (...in values (verify), and in the fact that the policy editor is absent from some)
OSX:
- supports NTLVv2 since 10.5 (verify)
Hiding or blocking certain files
hide files
- will list these files in directories
- they'll accessible as usual, but things like Windows Explorer will hide them (unless it's configured to show them).
Example:
hide files = /folder.jpg/Thumbs.db/*.tbn/
veto files
- blocks clients from creating new files/dirs matching this pattern
- makes existing files/dirs matching this pattern neither visible nor accessible
Example, to stop Macs from storing metadata and resource forks:
veto files = /._*/.AppleDouble/.DS_Store/
veto files introduces some edge cases, like that a client trying to delete a directory that contains only veto'd files will fail - which in many cases is the safe thing to, because when you override this (which you can) clients wouldn't know what files they are implicitly deleting.
It's a thing you can decide based on the value of veto files.
Linux client side
symlinks
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).
Apparently:
- 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.)
...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.
...so 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.
Unsorted
(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 = 192.168.3.25 192.168.5.255
Announce to what end?
#usually to a whole subnet remote announce = 192.168.3.255
- 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.
Clients:
- Text
- smbclient
- Graphical:
- KDE: smb:/
- Nautilus: smb:///
- Smb4K
Names
Some name types
0x00 WORKSTATION (advertized by all NetBIOS/SMB hosts) 0x03 CLIENT 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 0x1E BROWSER 0x01 UNKNOWN
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
- (unofficial draft)
- Looks like smb://[[[authdomain;]user@]host[:port][/share[/path[/name]]]][?context]
- implementation in libsmbclient, others; support in MacOSX, Unices (Gnome, KDE), no support in Windows (only its own UNC style there)
- See also:
Problems
(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 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"
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:
ro,noauto,username=me
the following worked (also for most other versions, but it and I seem less confused when I add it):
ro,noauto,username=me,domain=mydom,vers=3.0
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:
domain=something
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 domain=mydomain 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 side logs will mention something like
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 f.q.d.nl. Error was NT_STATUS_PASSWORD_EXPIRED.
auth retries
Oplock break failed for file
SMB has an oplock mechanism (basically required in SMB2 and SMB3).
This lets the server mediate locks,
allowing clients to cache contents locally, either for just repeated reads,
or for exclusive read/write access that doesn't have to go directly to the network.
Clients that come in later can ask the server to request a release from the first client.
In some specific situations this is quite positive for the response time of IO operations (because local).
The oplock protocol isn't very robust against e.g. clients leaving silently (e.g. when clients crash),
which can lead to the case where oplock release requests pile up, and will only be served when the server considers the first client to have timed out.
You sometimes want to micro-manage things, e.g. decide that lower performance is worth avoiding these halts happening, on specific files, shares, or in general.
There is various relevant samba config
- locking - allow byte-range locking
- strict locking - denies access when there is any byte-range request in it
- oplocks - allow local caching via oplocks
- level2 oplocks - allow degrade into read-only locks
- veto oplock files - what files not to oplock (and thereby not to cache either)
Things that can help:
- use keepalive sockets, should notice clients that went away sooner
- disable oplocks
- if you think it's because of an old dialect that can't communicate this well, upgrade samba
- deadtime helps in most (but not all) cases - inactivity after which connection is close
- applies only when no files or lock are open(verify)
- keepalive (defaults to 300 (seconds))
- applies always, so can catch crashed clients better than deadtime (verify)
- note that you can get similar behaviour via socket options
https://www.samba.org/samba/docs/using_samba/ch08.html
What the different [username] -> [username] are in check_ntlm_password lines
Yet to read
- http://www.huihoo.com/download/samba/samba_howto_collection.html
- http://tech.canterburyschool.org/tech/ServingWindowsWithSamba
- http://www.nyetwork.org/wiki/Samba
- http://lists.samba.org/archive/samba/2003-December/077198.html
- http://gbarbier.free.fr/prj/dev/#nmbscan
DFS
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.