My SAMBA cluster is unreliable, I noticed that from Windows desktop (on some occasion works fine but it is not reliable), on Ubuntu I'm getting this error (same is keep repeating in the log):
[root@smb1 ~]# smbpasswd -a root
lib/dbwrap_ctdb.c:951 Error sending local control SCHEDULE_FOR_DELETION: NT_STATUS_OK, cstatus = -1
g_lock_force_unlock: Could not store record: NT_STATUS_UNSUCCESSFUL
g_lock_unlock failed: NT_STATUS_UNSUCCESSFUL
New SMB password:
It feels like that Samba cannot write to TDB tables in cluster configuration, they are kept separately from DRBD block on each node local file system:
[root@smb2 ~]# ls /usr/local/var/ctdb/ -la
total 492
drwxr-xr-x 4 root root 4096 2014-01-13 22:24 .
drwxr-xr-x 3 root root 4096 2014-01-13 22:22 ..
-rw-r--r-- 1 root root 53248 2014-01-17 21:41 brlock.tdb.1
-rw-r--r-- 1 root root 81920 2014-01-17 21:45 connections.tdb.1
-rwx------ 1 root root 53248 2014-01-17 22:17 g_lock.tdb.1
-rw-r--r-- 1 root root 53248 2014-01-17 21:41 locking.tdb.1
-rw-r--r-- 1 root root 53248 2014-01-17 21:37 notify_onelevel.tdb.1
-rw-r--r-- 1 root root 40172 2014-01-17 21:04 notify.tdb.1
drwx------ 2 root root 4096 2014-01-13 22:22 persistent
-rw-r--r-- 1 root root 53248 2014-01-17 22:17 printer_list.tdb.1
-rw-r--r-- 1 root root 53248 2014-01-17 22:16 serverid.tdb.1
-rw-r--r-- 1 root root 40172 2014-01-17 20:46 sessionid.tdb.1
drwx------ 2 root root 4096 2014-01-17 20:46 state
-rw------- 1 root root 696 2014-01-13 22:22 vactune.tdb.1
I've spent whole week searching for solution on the web but nothing. That makes me believe my issue is either extremely easy solved or it's a brand new.
I deployed this setup on my VirtualBox lab, I tried changing many parameters of virtual machines (cpu number, network adapter card, chipset...) but it didn't help...
ls /clusterdata/public/
on both linux boxes and whole folder/file structure is still present on both nodes...clustering = yes
toclustering = no
in samba configuration file resolved the network issue and these tdb error related errors are showing no more in logs, but this is no solution I believe...