Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / Dokumentacja systemu SUSE LINUX Enterprise Server / Storage Administration Guide / Network storage / Samba
Applies to SUSE Linux Enterprise Server 15 SP3

20 Samba

Using Samba, a Unix machine can be configured as a file and print server for macOS, Windows, and OS/2 machines. Samba has developed into a fully-fledged and rather complex product. Configure Samba with YaST, or by editing the configuration file manually.

20.1 Terminology

The following are some terms used in Samba documentation and in the YaST module.

SMB protocol

Samba uses the SMB (server message block) protocol, which is based on NetBIOS services. Microsoft released the protocol so that software from other manufacturers could establish connections to a servers running Microsoft operating systems. Samba implements the SMB protocol on top of the TCP/IP protocol, which means that TCP/IP must be installed and enabled on all clients.

Tip: IBM Z: NetBIOS support

IBM Z merely supports SMB over TCP/IP. NetBIOS support is not available on these systems.

CIFS protocol

The CIFS (Common Internet File System) protocol is an early version of the SMB protocol, also known as SMB1. CIFS defines a standard remote file system access protocol for use over TCP/IP, enabling groups of users to work together and share documents across the Internet.

SMB1 was superseded by SMB2, first released as part of Microsoft Windows Vista™. This was in turn superseded by SMB3 in Microsoft Windows 8™ and Microsoft Windows Server 2012. In recent versions of Samba, SMB1 is disabled by default for security reasons.


NetBIOS is a software interface (API) designed for name resolution and communication between computers on a network. It enables machines connected to the network to reserve names for themselves. After reservation, these machines can be addressed by name. There is no central process that checks names. Any machine on the network can reserve as many names as it wants, as long as the names are not already in use. NetBIOS can be implemented on top of different network protocols. One relatively simple, non-routable implementation is called NetBEUI. (This is often confused with the NetBIOS API.) NetBIOS is also suppported on top of the Novell IPX/SPX protocol. Since version 3.2, Samba supports NetBIOS over both IPv4 and IPv6.

The NetBIOS names sent via TCP/IP have nothing in common with the names used in /etc/hosts or those defined by DNS. NetBIOS uses its own, completely independent naming convention. However, it is recommended to use names that correspond to DNS host names, to make administration easier, or to use DNS natively. This is the default used by Samba.

Samba server

Samba server provides SMB/CIFS services and NetBIOS over IP naming services to clients. For Linux, there are three daemons for the Samba server: smbd for SMB/CIFS services, nmbd for naming services, and winbind for authentication.

Samba client

The Samba client is a system that uses Samba services from a Samba server over the SMB protocol. Common operating systems, such as Windows and macOS, support the SMB protocol. The TCP/IP protocol must be installed on all computers. Samba provides a client for the different Unix flavors. For Linux, there is a kernel module for SMB that allows the integration of SMB resources on the Linux system level. You do not need to run any daemon for the Samba client.


SMB servers provide resources to the clients by means of shares. Shares are directories (including their subdirectories) and printers on the server. A share is exported by means of a share name, and can be accessed by this name. The share name can be set to any name—it does not need to be the name of the export directory. Shared printers are also assigned names. Clients can access shared directories and printers by their names.

By convention, share names ending with a dollar symbol ($) are hidden; that is, when using a Windows computer to browse available shares, they will not be displayed.


A domain controller (DC) is a server that handles accounts in a domain. For data replication, it is possible to have multiple domain controllers in a single domain.

20.2 Installing a Samba server

To install a Samba server, start YaST and select Software › Software Management. Choose View › Patterns and select File Server. Confirm the installation of the required packages to finish the installation process.

20.3 Starting and stopping Samba

You can start or stop the Samba server automatically (during boot) or manually. The starting and stopping policy is a part of the YaST Samba server configuration described in Section 20.4.1, “Configuring a Samba server with YaST”.

From a command line, stop services required for Samba with systemctl stop smb nmb and start them with systemctl start nmb smb. The smb service cares about winbind if needed.

Tip: winbind

winbind is an independent service, and as such is also offered as an individual samba-winbind package.

20.4 Configuring a Samba server

