The Samba-Bugzilla – Bug 6762
ctdb on gpfs error with MS Office
Last modified: 2014-09-10 18:59:46 UTC
I just updated to gpfs 3.2.1-14.(Before that I had gpfs 3.2.1-11.)
The samba version stayed the same with samba-ctdb:
With this new setup I get a strange behaviour when writing MS Office
documents of a certain size.(OpenOffice works fine)
Small documents in MS-Office work fine, but if I save a > ~700KB excel/word
document I get the following error in Office:
"There has been a network or file permission Error."
"The network connection maybe lost"
of course its not.
If I do an ls -la in the directory (with the message window still open)
I see that MS Office created two temporary files:
-rwxr-xr-- 1 vogt users 731648 2009-09-25 11:44 test.doc
drwx------ 197 vogt users 65536 2009-09-25 11:59 ..
-rwxr--r-- 1 vogt users 162 2009-09-25 12:20 ~$test.doc
drwxr-xr-x 27 vogt users 16384 2009-09-25 12:20 .
-rwxr--r-- 1 vogt users 131072 2009-09-25 12:20 ~WRD0002.tmp
test.doc is the document opened in Word and the other two files
appear to be temporary files created by the save dialog in word.
If I click "OK" on the error dialog (in word), the two temporary files
disappear, and the document is not updated.
Well ok, you just can say its a gpfs problem, but maybe its somehow
related to samba too, therefore I'm posting it here.
Attached is the [global] section of smb.conf
Maybe someone has an idea?
clustering = yes
idmap backend = tdb2
nt acl support = yes
acl check permissions = no
smb passwd file = /gpfs/share/.smb/etc/samba/smbpasswd
username map = /gpfs/share/.smb/etc/samba/smbusers
debuglevel = 0
server string = "DEP fileserver"
host msdfs = yes
netbios name = SMB
security = domain
workgroup = DEP
password server = ad1 , ad2
encrypt passwords = yes
map to guest = Bad User
getwd cache = yes
read raw = yes
write raw = yes
socket options = IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=65536 SO_RCVBUF=65536
dos filetimes = yes
dos filetime resolution = yes
fake directory create times = yes
delete readonly = yes
hide dot files = yes
map archive = yes
preserve case = yes
short preserve case = yes
case sensitive = no
locking = yes
strict locking = no
blocking locks = no
load printers = no
printing = bsd
printcap name = /dev/null
show add printer wizard = no
disable spoolss = yes
I posted a similar question in a gpfs forum and got an answer.
The current result is:
In the gpfs forum "they" already _know_ that
newer gpfs versions do not work with samba.
>There have been some changes in the sharemode behaviour of GPFS in PTF12 that >break Samba. You'll have to wait until a Samba patch for that is available or >stay on GPFS PTF11.
I have posted then a question on samba-technical if this is a know
issue or if there is already a version which should work with
gpfs > 3.2.1-11
Can you try gpfs:sharemodes = no please?
The PTF12 sharem mode behaviour changed in a way that Samba can not deal with at all. GPFS made the ftruncate call impossible while a share mode is held. GPFS in a much later version will possibly add a workaround for this which Samba then will have to adapt to, but until then gpfs share modes are just not usable for Samba.
I'm closing this as "later", maybe GPFS 3.3 has that workaround.
>Can you try gpfs:sharemodes = no please?
We have tested the following template:
comment = "DEP project data"
browseable = no
path = /var/empty
vfs objects = gpfs fileid
fileid:mapping = fsname
gpfs:sharemodes = no
force unknown acl user = yes
read only = no
create mask = 0777
directory mask = 0777
inherit acls = Yes
map archive = no
map hidden = no
map system = no
copy = project_template
browseable = yes
comment = "dep1 project data"
path = /gpfs/project/dep1
for the share. Same problem with MS Office.
Does not work :(.
Sorry, without detailed logs I'm lost then.
Ok, re-opening so that it does not get lost.
Created attachment 5853 [details]
Was needed for 3.5
Was needed for 3.5
I can confirm that the bug is fixed in a newer ctdb/gpfs version.
This was the posting to the gpfs forum:
And to the Samba list:
>The new GPFS API that was needed for Samba to work correctly
>(gpfs_ftruncate) >has been out since last Sep. The availability of the
>matching Samba change is >really the question for Samba folks. A quick
>google search shows some relevant >changes being pushed under
>3.2.11-ctdb-69 tag, but I don't know what this >really means.
This one worked.
Attached is a patch which was needed for Samba 3.5.
The "bug" can be closed now.
yes, we need to pick beb5afea54e279e348779c5b01070803ed59c775 to 3.5 to prevent data corruption on GPFS. The standard ftuncate seems to cause data corruption.
reassign to Karolin, for inclusion in 3.5
(In reply to comment #8)
> yes, we need to pick beb5afea54e279e348779c5b01070803ed59c775 to 3.5 to prevent
> data corruption on GPFS. The standard ftuncate seems to cause data corruption.
Patch does not apply to current v3-5-test branch.
Could you provide an updated one, please?
with the fix from bug #8031 in place this one applies, too :-)
Pushed to v3-5-test.
Will be included in the next release.
Closing out bug report.
I have this same issue with sernet samba 4.1.6 and gpfs 22.214.171.124 . I was able to fix it by setting gpfs:sharemodes = no for the share. The problem happened for me with Office 2010 on Windows 7/8 . Didn't test older versions of windows. The problem did not occur with Office on OSX, but I have unix extensions turned on. If this is supposed to work with gpfs:sharemodes = yes then I would say that this bug still exists, at least for 126.96.36.199 . We plan on upgrade to 188.8.131.52 soon.
> (In reply to comment #13)
> I have this same issue with sernet samba 4.1.6 and gpfs 184.108.40.206 . I was able
> to fix it by setting gpfs:sharemodes = no for the share. The problem happened
> for me with Office 2010 on Windows 7/8 . Didn't test older versions of windows.
> The problem did not occur with Office on OSX, but I have unix extensions turned
> on. If this is supposed to work with gpfs:sharemodes = yes then I would say
> that this bug still exists, at least for 220.127.116.11 . We plan on upgrade to
> 18.104.22.168 soon.
That's probably more Bug 10774 that is caused by a Samba/GPFS incompatibility.