4.5. Testing the Resource Configuration

If the Samba configuration was successful, you should be able to mount the Samba share on a node in the cluster. The following example procedure mounts a Samba share.
  1. Add an existing user in the cluster node to the smbpasswd file and assign a password. In the following example, there is an existing user smbuser.
    [root@z1 ~]# smbpasswd -a smbuser
    New SMB password:
    Retype new SMB password:
    Added user smbuser
  2. Mount the Samba share:
    [root@z1 ~]# mkdir /mnt/sambashare
    [root@z1 ~]# mount -t cifs -o user=smbuser // /mnt/sambashare
    Password for smbuser@//  ********
  3. Check whether the file system is mounted:
    [root@z1 ~]# mount | grep /mnt/sambashare
    // on /mnt/sambashare type cifs (rw,relatime,vers=1.0,cache=strict,username=smbuser,domain=LINUXSERVER,uid=0,noforceuid,gid=0,noforcegid,addr=,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,echo_interval=60,actimeo=1)
To check for Samba recovery, perform the following procedure.
  1. Manually stop the CTDB resource with the following command:
    [root@z1 ~]# pcs resource debug-stop ctdb
  2. After you stop the resource, the system should recover the service. Check the cluster status with the pcs status command. You should see that the ctdb-clone resource has started, but you will also see a ctdb_monitor failure.
    [root@z1 ~]# pcs status
    Clone Set: ctdb-clone [ctdb]
         Started: [ z1.example.com z2.example.com ]
    Failed Actions:
    * ctdb_monitor_10000 on z1.example.com 'unknown error' (1): call=126, status=complete, exitreason='CTDB status call failed: connect() failed, errno=111',
        last-rc-change='Thu Oct 19 18:39:51 2017', queued=0ms, exec=0ms
    To clear this error from the status, enter the following command on one of the cluster nodes:
    [root@z1 ~]# pcs resource cleanup ctdb-clone