A Samba server in SUSE® Linux Enterprise Server can be configured in two different ways: with YaST or manually. Manual configuration offers a higher level of detail, but lacks the convenience of the YaST GUI.

20.4.1 Configuring a Samba server with YaST

To configure a Samba server, start YaST and select Network Services › Samba Server. Initial Samba configuration

When starting the module for the first time, the Samba Installation dialog starts, prompting you to make a few basic decisions concerning administration of the server. At the end of the configuration, it prompts for the Samba administrator password (Samba Root Password). For later starts, the Samba Configuration dialog appears.

The Samba Installation dialog consists of two steps and optional detailed settings:

Workgroup or domain name

Select an existing name from Workgroup or Domain Name or enter a new one and click Next.

Samba server type

In the next step, specify whether your server should act as a primary domain controller (PDC), backup domain controller (BDC), or not act as a domain controller. Continue with Next.

If you do not want to proceed with a detailed server configuration, confirm with OK. Then in the final pop-up box, set the Samba root Password.

You can change all settings later in the Samba Configuration dialog with the Start-Up, Shares, Identity, Trusted Domains, and LDAP Settings tabs. Enabling current versions of the SMB protocol on the server

On clients running current versions of SUSE Linux Enterprise Server or other recent Linux versions, the insecure SMB1/CIFS protocol is disabled by default. However, existing instances of Samba may be configured to only serve shares using the SMB1/CIFS version of the protocol. To interact with such clients, you need to configure Samba to serve shares using at least the SMB 2.1 protocol.

There are setups in which only SMB1 can be used—for example, because they rely on SMB1's/CIFS's Unix extensions. These extensions have not been ported to newer protocol versions. If you are in this situation, consider changing your setup or see Section 20.5.2, “Mounting SMB1/CIFS shares on clients”.

To do so, in the configuration file /etc/samba/smb.conf, set the global parameter server max protocol = SMB2_10. For a list of all possible values, see man smb.conf. Advanced Samba configuration

During the first start of the Samba server module, the Samba Configuration dialog appears directly after the two initial steps described in Section, “Initial Samba configuration”. Use it to adjust your Samba server configuration.

After editing your configuration, click OK to save your settings. Starting the server

In the Start Up tab, configure the start of the Samba server. To start the service every time your system boots, select During Boot. To activate manual start, choose Manually. More information about starting a Samba server is provided in Section 20.3, “Starting and stopping Samba”.

In this tab, you can also open ports in your firewall. To do so, select Open Port in Firewall. If you have multiple network interfaces, select the network interface for Samba services by clicking Firewall Details, selecting the interfaces, and clicking OK. Shares

In the Shares tab, determine the Samba shares to activate. There are some predefined shares, like homes and printers. Use Toggle Status to switch between Active and Inactive. Click Add to add new shares and Delete to delete the selected share.

Allow Users to Share Their Directories enables members of the group in Permitted Group to share directories they own with other users. For example, users for a local scope or DOMAIN\Users for a domain scope. The user also must make sure that the file system permissions allow access. With Maximum Number of Shares, limit the total amount of shares that may be created. To permit access to user shares without authentication, enable Allow Guest Access. Identity

In the Identity tab, you can determine the domain with which the host is associated (Base Settings) and whether to use an alternative host name in the network (NetBIOS Hostname). It is also possible to use Microsoft Windows Internet Name Service (WINS) for name resolution. In this case, activate Use WINS for Hostname Resolution and decide whether to Retrieve WINS server via DHCP. To set expert global settings or set a user authentication source, for example LDAP instead of TDB database, click Advanced Settings. Trusted domains

To enable users from other domains to access your domain, make the appropriate settings in the Trusted Domains tab. To add a new domain, click Add. To remove the selected domain, click Delete. LDAP settings

In the tab LDAP Settings, you can determine the LDAP server to use for authentication. To test the connection to your LDAP server, click Test Connection. To set expert LDAP settings or use default values, click Advanced Settings.

For more information about LDAP configuration, see Chapter 5, LDAP with 389 Directory Server.

20.4.2 Configuring the server manually

If you intend to use Samba as a server, install samba. The main configuration file for Samba is /etc/samba/smb.conf. This file can be divided into two logical parts. The [global] section contains the central and global settings. The following default sections contain the individual file and printer shares:

  • [homes]

  • [profiles]

  • [users]

  • [groups]

  • [printers]

  • [print$]

