[Samba] shadow_copy2 prob? FSCTL..GET..DATA: max_data_count(114) too small (118) bytes needed!
samba at tlinx.org
Sat Feb 6 04:37:28 MST 2010
I have "/home" as a logical volume. I have snapshots:
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
2010.02.05-01.26.19 Home swi-ao 10.00G lvol0 39.81
2010.02.06-02.37.52 Home swi-ao 5.00G lvol0 0.25
lvol0 Home owi-ao 1.00T
and they are mounted:
/dev/mapper/Home-2010.02.05--01.26.19 on /home/snapdir/@GMT-2010.02.05-01.26.19 type xfs (ro,nouuid)
/dev/mapper/Home-2010.02.06--02.37.52 on /home/snapdir/@GMT-2010.02.06-02.37.52 type xfs (ro,nouuid)
My 'home's definitions (I have 3 shares that all resided on /home partition':
'ServHome' (home of user on the server)
'home' (share of the root of the share) and
'/homes' (the per-user in Domain share) where their profiles go
vfs objects = recycle readahead shadow_copy2
shadow:snapdir = /home/snapdir
shadow:basedir = /home
Yet when I go look at files that that have been modified on the 6th, I see no
In /var/log/samba/clientname.log, I see:
linw opened file mail/bind read=Yes write=No (numopen=3)
[2010/02/06 03:23:41, 0] smbd/nttrans.c:1970(call_nt_transact_ioctl)
FSCTL_GET_SHADOW_COPY_DATA: max_data_count(114) too small (118) bytes needed!
[2010/02/06 03:23:57, 2] smbd/close.c:612(close_normal_file)
linw closed file mail/bind (numopen=2) NT_STATUS_OK
Is the max data count too small the problem? Is there a bug in this
version of samba? Is this relevant?
Or is there something else wrong I don't see?
linux 18.104.22.168 on suse 11.1
Any insight appreciated....
More information about the samba