View source for SMB, CIFS, Samba, Windows File Sharing notes

{{#addbodyclass:tag_tech}}
{{Hosting stuff}}


'''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.

{{comment|(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.

{{comment|(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:
* http://ubiqx.org/cifs/SMB.html

* https://www.samba.org/~sfrench/presentations/smf-linux-collab-summmit-future-of-file-protocols-smb2.2.pdf

* https://wiki.wireshark.org/SMB2

* https://blogs.technet.microsoft.com/josebda/2013/10/02/windows-server-2012-r2-which-version-of-the-smb-protocol-smb-1-0-smb-2-0-smb-2-1-smb-3-0-or-smb-3-02-are-you-using/

* mount.cifs man page 

* smb.conf man page

<!--
https://wiki.samba.org/index.php/LinuxCIFSKernel
-->

=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.

<!--
SMB has been encapsulated in various protocols. It has e.g. been seen as:
* NBX: SMB on IPX  (combination also called NBX)
* SMB on NetBIOS, on NetBEUI
* SMB on NetBIOS, on TCP, on IP  (combination also called NBT)
** Which can do without some of the NetBIOS stuff - can e.g. use names from DNS and avoid NBNS.
* SMB on TCP {{verify}}

When choosing between TCP/IP only and NetBIOS, it used to be that windows would force your hand: 2000, 2003, XP, Vista, and 7 support NBT, but 95, 98, ME, NT rely on NBX, meaning that you would probably use both.
-->


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
** {{comment|(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.

<!--
To see what interfaces/ports your samba is serving on right now, look at the output of 
 sudo netstat -pnaut | egrep '(smbd|nmbd)'
-->

=On name resolution and network browsing=
{{stub}}

[[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 [https://www.samba.org/samba/docs/current/man-html/nmbd.8.html nmbd], 
Microsoft's is [https://en.wikipedia.org/wiki/Windows_Internet_Name_Service 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 <tt>/etc/samba</tt> or <tt>/usr/local/samba/lib</tt>

: 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)
:: {{comment|(...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 :)}}


<!--
http://www.techrepublic.com/article/how-netbios-name-resolution-really-works/


These days you have the option of skipping NetBIOS as a transport, and rely on IP for name resolution.

Anything that is communicated via SMB uses NetBIOS names internally, usually synced with the DNS names.


NetBIOS name lookups are sent to the NetBIOS nameserver (if known), and/or broadcast.
As such, apparent behaviour differs when such a server is or isn't known.{{verify}}

NetBIOS participants must register with a unique name - of at most 15 characters.
The same packet also informs you of the node type.

Since NBT works over IPs, you can use NBNS, ''or'' choose to use an existing DNS setup for host naming.

If you use CIFS over TCP/IP (recent windows, and/or a so-configured Samba) you can choose to deal only with IPs, DNS, and completely avoid NetBIOS names and its nameservice.
-->

<!--
 nmblookup '*'   #looks up all names in broadcast range
-->



==(semi-sorted)==
{{stub}}





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:
* {{inlinecode|<nowiki>wins support = yes</nowiki>}}, which implies "become server", OR
* refer to an existing WINS server, {{inlinecode|<nowiki>wins server = 192.168.3.1</nowiki>}} 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


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 <tt>nmblookup -M somenode</tt>. It will say something like "querying mbserver on 192.168.1.255." {{verify}}

* {{inlinecode|<nowiki>local master = no</nowiki>}} opts you ''out'' of a browser election

* {{inlinecode|<nowiki>preferred master = yes</nowiki>}} 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 {{inlinecode|<nowiki>domain master = yes</nowiki>}}, particularly if there is no windows domain controller around. {{verify}}


* {{inlinecode|<nowiki>domain logons = yes</nowiki>}} 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'
<!--
Probably the simplest is an "allow these nets, deny all others" setup:
 hosts deny = ALL
 hosts allow = 192.168.1.0/24 127.
-->

Note: Using <tt>interfaces</tt> is network-level in that you don't listen to some things, while using <tt>host deny</tt> 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.

==security models (security=share, user, and such)==
The {{inlinecode|security <nowiki>=</nowiki> ''something''}} setting sets the basic security model, which mostly controls how and when connection authentication will be handled.

It also affects the user mapping. 

{{comment|(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 <tt>map to guest = Bad user</tt>, 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 <tt>guest ok=yes</tt> used globally in a security=user setup, so if that made sense it suggests the former)

===share===
(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 {{inlinecode|<nowiki>guest ok=yes</nowiki>}} (and its functional synonym, {{inlinecode|<nowiki>public</nowiki>}}) because in this case the server maps you to what you have set as the {{inlinecode|guest account}}

* With passwordless (<tt>guest ok</tt>) use, user mapping is complex and somewhat unpredictable. Basically:
** using only <tt>guest ok=yes</tt> 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
** <tt>guest ok=yes</tt> plus <tt>guest only=yes</tt> means forced mapping to the <tt>guest account</tt> (a global setting pointing to a unix username <small>[which is probably loginless]</small>). 


===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 {{comment|(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 {{inlinecode|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:
* {{inlinecode|only guest}} is synonymous with {{inlinecode|guest only}}

* While there are details in behaviour, <tt>server</tt>, <tt>domain</tt> and <tt>ADS</tt> 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: <tt>password server = ''first'' [''fallback'']</tt>, 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==
{{stub}}


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.
{{comment|(you ''could'' do a bunch of script-fu to get very close, though)}}


====Backends====
{{stub}}

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 {{comment|(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 <tt>/etc/samba/private/smbpasswd</tt>). 

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



Not to be confused with the {{inlinecode|smbpasswd}} ''executable'', which can update this file, and apparently also tdbsam{{verify}}. Its main uses:
* {{inlinecode|<nowiki>smbpasswd olduser</nowiki>}} changes a password
* {{inlinecode|<nowiki>smbpasswd -a newuser</nowiki>}} adds a user, and essentially ''assumes'' it already has a unix account
* {{inlinecode|<nowiki>smbpasswd -d user</nowiki>}} disables a user. Re-enable with {{inlinecode|smbpasswd -e}}.
* {{inlinecode|<nowiki>smbpasswd -x user</nowiki>}} removes a user from smbpasswd file.

=====tdbsam=====
'''(currently the default)'''

Similar to the smbpasswd backend, but uses a different file (<tt>passdb.tdb</tt>) 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.


<!--
You can store the password used to login to the LDAP backend using:
 smbpasswd -w ''password''
(the implied DN is implied from what?)

You would probably set
 add user script
 add group script
 add user to group script 
 delete user script
 delete group script
 delete user from group scrip
 set primary group script
 add machine script
...to point to the respective smbldap-tools executables.

-->


=====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




<!--
http://www.informit.com/articles/article.aspx?p=422302&seqNum=4&rl=1
-->

===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...

<!--
* You can also define groups, but that mostly just makes samba-level permission details simpler.
-->


===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 <tt>force user</tt>'s effect.

===guest, IPC$===
{{stub}}

'''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 <tt>IPC$</tt> 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 (<tt>TMPDIR</tt> if it is in the environment, otherwise <tt>/tmp</tt>{{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<!--, using something like:
 [ipc$] 
 guest ok = yes
 valid users = @samba
 hosts allow = 192.168.1.0/24 127.0.0.1
 hosts deny = 0.0.0.0/0-->



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===
====<tt>net</tt>====
{{stub}}


====Domain controllers====
{{stub}}

<!--
A PDC is a primary domain controller, a BDC is a backup domain controller.

'Backup' should perhaps be called 'additional'.
Every domain forest should only have exactly one PDC, but many BDCs can be used, for example in department subnets that divide large networks.


PCDs and BDCs have a few jobs:
* They are browser masters
* they may provide logon features for windows clients


You'll need a domain name. Set:
 workgroup = domainname
-->



<!--
Browser masters keep track of the nodes. 
* BDCs (local masters) -  do this for their own subnet, 
* PDCs (master browsers) mark themself as such for their workgroup, causing local masters to report their partial lists and fetch the merged browse lists from this.


 #participate in elections
 local master = yes
 #good chance
 os level = 65

 #prefer self as master, trigger election on startup
 preferred master = yes

 #become PDC/master browser, not just BDC/local master
 domain master = yes

 #provide domain logon features (see also below)
 domain logons = yes
 #(this technically implies domain master=yes)
-->


<!--
passdb backend = ldapsam

Note: You usually want security=user, since share is generally out of favour, and a domain controller being a domain client makes little sense.



The idmap feature maps windows [[SID]]s to unix uids/gids. When you have only a single samba server, the defaults behaviour of a purely machine-local mechanism works fine.

When when you want windows and unix identities consistent across multiple servers (and/or mix domains), you need some trickery.
One solution is to use NSS to use LDAP as a backend for user information, and use winbind to handle the creation of SID to UID/GID maps in that LDAP backend. You also usually give it a range od uids and gids it can use - that are free on all participating hosts.


Tell smbldap about the LDAP structure, using:
 ldap suffix = dc=example,dc=com
 ldap machine suffix = ou=People
 ldap user suffix = ou=People
 ldap group suffix = ou=Groups
 ldap idmap suffix = ou=Idmap
 ldap admin dn = cn=Manager,dc=example,dc=com










printing = cups


 #Attempt to make windows' ACL inheriting work
 map acl inherit = Yes
 

-->


<!--
Things you can do for clients
 #advertize yourself as a time server (for windows clients)
 time server = yes



Windows login scripts depend on telling the client to do domain logons. When you do, you can use:

 logon path = \\%N\%U\profile
%U is the session username, %N is the NIS home directory server (or, without NIS support, the server name. %L is the server name.

There is also a <tt>logon home</tt>, which allows <tt>NET USE H: /HOME</tt>


 logon drive = X:
The drive that your profile is mounted on

 logon script = scripts\logon.bat
Path to the script that should be run at login time. Path should be relative to the [netlogon] service. (which should obviously not be writable)


To syncrhonize the local time with a specific server time {{comment|(you can also synch with domain (its PDC), the configured NTP server (if any), and an TRS domain)}}:
NET TIME \\SERVERNAME /SET /YES




-->

==Other/notes==
{{inlinecode|<nowiki>password level</nowiki>}} and {{inlinecode|<nowiki>username level</nowiki>}} 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.


{{inlinecode|<nowiki>map to guest = never</nowiki>}} 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, {{inlinecode|<nowiki>null passwords = no</nowiki>}}, 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 <tt>/etc/samba/smb.conf</tt>, 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 <tt>/etc/xinetd.d/swat</tt> 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
 }
<tt>user</tt> is the effective user. Make this the most restricted user that can edit <tt>/etc/samba/smb.conf</tt>, 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 <tt>/etc/init.d/xinetd reload</tt> to restart xinetd with swat enabled {{comment|(your distro may require you to do more work than that; you'ld have to check with it)}}, and point your browser to <tt>http://localhost:901</tt> (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, <tt>workgroup</tt> is the the workgroup to show in the browsing list.

With <tt>security=domain</tt> this is the NT domain, and has stricter requirements such as that you need to join it using {{inlinecode|net}} {{verify}}.

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

====encrypt passwords====
<tt>encrypt passwords</tt> 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===
<!--
{{inlinecode|<nowiki>netbios name = something</nowiki>}} overrides the default of using the node's  hostname
-->

====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 <tt>max log size</tt> (in kilobytes) much higher.


You can log things per share or machine by using %S and %m in the <tt>log file</tt> 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:

<syntaxhighlight lang="python">
# 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
</syntaxhighlight >


Syslog:
<syntaxhighlight lang="python">
# 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
</syntaxhighlight >



Note that {{inlinecode|logging}} 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
 [sharename]
 path = /data/directory/to/share
 
Notes:
* To not list a share in browsing, set <tt>browseable = no</tt>. (Disables listing it, has no other effect on access)
* To add a user friendly name for browsing, add <tt>comment = Big data directory</tt>.


===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 <tt>invalid</tt> override those <tt>valid</tt> (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 {{inlinecode|read list}} or {{inlinecode|write list}} will not imply putting these users in {{inlinecode|valid list}}

* The <tt>write list</tt> overrides the <tt>read list</tt> 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==
{{stub}}

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

<!--
http://www.gentoo.org/doc/en/quick-samba-howto.xml
-->

===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 <tt>[global]</tt> 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  {{inlinecode|testparm}} will give you warnings and errors about the basic setup of your <tt>smb.conf</tt>


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


<!--
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)


The rlimit thing is actually the max open file descriptors. The value above, 1024, is also what
{{inlinecode|ulimit -n}} reports. 
If you want to change this edit:
 /etc/security/limits.conf
to contain something like:
 *               -       nofile          16385

-->

=Speed tweaks=
{{stub}}


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 [http://freshmeat.net/projects/netio/ netio] or [http://ftp.arl.mil/~mike/ttcp.html ttcp]. ({{comment|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.


<!--
Many involve:
* TCP windows: 
** Note: In recent kernels, '''autotuning probably works better than setting your own values''', so '''do ''not'' add these''' http://www.kernel.org/doc/man-pages/online/pages/man7/tcp.7.html
** But in case you want to compare, try 8196 for both of these - they seemed to regularly give the highest speed: (though I don't know under what assumptions/conditions)
** <tt>SO_RCVBUF=8192</tt> - This and the following may give marginal speed increases. Setting this too high may ''lower'' performance
** <tt>SO_SNDBUF=8192</tt> - Setting this too high seems less problematic. Setting it below 4K is probably a Bad idea.

* <tt>TCP_NODELAY</tt> to disable Nagle's algorithm (see [[Networking_notes_-_Layer_3_(IP_mostly)#TCP_NODELAY_and_Nagle.27s_Algorithm|Networking notes]]). Since we mostly have bulk transfers, it ought not to matter much even in theory.

* IP Type Of Service (IPTOS) options like IPTOS_LOWDELAY (or IPTOS_THROUGHPUT?) ''may'' sometimes help, but only with TOS-aware routers, and traffic shaping if you use it (even if only for TOS and not throttling). They probably won't do anything in your home LAN, and ''may'' not help in company networks, but can't really hurt either
-->


<!--
Linux

# increase TCP max buffer size setable using setsockopt()
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

http://www.cyberciti.biz/faq/linux-tcp-tuning/


BSD:
www.freebsd.org/cgi/man.cgi?query=tuning&sektion=7
http://www.freebsd.org/cgi/man.cgi?query=tuning&sektion=7



See also
* http://www-128.ibm.com/developerworks/linux/library/l-hisock.html
http://www.psc.edu/networking/projects/tcptune/



Windows

In Win2K/XP and later, you can tweak delayed acknowledgements (for all TCP connections, per interface) in the registry:
* TcpAckFrequency: DWORD: number of outstanding acks that will trigger them to be sent (regardless of whether the timer expired or not) Default is 2
* TcpDelAckTicks: DWORD: 0 to 6, units of 100ms. Default is 2 (200ms)

To disable delayed acks, set TcpAckFrequency to 1 and/or TcpDelAckTicks to 0, for a particular interface (HKLM\SYSTEM\CuttentControlSet\Services\Tcpip\Parameters\Adapters\ and then take an educated guess which GUID represents the connection you want (you can usually tell by the configured IP)).

See also:
* http://support.microsoft.com/kb/328890
* http://support.microsoft.com/kb/321098
http://support.microsoft.com/kb/299357 
-->

===Samba network settings===
<!--
There are many suggestions around, but a bunch of them are wishful thinking - few have really noticeable impact, and some are very context dependent.


: '''<tt>socket options</tt>'''



: '''Others'''

* <tt>write cache size</tt> to use a writeback cache for incoming writes.
** Can be useful when your storage is many-disk and/or large-stripe RAID. Otherwise probably not so interesting.
** In bytes. Per transfer/file, but with a maximum (related to oplocks?)
** People seem to like values on the order of 262144 (shouldn't that be somewhat higher?{{verify}})
** Considered semi-deprecated, at least at the time. Seems it may stick around.
** (insert generic "writebacks are bad without battery backup" warning here)



Questionables:
* <tt>large readwrite = yes</tt> (default), (or <tt>= no</tt>, apparently in environments that don't really support them yet?)
* <tt>read raw = yes</tt> and <tt>write raw = yes</tt> used to cause problems for some old clients. Now worth it to enable? 

* <tt>max xmit</tt>, the maximum ''negotiable'' packet size. The default has changed between samba versions; it can be can be 65535 (also the maximum value) or 16644 (possibly other values?). Sometimes ''lowering'' this can speed things up{{verify}}, though values below 2K will probably cause problems.


I need to wade through everything some time to give more value to them than anecdote.

<!--
https://www.physiol.ox.ac.uk/Computing/Online_Documentation/using_samba/appb_02.html

aio read size, aio write size: 
* if Samba has been built with asynchronous I/O support 
* aio will be used if the value is at least this amount of bytes


-->



<!--
==Readahead===

 vfs objects = readahead
-->

==Client-wise==

<!--
Note that if your (unix name mapping) configuration implies that multiple people share a server-side process, any time they use the server concurrently they'll notice slowness.{{verify}}
-->


===Name resolution===
{{stub}}
===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) {{comment|(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


<!--
=====Subversion=====
Programs such as TortoiseSVN checks directories for the metadata that marks it as a working copy. 
This only causes fstats, which are relatively light, but still take some time.
-->

==On client caches==
<!--

tl;dr:
* CIFS's own cacheing uses the page cache (i.e. RAM).
: you can get it to be more aggressive, but under certain cases this does nothing, and in certain cases it's dangerous

* You can also get it to use FSCache (which is an on-disk cache).
: (install and configure cachefilesd,  and add fsc to the cifs mount options.)
: roughly the same coherency limitations apply, though{{verify}}


First, read the CACHE COHERENCY section of the mount.cifs man page (and note it applies to both{{verify}}).

The short of it: when multiple clients have the same file open, and at least one is writing, you ''fundamentally'' need some type of locking to do correct reads as well as cacheing. 
In SMB, this is done via [[Locking,_data_versioning,_concurrency,_and_larger-scale_computing_notes#Opportunistic_locking|oplocks]]

The '''cache=strict''' option means the client reads from its own cache ''only'' if it holds an oplock for the given file - if not, it reads from the server directly. (writes are buffered when it holds an exclusive oplock, otherwise they go directly to the server)

(when/how are oplocks requested?)


The '''cache=loose''' option loosens those semantics: Without an oplock it'll remove cached data when it notices mtime changes (which isn't always on time), and will flush soonish after a write (which isn't always on time). Depending on what you're doing, it can lead to inconsistent cache data and, if you use that to base further writes on, inconsistent server data.

Under certain types of loads it will be fine, e.g. read-only shares, and while all clients are read-only{{verify}}
and will be faster when no oplocks are used. 


'''What about practice?'''

Since 3.7 kernels, cache=strict is the default. Before then it was loose.

Oplocks are on by default {{verify}} - disabling oplocks effectively disables caching. 






https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/storage_administration_guide/ch-fscache

-->

==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.



<!--
Asynchronous IO (aio)

To do any reads/writes of over via io, configure:
 #aio read size = 16384
 #aio write size = 16384
 aio read size = 512
 aio write size = 512

Apparently, Linux' dummy support of aio (using pthreads) is slower, 
while Solaris and maybe AIX seem to have better support.





Some notes: 
* BUFFER OVERFLOW is not an error (see [http://blogs.technet.com/markrussinovich/archive/2005/05/17/buffer-overflows.aspx])


To see what your windows client is up to (whether it's doing excessive operations), you can use [http://www.microsoft.com/technet/sysinternals/processesandthreads/processmonitor.mspx
Process Monitor] (and filter in just your network drives).


To inspect what a smbd process is up to, you can use strace. Find the smbd process that seems to be serving you, and latch onto it:
 strace -p 7502
You can look for specific calls by using strace's -e option. A handy option can be <tt>-efile</tt> ('file related calls').

It may be more interesting to grep the output instead, for example using a negative filter to filter out specific things step by sete as you figure out how much of a problem they are or aren't.
 strace -p 7502 2>&1 | 
   egrep -v '(gete[ug]id32|[gs]etgroups32|setres[gu]id32|getdents64)' | \
   egrep -v '(read\(28|write\(28|SEEK_SET|gettimeofday|kill)'

Noise you probably don't want to see include:
* signaling: <tt>kill</tt>
* permission stuff: that second line there
* <tt>gettimeofday</tt>
* network packet reads and writes: <tt>377SMB</tt> works for real packets, but you'll also see a lot of very small packets. You could use lsof to see which filehandle is the open connection and filter out reads and writes from there (28 in the above example)
* in-file seeks: SEEK_SET


Things you could look for or filter out include
* excessive stat64()ing
* directory opens and/or file opens with IFDIR and IFREG
* update polling: select
-->

=Semi-sorted=

==Clients==

<!--
Windows


Linux:
* GNOME client (mostly nautilus)
: seems to have some speed issues

* KDE client (mostly dolphin?)

* cifs-utils
: provides mount.cifs

* smbclient (you may prefer the above, though)
: provides smbclient

* smbfs (deprecated)
: provides smbmnt, smbumount



-->


==mount.cifs options==
{{stub}}

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



<!--
==Generating hashes==
In case you want to generate MD4s
<syntaxhighlight lang="bash">
#!/bin/bash

read -s -p "Password (not shown): " PASSWORD

echo ""

echo -n "md4: "
echo "$PASSWORD" | tr -d '\n' | iconv -t utf16le | openssl md4

# and MD5, just for double checking.
echo -n "md5: "
echo "$PASSWORD" | tr -d '\n' | md5sum | tr -d '-'
</syntaxhighlight >

Notes:
* There are hash libraries in many scripting languages, but this seems more portable (exceptI can't find it in docs)
* removal of the newline on the value because read seems to leave it appended
* the iconv because openssl wants it that way
* removing the dash on the md5 mostly for fun
-->

==Getting windows to remember network logins==
{{stub}}

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 &rarr; User Accounts &rarr; Advanced &rarr; 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 {{comment|(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 ({{key|Win}}-R, {{inlinecode|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==
{{stub}}

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 ?<!--
** means MD4 hash?
** can be 40-bit or 56-bit {{verify}}-->


* 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.<!--
** can be 40-bit, 56-bit, and 128-bit {{verify}}-->


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 
* <tt>security=domain</tt> - works {{verify}}
* <tt>security=server</tt> - doesn't work {{verify}}
* <tt>security=user</tt> - ?


----


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}}



<!--
'''NTLMv1 passwords NOT PERMITTED for user ''username'''''

NTLMv1 seems to mean MD4 hash
-->


<!--
Recent windowses will reject the older  security -- but doesn't NTLMv1 and not NTLMv2 without explicitly enabling it.


Under KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa:

* LmCompatibilityLevel (a DWORD, in case it doesn't exist)
** 0: client sends LM and NTLM Responses
** 1: client sends LM and NTLM, use NTLMv2 session security if negotiated
** 2: client sends NTLM response only
** 3: client sends NTLMv2 response only (default)
** 4: Send NTLMv2 response only/refuse LM
** 5: Send NTLMv2 response only/refuse LM and NTLM


* \MSV1_0\NtlmMinClientSec and \MSV1_0\NtlmMinServerSec:
** 0x0 - no security
** 0x10 - Require message integrity
** 0x20 - Require message confidentiality
** 0x80000 - Require NTLMv2 session security
** 0x20000000 - Require 128-bit encryption 

Seem to be 0x20000000 when you set


SPNEGO (WindowsXP, Windows2000)
-->

<!--
-->

<!--
===The specified network password is incorrect===

Seems to typically be one of two things:
'''Minimum security requirements for connections'''


'''Some bug with windows live''' - removing "Windows Live ID Sign-in Assistant" seems to fix it?


===Can only see some servers===

In particular, Win7 only seeing other Win7 nodes, not samba, NAS, or such.


NTLMv2 responses only” to one of the more lenient settings, like “LM and NTLM – use NTLMV2 session security if negotiated”.
-->

==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==
{{stub}}
<!--
smbfs is now considered outdated, cifs is preferred.


For cifs:
* fstab lines should probably include:
** uid, to specify what user (instead of root) will own the share after mounting. Often necessary to get useful write access
-->

==symlinks==
{{stub}}
Samba supports symlinks, but there are a bunch of details.


Seems to be tied to CIFS Unix extensions (as defined by HP[http://docs.hp.com/en/B8724-90044/ch01s03.html])

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 <tt>follow symlinks</tt>)
* links outside can be restricted (and there are differences between relative and absolute symlinks)


Relevant settings:
* {{inlinecode|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.

* {{inlinecode|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.

* {{inlinecode|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).
{{comment|(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.)}}


<!--
You could (ab)use symlinks to create shares with virtual contents that actually come from various places. It seemed that OSX had a problem with 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 <tt>wide links</tt> (share-level) {{comment|(...also <tt>follow symlinks</tt>, 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 <tt>wide links</tt>, you'll probably want to set <tt>unix extensions=no</tt> - 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 <tt>lfs</tt> 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



<!--
Windows caches logins/passwords to transparently try later. This may sometimes lead to problems, 
-->





==Names==
{{stub}}

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:
* http://www.system-linux.net/doc/samba-doc/htmldocs/Samba3-HOWTO/integrate-ms-networks.html

==Samba URLs==
{{stub}}
* (unofficial draft)
* Looks like <tt>smb://[[[authdomain;]user@]host[:port][/share[/path[/name]]]][?context]</tt>
* implementation in libsmbclient, others; support in MacOSX, Unices (Gnome, KDE), no support in Windows (only its own UNC style there)
* See also:
** http://www.ubiqx.org/cifs/Appendix-D.html
** http://www.ietf.org/mail-archive/web-old/ietf-announce-old/current/msg13348.html
** http://code.google.com/apis/searchappliance/documentation/50/admin/URL_patterns.html#SMB_patterns


==Problems==

===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 &rarr; ''Tools'' menu &rarr; ''Disconnect Network Drive'', OR
** via the command line using {{inlinecode|net use}} to shows you the mounts, andsomething like {{inlinecode|net use N: /delete}} to remove one or {{inlinecode|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:
* http://support.microsoft.com/default.aspx?scid=kb;EN-US;q106211


===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!"===
{{stub}}
This seems to have multiple causes and be multiple similar errors, at least:

* one from <tt>smbd/service.c:make_connection</tt> 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 <tt>smbd/service.c:make_connection_snum</tt>, which usually means everything works, but apparently indicates the (transparent background re)connection falls back to something that works. 

<!--
It's possible that figuring out what causes this allows these (re)connections to be a little faster.

In my case, an explicit <tt>encrypt passwords = yes</tt> in the logs solved it.
-->

==="The alias ... can't be opened because the original item can't be found"===
{{stub}}
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 [https://wiki.samba.org/index.php/LinuxCIFSKernel#4.13_Kernel_.2824_changesets.29 changed the defailt dialect to 3 (/ highest agreed?{{verify}})] {{comment|<nowiki>(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."</nowiki>)}}


...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 <tt>loglevel</tt> 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 <tt>valid users</tt> list on ipc$ (...that didn't include this particular user).


<!--
==='''INVALID PIPE HANDLE'''===

Possibly related to an (implied?) directory that smbd wants to stat that is missing or not accessible by the effective user?

Probably related to some guest account details and/or the IPC$ share.


==='''There are currently no logon servers to service the logon request / NT_STATUS_NO_LOGON_SERVERS''' Error==
-->


===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 {{inlinecode|<nowiki>domain=mydomain</nowiki>}} 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}}
<!--
sec=
-->

<!--
===user '' 'username' '' (from session setup) not permitted to access this share (''sharename'')===
...when using the mysql backend.

A share would work until I used added <tt>valid user</tt> / <tt>read list</tt> restrictions, at which case anyone was denied outright.

It's likely that a 
 loglevel = 2 auth:10 
will help you diagnose this


I long thought it may have had to do with how to specify users, but that suggested it had to do with
how SIDs are stored/processed.


-->

===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===
<!--

I managed to get locked out of my university account for a few days
due to a CIFS mounter retrying indefinitely using cached credentials.

This means that when you change your password, you have to umount all hosts that use this account,
change password, and mount all these mounts again.


CIFS has soft/hard, similar to NFS. 

hard
* if the server leaves abrubtly (e.g. crashes), will cause the IO in the client's program hang forever

soft (default)
* if the server leaves abrubtly (e.g. crashes), will return an error to the client's program


You may have more control when mounting through FUSE (because userspace), 
-->

===Oplock break failed for file===
{{stub}}

SMB has an [[Locking,_data_versioning,_concurrency,_and_larger-scale_computing_notes#Opportunistic_locking|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==
<!--
 check_ntlm_password:  Authentication for user [username] -> [username] FAILED with error NT_STATUS_NO_SUCH_USER


Says e.g. https://sources.debian.org/src/samba/2:4.6.7+dfsg-2/source3/auth/auth.c/?hl=290#L290

 check_ntlm_password:  authentication for user [%s] -> [%s] -> [%s] succeeded
       user_info->client.account_name,
       user_info->mapped.account_name,
       unix_username

 check_ntlm_password:  Authentication for user [%s] -> [%s] FAILED with error %s
       user_info->client.account_name,
       user_info->mapped.account_name,
           nt_errstr(nt_status)));

Those structs are created elsewhere, this function only verifies the password.

Note that NT_STATUS_NO_SUCH_USER is the fallback value, which can also happen if none of the 


-->

==Yet to read==
* http://us1.samba.org/samba/docs/man/Samba-Guide/
* http://www.faqs.org/docs/samba/toc.html


* http://www.oregontechsupport.com/samba/

* 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

* http://www.samba-tng.org/docs/tng-arch/tng-arch.html






==DFS==

Microsoft has DFS, [https://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft) 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. [http://samba.org/samba/docs/man/Samba-HOWTO-Collection/msdfs.html]

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



[[Category:Unices]]
[[Category:Networking]]
[[Category:Server]]