Using this approach, options of the shares can be set differently or globally in the [global] section, which makes the configuration file easier to understand. The global section

The following parameters of the [global] section should be modified to match the requirements of your network setup, so other machines can access your Samba server via SMB in a Windows environment.

workgroup = WORKGROUP

This line assigns the Samba server to a workgroup. Replace WORKGROUP with an appropriate workgroup of your networking environment. Your Samba server appears under its DNS name unless this name has been assigned to some other machine in the network. If the DNS name is not available, set the server name using netbiosname=MYNAME. For more details about this parameter, see the smb.conf man page.

os level = 20

This parameter triggers whether your Samba server tries to become LMB (local master browser) for its workgroup. Choose a very low value such as 2 to spare the existing Windows network from any interruptions caused by a misconfigured Samba server. More information about this topic can be found in the Network Browsing chapter of the Samba 3 Howto; for more information on the Samba 3 Howto, see Section 20.9, “More information”.

If no other SMB server is in your network (such as a Windows 2000 server) and you want the Samba server to keep a list of all systems present in the local environment, set the os level to a higher value (for example, 65). Your Samba server is then chosen as LMB for your local network.

When changing this setting, consider carefully how this could affect an existing Windows network environment. First test the changes in an isolated network or at a noncritical time of day.

wins support and wins server

To integrate your Samba server into an existing Windows network with an active WINS server, enable the wins server option and set its value to the IP address of that WINS server.

If your Windows machines are connected to separate subnets and need to still be aware of each other, you need to set up a WINS server. To turn a Samba server into such a WINS server, set the option wins support = Yes. Make sure that only one Samba server of the network has this setting enabled. The options wins server and wins support must never be enabled at the same time in your smb.conf file. Shares

The following examples illustrate how a CD-ROM drive and the user directories (homes) are made available to the SMB clients.


To avoid having the CD-ROM drive accidentally made available, these lines are deactivated with comment marks (semicolons in this case). Remove the semicolons in the first column to share the CD-ROM drive with Samba.

Example 20.1: A CD-ROM share
       comment = Linux CD-ROM
       path = /media/cdrom
       locking = No
[cdrom] and comment

The [cdrom] section entry is the name of the share that can be seen by all SMB clients on the network. An additional comment can be added to further describe the share.

path = /media/cdrom

path exports the directory /media/cdrom.

By means of a very restrictive default configuration, this kind of share is only made available to the users present on this system. If this share should be made available to everybody, add a line guest ok = yes to the configuration. This setting gives read permissions to anyone on the network. It is recommended to handle this parameter with great care. This applies even more to the use of this parameter in the [global] section.


The [homes] share is of special importance here. If the user has a valid account and password for the Linux file server and their own home directory, they can be connected to it.

Example 20.2: [homes] share
        comment = Home Directories
        valid users = %S
        browseable = No
        read only = No
        inherit acls = Yes

As long as there is no other share using the share name of the user connecting to the SMB server, a share is dynamically generated using the [homes] share directives. The resulting name of the share is the user name.

valid users = %S

%S is replaced with the concrete name of the share when a connection has been successfully established. For a [homes] share, this is always the user name. As a consequence, access rights to a user's share are restricted exclusively to that user.

browseable = No

This setting makes the share invisible in the network environment.

read only = No

By default, Samba prohibits write access to any exported share by means of the read only = Yes parameter. To make a share writable, set the value read only = No, which is synonymous with writable = Yes.

create mask = 0640

Systems that are not based on MS Windows NT do not understand the concept of Unix permissions, so they cannot assign permissions when creating a file. The parameter create mask defines the access permissions assigned to newly created files. This only applies to writable shares. In effect, this setting means the owner has read and write permissions and the members of the owner's primary group have read permissions. valid users = %S prevents read access even if the group has read permissions. For the group to have read or write access, deactivate the line valid users = %S.

Warning: Do not share NFS mounts with Samba

Sharing NFS mounts with Samba may result in data loss and is not supported. Install Samba directly on the file server or consider using alternatives such as iSCSI. Security levels

To improve security, each share access can be protected with a password. SMB offers the following ways of checking permissions:

