<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

include = /etc/samba/template_shares.<u></u>conf<br>
include = /etc/samba/test_shares.conf<br>
</blockquote>
<br></div>
That is stupid, you need to use registry share definitions with CTDB. Having them in files is bad bad bad.</blockquote><div><br></div><div>Will look into it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">### template_shares.conf ###<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
[template_nfs4]<br>
comment = GPFS Cluster on smb using %R protocol<br>
path = /dors/testfs<br>
writeable = yes<br>
vfs objects = shadow_copy2 gpfs fileid<br>
</blockquote>
<br></div>
Hum, might have changed in Samba 4.x but in Samba 3.5/3.6 you can only have one vfs objects line in the entire smb.conf file and I did not thing it was a per share option either. Well you can have more than one, but the later ones just override the previous ones.</blockquote>
<div> </div><div><br></div><div>Yup, it's definitely per share in 4.1.x and the later ones probably do override the previous one if the same vfs functions are overloaded, but in the case above there's no overlap and shadow_copy2 and gpfs do work.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><br></div></div>
I am not well versed with Samba 4.x but a quick check says that share modes = yes conflicts with SMB2 and durable handles. Given in Samba 4.1 max protocol is SMB2 by default ...<br></blockquote><div><br></div><div>I was able to do SMB2 (at least in terms of performance over SMBv1) with sharemodes = yes or sharemodes = no. Durable / persistent handles don't work in that active read/write I/O will not continue if  smb/ctdb is disabled on one of the samba nodes. The client will not have to re-map/re-connect but any active I/O other than file deletions and perhaps metadata operations will continue unaffected.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have not seen a definitive answer anywhere about whether SMB2 and CTDB can be used in combination and if so what versions of CTDB/Samba one should be using however.</blockquote><div><br></div><div>I'm using ctdb 1.0.114 packaged by sernet along with sernet samba 4.1.6 . They said they would release re-packaged v2 rpm at some point. Again, SMB2 works in so far as I can tell with its much improved read/write performance over SMB1.  </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
No, but they're all set to no, including map hidden which was missing<br>
above but according to man smb.conf is by default set to no, so wouldn't<br>
these not be mapped/stored in GPFS anyways? What EA file would these be<br>
stored in if these were set to yes?<br>
</blockquote>
<br></div>
They are not stored in an extended attribute they are stored in the GPFS file system itself. The various settings that I listed are so that Samba tells the GPFS VFS module to store them in the extended attributes. Howeve the GPFS VFS module then goes and stores/retrieves them directly from the file system. It's all part of GPFS being able to run on Windows. There are genuine file creation times as well<br>

<br>
I suggest that you explicitly test and make sure it is working.<br></blockquote><div><br></div><div>Yup, they're working, they're being stored wherever they're supposed to be stored in GPFS itself. I set a file to hidden and it disappeared from the explorer window. Went into a command prompt and ran dir/a and it appeared. Then ran mmlsattr -L on the file and it showed ARCHIVE HIDDEN in the Windows attributes section.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Put simply no you are not working around it, it is the cause of your issues with Office. More precisely the issue with Office is down to how the mapping of NTFS ACLS to GPFS is working, because storing the NTFS ACLS in extended attributes works. I am telling you don't mix Posix and NFSv4 ACL's in GPFS it won't work. Whether you listen is up to you.<br>
</blockquote><div><br></div><div>It doesn't work if the ACL on the file is POSIX or has been promoted to NFS4. In any case, we have need for the ACLs support to be both POSIX and NFS4 where needed for the window shares and we can't/won't split up the filesystem. </div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I suggest you use a development/test GPFS cluster to verify it.</blockquote><div><br></div><div>Yes, we're going to need a test/dev cluster for testing these for future upgrades, etc so I will try an FS that's pure nfs4 ACLs only and see if it behaves any differently.</div>
<div> </div></div></div></div>