Cannot copy over 7MB file to Samba cluster on Centos 6.5

0

0

I have followed these instructions (with lots of updates since it's old) to get working two nodes Samba cluster in my VirtualBox lab. It's almost done, but I experience strange issue and does not know where to search for solution:

I cannot copy files bigger than 7MB from Windows desktop to this share. Smaller ones I copy with no issue. Error is "There is a problem accessing \192.168.1.128\public" "Make sure you are connected to the network and try again".

UPDATE: I just restarted VirtualBox host and power on both CentOs VMs. Using Windows desktop I managed to create a new folder and to copy 1Gb file to the share successfully. After copy is finished I cannot copy big file again (batch of small ones are copied ok).

UPDATE 2: I just realized I'm able to copy files to share root (public) but not to folders I created from clients (Windows 7 and Ubuntu which) UPDATE 2a: I was wrong, I did managed to copy more gigabytes on root share (public) from Windows before I start hitting the same error, from Ubuntu file is always copied until end, but with error message at the very end (Invalid argument)

Any ideas?

[root@smb1 ~]# testparm -s
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
WARNING: The "idmap backend" option is deprecated
Processing section "[public]"
Loaded services file OK.
Server role: ROLE_STANDALONE
[global]
    map to guest = Bad Password
    private dir = /clusterdata/ctdb
    max protocol = SMB2
    use mmap = No
    clustering = Yes
    fileid:mapping = fsname
    idmap config * : backend = tdb2
    ea support = Yes

[public]
    comment = public share
    path = /clusterdata/public
    read only = No
    guest only = Yes
    guest ok = Yes


[root@smb2 ~]# cat /etc/sysconfig/ctdb
 CTDB_RECOVERY_LOCK="/clusterdata/ctdb.lock"
 CTDB_PUBLIC_INTERFACE=eth0
 CTDB_PUBLIC_ADDRESSES=/etc/ctdb/public_addresses
 CTDB_MANAGES_SAMBA=yes
 ulimit -n 10000
 CTDB_NODES=/etc/ctdb/nodes
 CTDB_LOGFILE=/var/log/log.ctdb
 CTDB_DEBUGLEVEL=2
 CTDB_PUBLIC_NETWORK="192.168.1.0/24"
 CTDB_PUBLIC_GATEWAY="192.168.1.1"

Jan 14 19:01:12 smb2 smbd[17637]: [2014/01/14 19:01:12.908248,  0] locking/locking.c:887(share_mode_lock_destructor)
Jan 14 19:01:12 smb2 smbd[17637]:   delete_rec returned NT_STATUS_UNSUCCESSFUL
Jan 14 19:01:12 smb2 smbd[17637]: [2014/01/14 19:01:12.908417,  0] lib/util.c:1117(smb_panic)
Jan 14 19:01:12 smb2 smbd[17637]:   PANIC (pid 17637): could not delete share entry: NT_STATUS_UNSUCCESSFUL

[root@smb1 ~]# rpm -qa | grep samba
samba-winbind-3.6.9-167.el6_5.x86_64
samba-3.6.9-167.el6_5.x86_64
samba-common-3.6.9-167.el6_5.x86_64
samba-winbind-clients-3.6.9-167.el6_5.x86_64

soiiid1953

Posted 2014-01-14T12:37:11.767

Reputation: 1

does testparm -s (run as root) note any configuration issues? please post your smb.conf. are you able to put larger files to the shared disk(s) using sftp/scp, or even just copying files around the server? – Frank Thomas – 2014-01-14T13:06:29.210

question body updated – soiiid1953 – 2014-01-14T17:37:54.060

It is unpredictable... I managed to copy several gigabytes from my desktop windows, but it is not reliable, i'm getting on occasion network error. SCP works great, also copy files from local file system to drbd makes file replicated on second node.

This is only error I found in all logs: [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: (Ctrl+C)

I could not find anything on web... – soiiid1953 – 2014-01-17T21:27:06.693

I'm getting pretty sure DRBD + GFS2 is working fine (all files management on /clusterdata/public done in linux) is smooth and reflected to other node. Therefore issue must be with SAMBA and CTDB... – soiiid1953 – 2014-01-18T20:11:22.597

I can confirm changing from clustering = yes to clustering = 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... – soiiid1953 – 2014-01-19T10:51:55.910

No answers