User level security (security = user)

This variant introduces the concept of the user to SMB. Each user must register with the server with their own password. After registration, the server can grant access to individual exported shares dependent on user names.

ADS level security (security = ADS)

In this mode, Samba will act as a domain member in an Active Directory environment. To operate in this mode, the machine running Samba needs Kerberos installed and configured. You must join the machine using Samba to the ADS realm. This can be done using the YaST Windows Domain Membership module.

Domain level security (security = domain)

This mode will only work correctly if the machine has been joined to a Windows NT domain. Samba will try to validate the user name and password by passing it to a Windows Primary or Backup Domain Controller, the same way as a Windows Server would do. It expects the encrypted passwords parameter to be set to yes.

The selection of share, user, server, or domain level security applies to the entire server. It is not possible to offer individual shares of a server configuration with share level security and others with user level security. However, you can run a separate Samba server for each configured IP address on a system.

More information about this subject can be found in the Samba 3 HOWTO. For multiple servers on one system, pay attention to the options interfaces and bind interfaces only.

20.5 Configuring clients

Clients can only access the Samba server via TCP/IP. NetBEUI and NetBIOS via IPX cannot be used with Samba.

20.5.1 Configuring a Samba client with YaST

Configure a Samba client to access resources (files or printers) on the Samba or Windows server. Enter the Windows or Active Directory domain or workgroup in the dialog Network Services › Windows Domain Membership. If you activate Also Use SMB Information for Linux Authentication, the user authentication runs over the Samba, Windows, or Kerberos server.

Click Expert Settings for advanced configuration options. For example, use the Mount Server Directories table to enable mounting server home directory automatically with authentication. This way users can access their home directories when hosted on CIFS. For details, see the pam_mount man page.

After completing all settings, confirm the dialog to finish the configuration.

20.5.2 Mounting SMB1/CIFS shares on clients

The first version of the SMB network protocol, SMB1 or CIFS, is an old and insecure protocol, which has been deprecated by its originator Microsoft. For security reasons, the mount command on SUSE Linux Enterprise Server will only mount SMB shares using newer protocol versions by default, namely SMB 2.1, SMB 3.0, or SMB 3.02.

However, this change only affects mount and mounting via /etc/fstab. SMB1 is still available by explicitly requiring it. Use the following:

  • The smbclient tool.

  • The Samba server software shipped with SUSE Linux Enterprise Server.

There are setups in which this default setting will lead to connection failures, because only SMB1 can be used:

  • Setups using an SMB server that does not support newer SMB protocol versions. Windows has offered SMB 2.1 support since Windows 7 and Windows Server 2008.

  • Setups that rely on SMB1's/CIFS's Unix extensions. These extensions have not been ported to newer protocol versions.

Important: Decreased system security

Following the instruction below makes it possible to exploit security issues. For more information about the issues, see https://blogs.technet.microsoft.com/filecab/2016/09/16/stop-using-smb1/.

As soon as possible, upgrade your server to allow for a more secure SMB version.

For information about enabling suitable protocol versions on SUSE Linux Enterprise Server, see Section, “Enabling current versions of the SMB protocol on the server”.

If you need to enable SMB1 shares on the current SUSE Linux Enterprise Server kernel, add the option vers=1.0 to the mount command line you use:

# mount -t cifs //HOST/SHARE /MOUNT_POINT –o username=USER_ID,vers=1.0

Alternatively, you can enable SMB1 shares globally within your SUSE Linux Enterprise Server installation. To do so, add the following to /etc/samba/smb.conf under the section [global]:

        client min protocol = CORE

20.6 Samba as login server

In business settings, it is often desirable to allow access only to users registered on a central instance. In a Windows-based network, this task is handled by a primary domain controller (PDC). You can use a Windows Server configured as PDC, but this task can also be done with a Samba server. The entries that must be made in the [global] section of smb.conf are shown in Example 20.3, “Global section in smb.conf”.

Example 20.3: Global section in smb.conf
    workgroup = WORKGROUP
    domain logons = Yes
    domain master = Yes

It is necessary to prepare user accounts and passwords in an encryption format that conforms with Windows. Do this with the command smbpasswd -a name. Create the domain account for the computers, required by the Windows domain concept, with the following commands:

