[global] socket options=SO_RCVBUF=131072 SO_SNDBUF=131072 TCP_NODELAY IPTOS_LOWDELAY use sendfile = true max xmit = 65535 max connections = 65535 max open files = 65535 min receivefile size = 16384 aio read size = 16384 aio write size = 16384 read raw = yes write raw = yes getwd cache = yes dead time = 15 kernel oplocks = yes
Given a development share, where files are added by multiple accessing users, it would be helpful if that share would create the files on the server using a single user and group. This can be accomplished per-share with the following two options:
[devel] ... force user = development force group = development ...
Note that this setting in Samba is stronger rather than setting the sticky group bit on the parent directory because samba will also maintain the user ownership. That is, all files created in the
devel share, regardless by whom will be owned by the user
development and group
None of the documentation provided by samba helps, instructions are given how
create mask removes bits and
force create mode adds bits but the documentation lacks examples where, in the most common case, you would want to set simple permissions for both files and folders created under a share.
This can be accomplied per-share using the following (excessive) options1):
[devel] ... ; newly created files will have 660 (rw-rw----) create mask = 660 force create mode = 660 security mask = 660 force security mode = 660 ; newly created directories will have 0770 (rwxrwx---) directory mask = 0770 force directory mode = 0770 directory security mask = 0770 force directory security mode = 0770 ...
which would be suitable in combination with the previous fuss - for example:
[devel] ; all files and directories created in the share ; will be owned by the development user and the ; development group from passwd / groups force user = development force group = development ; newly created files will have 660 (rw-rw----) create mask = 660 force create mode = 660 security mask = 660 force security mode = 660 ; newly created directories will have 0770 (rwxrwx---) directory mask = 0770 force directory mode = 0770 directory security mask = 0770 force directory security mode = 0770 ...
The reason to do this is that the directories and files on the server, created through samba will then only be accessible to the
development user and
development group. On the other hand, the share will be accessible to a range of users configured with
Seriously though, I recommend the following options to be added to samba:
set file permissions = ... set directory permissions = ...
that would summarise 8 lines of configuration to just 2 lines!
Disabling UNIX extensions (
facl & co.) and
oplocks allows for better compatibility with OSX clients.
[global] # Better compatibility with OSX unix extensions = no max protocol = NT1 min protocol = NT1
Samba version 4.x provides multiple authentication mechanisms which can be chosen as an option
sec during the mount (retrieved from the manual page):
| ||attempt to connection as a null user (no name)|
| ||Use Kerberos version 5 authentication|
| ||Use Kerberos authentication and forcibly enable packet signing|
| ||Use NTLM password hashing|
| ||Use NTLM password hashing and force packet signing|
| ||Use NTLMv2 password hashing|
| ||Use NTLMv2 password hashing and force packet signing|
| ||Use NTLMv2 password hashing encapsulated in Raw NTLMSSP message|
| ||Use NTLMv2 password hashing encapsulated in Raw NTLMSSP message, and force packet signing|
In case you get the following mount-errors (retrieved via
[196525.842930] Status code returned 0xc000006d NT_STATUS_LOGON_FAILURE [196525.842942] CIFS VFS: Send error in SessSetup = -13 [196525.843076] CIFS VFS: cifs_mount failed w/return code = -13
for example, when trying to mount an Apple TimeCapsule share, then most likely the authentication mechanism was not well chosen.
For an Apple TimeCapsule, choosing
ntlm as the authentication mechanism seems to be working:
mount -t cifs //capsule.dg/Sites /mnt/sites/ -o sec=ntlm
The Samba-PAM password sync module has been deprecated. An alternative is to use LDAP as an authentication backend.
To enable the synchronization between shadow and Samba passwords install the
aptitude install libpam-smbpass
/usr/share/doc/libpam-smbpass/examples/password-sync from the
libpam-smbpass package to
/etc/samba/smb.conf make sure that the following settings are made:
obey pam restrictions = yes unix password sync = yes passwd program = /usr/bin/passwd %u passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* . pam password change = yes