useradd hostname
smbpasswd -a -m hostname

With the useradd command, a dollar sign is added. The command smbpasswd inserts this automatically when the parameter -m is used. The commented configuration example (/usr/share/doc/packages/samba/examples/smb.conf.SUSE) contains settings that automate this task.

add machine script = /usr/sbin/useradd -g nogroup -c "NT Machine Account" \
-s /bin/false %m

To make sure that Samba can execute this script correctly, choose a Samba user with the required administrator permissions and add it to the ntadmin group. Then all users belonging to this Linux group can be assigned Domain Admin status with the command:

net groupmap add ntgroup="Domain Admins" unixgroup=ntadmin

20.7 Samba server in the network with Active Directory

If you run Linux servers and Windows servers together, you can build two independent authentication systems and networks or connect servers to one network with one central authentication system. Because Samba can cooperate with an Active Directory domain, you can join your SUSE Linux Enterprise Server server with an Active Directory (AD) domain.

To join an AD domain proceed as follows:

  1. Log in as root and start YaST.

  2. Start Network Services › Windows Domain Membership.

  3. Enter the domain to join in the Domain or Workgroup field in the Windows Domain Membership screen.

    Determining Windows domain membership
    Figure 20.1: Determining Windows domain membership
  4. Check Also Use SMB Information for Linux Authentication to use the SMB source for Linux authentication on your server.

  5. Click OK and confirm the domain join when prompted for it.

  6. Provide the password for the Windows Administrator on the AD server and click OK.

    Your server is now set up to pull in all authentication data from the Active Directory domain controller.

    Alternatively, you can use the realmd tool to connect to Active Directory. For details, refer to Section 20.7.1, “Using realmd to manage Active Directory”.

Tip: Identity mapping

In an environment with more than one Samba server, UIDs and GIDs will not be created consistently. The UIDs that get assigned to users will be dependent on the order in which they first log in, which results in UID conflicts across servers. To fix this, you need to use identity mapping. See https://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html for more details.

20.7.1 Using realmd to manage Active Directory

realmd is a DBus service that allows you to configure network authentication and domain membership. Discovering Active Directory domains

realmd discovers which domains or realms can be used or configured by checking the DNS SRV records. Ensure that a DNS SRV record is available for the Active Directory domain to be discovered; domain.example.com in the following example:


The DNS records should be created automatically by the DNS server that comes with the Active Directory.

To discover a particular domain name, run the command:

> sudo realm discover --verbose domain.example.com

* Resolving: _ldap._tcp.dc._msdcs.domain.example.com
 * Sending MS-CLDAP ping to:
 * Sending MS-CLDAP ping to:
 * Successfully discovered: domain.example.com

To join a particular Active Directory domain, run the command:

> sudo realm join --verbose domain.example.com

Once you joined the Active Directory domain, you can configure the machine to enable logging in using the domain accounts. To do so, run:

> sudo realm permit --realm domain.example.com --all

To permit only specific accounts by specifying them in the command as follows:

> sudo realm permit --realm domain.example.com DOMAIN\\USERNAME DOMAIN\\USERNAME

To deny logins from any domain account, use the following command:

> sudo realm deny --realm domain.example.com --all

20.8 Advanced topics

This section introduces more advanced techniques to manage both the client and server parts of the Samba suite.

20.8.1 Automounting CIFS file system using systemd

You can use systemd to mount CIFS shares on startup. To do so, proceed as described further:

  1. Create the mount points:


    where PATH_SERVER_SHARED_FOLDER is /cifs/shared in further steps.

  2. Create the systemd unit file and generate a file name from the path specified in the previous step where "/" are replaced with "-", for example:

    > sudo touch /etc/systemd/system/cifs-shared.mount

    with the following content:

    Description=CIFS share from The-Server
  3. Enable the service:

    > sudo systemctl enable cifs-shared.mount
  4. Start the service:

    > sudo systemctl start cifs-shared.mount

    To verify that the service is running, run the command:

    > sudo systemctl status cifs-shared.mount
  5. To confirm that the CIFS shared path is available, try the following command:

    >  cd /cifs/shared
    > ls -l
    total 0
    -rwxrwxrwx. 1 root    root    0 Oct 24 22:31 hello-world-cifs.txt
    drwxrwxrwx. 2 root    root    0 Oct 24 22:31 subfolder
    -rw-r--r--. 1 vagrant vagrant 0 Oct 28 21:51 testfile.txt

20.8.2 Transparent file compression on Btrfs

Samba allows clients to remotely manipulate file and directory compression flags for shares placed on the Btrfs file system. Windows Explorer provides the ability to flag files/directories for transparent compression via the File › Properties › Advanced dialog:

Windows Explorer Advanced Attributes dialog
Figure 20.2: Windows Explorer Advanced Attributes dialog

Files flagged for compression are transparently compressed and decompressed by the underlying file system when accessed or modified. This normally results in storage capacity savings at the expense of extra CPU overhead when accessing the file. New files and directories inherit the compression flag from the parent directory, unless created with the FILE_NO_COMPRESSION option.

Windows Explorer presents compressed files and directories visually differently to those that are not compressed:

Windows Explorer directory listing with compressed files
Figure 20.3: Windows Explorer directory listing with compressed files

You can enable Samba share compression either manually by adding

vfs objects = btrfs

to the share configuration in /etc/samba/smb.conf, or using YaST: Network Services › Samba Server › Add, and checking Utilize Btrfs Features.

A general overview of compression on Btrfs can be found in Section, “Mounting compressed Btrfs file systems”.

20.8.3 Snapshots

Snapshots, also called Shadow Copies, are copies of the state of a file system subvolume at a certain point in time. Snapper is the tool to manage these snapshots in Linux. Snapshots are supported on the Btrfs file system or thinly provisioned LVM volumes. The Samba suite supports managing remote snapshots through the FSRVP protocol on both the server and client side. Previous versions

Snapshots on a Samba server can be exposed to remote Windows clients as previous versions of files or directories.

To enable snapshots on a Samba server, the following conditions must be fulfilled:

  • The SMB network share resides on a Btrfs subvolume.

  • The SMB network share path has a related Snapper configuration file. You can create the snapper file with

    > sudo snapper -c <cfg_name> create-config /path/to/share

    For more information on Snapper, see Chapter 7, System recovery and snapshot management with Snapper.

  • The snapshot directory tree must allow access for relevant users. For more information, see the PERMISSIONS section of the vfs_snapper manual page (man 8 vfs_snapper).

To support remote snapshots, you need to modify the /etc/samba/smb.conf file. You can do this either with YaST › Network Services › Samba Server, or manually by enhancing the relevant share section with

vfs objects = snapper

Note that you need to restart the Samba service for manual changes to smb.conf to take effect:

> sudo systemctl restart nmb smb
Adding a new Samba share with snapshots enabled
Figure 20.4: Adding a new Samba share with snapshots enabled

After being configured, snapshots created by Snapper for the Samba share path can be accessed from Windows Explorer from a file or directory's Previous Versions tab.

The Previous versions tab in Windows explorer
Figure 20.5: The Previous versions tab in Windows explorer Remote share snapshots

By default, snapshots can only be created and deleted on the Samba server locally, via the Snapper command line utility, or using Snapper's timeline feature.

Samba can be configured to process share snapshot creation and deletion requests from remote hosts using the File Server Remote VSS Protocol (FSRVP).

In addition to the configuration and prerequisites documented in Section, “Previous versions”, the following global configuration is required in /etc/samba/smb.conf:

rpc_daemon:fssd = fork
registry shares = yes
include = registry

FSRVP clients, including Samba's rpcclient and Windows Server 2012 DiskShadow.exe, can then instruct Samba to create or delete a snapshot for a given share, and expose the snapshot as a new share. Managing snapshots remotely from Linux with rpcclient

The samba-client package contains an FSRVP client that can remotely request a Windows/Samba server to create and expose a snapshot of a given share. You can then use existing tools in SUSE Linux Enterprise Server to mount the exposed share and back up its files. Requests to the server are sent using the rpcclient binary.

Example 20.4: Using rpcclient to request a Windows server 2012 share snapshot

Connect to win-server.example.com server as an administrator in an EXAMPLE domain:

# rpcclient -U 'EXAMPLE\Administrator' ncacn_np:win-server.example.com[ndr64,sign]
Enter EXAMPLE/Administrator's password:

Check that the SMB share is visible for rpcclient:

# rpcclient $> netshareenum
netname: windows_server_2012_share
path:   C:\Shares\windows_server_2012_share
password:       (null)

Check that the SMB share supports snapshot creation:

# rpcclient $> fss_is_path_sup windows_server_2012_share \
UNC \\WIN-SERVER\windows_server_2012_share\ supports shadow copy requests

Request the creation of a share snapshot:

# rpcclient $> fss_create_expose backup ro windows_server_2012_share
13fe880e-e232-493d-87e9-402f21019fb6: shadow-copy set created
13fe880e-e232-493d-87e9-402f21019fb6(1c26544e-8251-445f-be89-d1e0a3938777): \
\\WIN-SERVER\windows_server_2012_share\ shadow-copy added to set
13fe880e-e232-493d-87e9-402f21019fb6: prepare completed in 0 secs
13fe880e-e232-493d-87e9-402f21019fb6: commit completed in 1 secs
13fe880e-e232-493d-87e9-402f21019fb6(1c26544e-8251-445f-be89-d1e0a3938777): \
share windows_server_2012_share@{1C26544E-8251-445F-BE89-D1E0A3938777} \
exposed as a snapshot of \\WIN-SERVER\windows_server_2012_share\

Confirm that the snapshot share is exposed by the server:

# rpcclient $> netshareenum
netname: windows_server_2012_share
path:   C:\Shares\windows_server_2012_share
password:       (null)

netname: windows_server_2012_share@{1C26544E-8251-445F-BE89-D1E0A3938777}
remark: (null)
path:   \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy{F6E6507E-F537-11E3-9404-B8AC6F927453}\Shares\windows_server_2012_share\
password:       (null)

Attempt to delete the snapshot share:

# rpcclient $> fss_delete windows_server_2012_share \
13fe880e-e232-493d-87e9-402f21019fb6 1c26544e-8251-445f-be89-d1e0a3938777
13fe880e-e232-493d-87e9-402f21019fb6(1c26544e-8251-445f-be89-d1e0a3938777): \
\\WIN-SERVER\windows_server_2012_share\ shadow-copy deleted

Confirm that the snapshot share has been removed by the server:

# rpcclient $> netshareenum
netname: windows_server_2012_share
path:   C:\Shares\windows_server_2012_share
password:       (null) Managing snapshots remotely from Windows with DiskShadow.exe

You can manage snapshots of SMB shares on the Linux Samba server from Windows clients as well. Windows Server 2012 includes the DiskShadow.exe utility which can manage remote shares similarly to the rpcclient command described in Section, “Managing snapshots remotely from Linux with rpcclient. Note that you need to carefully set up the Samba server first.

The following is an example procedure to set up the Samba server so that the Windows client can manage its shares' snapshots. Note that EXAMPLE is the Active Directory domain used in the testing environment, fsrvp-server.example.com is the host name of the Samba server, and /srv/smb is the path to the SMB share.

Procedure 20.1: Detailed Samba server configuration
  1. Join Active Directory domain via YaST. For more information, see Section 20.7, “Samba server in the network with Active Directory”.

  2. Ensure that the Active Directory domain's DNS entry is correct:

    fsrvp-server:~ # net -U 'Administrator' ads dns register \
    fsrvp-server.example.com <IP address>
    Successfully registered hostname with DNS
  3. Create Btrfs subvolume at /srv/smb

    fsrvp-server:~ # btrfs subvolume create /srv/smb
  4. Create a Snapper configuration file for the path /srv/smb:

    fsrvp-server:~ # snapper -c <snapper_config> create-config /srv/smb
  5. Create a new share with path /srv/smb, and the YaST Expose Snapshots check box enabled. Make sure to add the following snippets to the global section of /etc/samba/smb.conf, as mentioned in Section, “Remote share snapshots”:

     rpc_daemon:fssd = fork
     registry shares = yes
     include = registry
  6. Restart Samba with systemctl restart nmb smb

  7. Configure Snapper permissions:

    fsrvp-server:~ # snapper -c <snapper_config> set-config \
    ALLOW_USERS="EXAMPLE\\\\Administrator EXAMPLE\\\\win-client$"

    Ensure that any instances of ALLOW_USERS are also permitted access to the .snapshots subdirectory.

    fsrvp-server:~ # snapper -c <snapper_config> set-config SYNC_ACL=yes
    Important: Path escaping

    Be careful about the '\' escapes! Escape twice to ensure that the value stored in /etc/snapper/configs/<snapper_config> is escaped once.

    "EXAMPLE\win-client$" corresponds to the Windows client computer account. Windows issues initial FSRVP requests while authenticated with this account.

  8. Grant Windows client account necessary privileges:

    fsrvp-server:~ # net -U 'Administrator' rpc rights grant \
    "EXAMPLE\\win-client$" SeBackupPrivilege
    Successfully granted rights.

    The previous command is not needed for the "EXAMPLE\Administrator" user, which has privileges already granted.

Procedure 20.2: Windows client setup and DiskShadow.exe in action
  1. Boot Windows Server 2012 (example host name WIN-CLIENT).

  2. Join the same Active Directory domain EXAMPLE as with the SUSE Linux Enterprise Server.

  3. Reboot.

  4. Open Powershell.

  5. Start DiskShadow.exe and begin the backup procedure:

    PS C:\Users\Administrator.EXAMPLE> diskshadow.exe
    Microsoft DiskShadow version 1.0
    Copyright (C) 2012 Microsoft Corporation
    On computer:  WIN-CLIENT,  6/17/2014 3:53:54 PM
    DISKSHADOW> begin backup
  6. Specify that shadow copies persist across program exits, resets, and reboots:

  7. Check whether the specified share supports snapshots, and create one:

    DISKSHADOW> add volume \\fsrvp-server\sles_snapper
    DISKSHADOW> create
    Alias VSS_SHADOW_1 for shadow ID {de4ddca4-4978-4805-8776-cdf82d190a4a} set as \
     environment variable.
    Alias VSS_SHADOW_SET for shadow set ID {c58e1452-c554-400e-a266-d11d5c837cb1} \
     set as environment variable.
    Querying all shadow copies with the shadow copy set ID \
     * Shadow copy ID = {de4ddca4-4978-4805-8776-cdf82d190a4a}     %VSS_SHADOW_1%
        - Shadow copy set: {c58e1452-c554-400e-a266-d11d5c837cb1}  %VSS_SHADOW_SET%
        - Original count of shadow copies = 1
        - Original volume name: \\FSRVP-SERVER\SLES_SNAPPER\ \
          [volume not on this machine]
        - Creation time: 6/17/2014 3:54:43 PM
        - Shadow copy device name:
        - Originating machine: FSRVP-SERVER
        - Service machine: win-client.example.com
        - Not exposed
        - Provider ID: {89300202-3cec-4981-9171-19f59559e0f2}
        - Attributes:  No_Auto_Release Persistent FileShare
    Number of shadow copies listed: 1
  8. Finish the backup procedure:

    DISKSHADOW> end backup
  9. After the snapshot was created, try to delete it and verify the deletion:

    DISKSHADOW> delete shadows volume \\FSRVP-SERVER\SLES_SNAPPER\
    Deleting shadow copy {de4ddca4-4978-4805-8776-cdf82d190a4a} on volume \
     \\FSRVP-SERVER\SLES_SNAPPER\ from provider \
    {89300202-3cec-4981-9171-19f59559e0f2} [Attributes: 0x04000009]...
    Number of shadow copies deleted: 1
    DISKSHADOW> list shadows all
    Querying all shadow copies on the computer ...
    No shadow copies found in system.

20.9 More information

  • Man pages: To see a list of all man pages installed with the package samba, run apropos samba. Open any of the man pages with man NAME_OF_MAN_PAGE.

  • SUSE-specific README file: The package samba-client contains the file /usr/share/doc/packages/samba/README.SUSE.

  • Additional package documentation: Install the package samba-doc with zypper install samba-doc.

    This documentation installs into /usr/share/doc/packages/samba. It contains an HTML version of the man pages and a library of example configurations (such as smb.conf.SUSE).

  • Online documentation: The Samba wiki contains extensive User Documentation at https://wiki.samba.org/index.php/User_Documentation.