[gpfsug-discuss] question about why unix extensions = no is recommended when using samba + gpfs?

[Jonathan Buzzard]

On 03/04/14 03:08, Sabuj Pattanayek wrote:

[SNIP]
>
> include = /etc/samba/template_shares.conf
> include = /etc/samba/test_shares.conf

That is stupid, you need to use registry share definitions with CTDB. 
Having them in files is bad bad bad.

>
> ### template_shares.conf ###
>
> [template_nfs4]
> comment = GPFS Cluster on smb using %R protocol
> path = /dors/testfs
> writeable = yes
> vfs objects = shadow_copy2 gpfs fileid

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.

> ea support = yes
> store dos attributes = yes
> access based share enum = yes
> map readonly = no
> map archive = no
> map system = no
> mangled names = no
> force unknown acl user = yes
> locking = yes
> notify:inotify = no
> shadow:snapdir = .snapshots
> shadow:localtime = yes
> shadow:format = %Y%m%d_%H:%M
> shadow:fixinodes = yes
> shadow:snapdirseverywhere = yes
> shadow:sort = desc
> # vfs_gpfs settings
> gpfs:acl = yes
> gpfs:winattr = yes
> gpfs:dfreequota = yes
> nfs4:mode = simple
> nfs4:chown = yes
> nfs4:acedup = merge
> ## needed to turn off sharemodes, msoffice on windows couldn't save
> # https://bugzilla.samba.org/show_bug.cgi?id=6762
> gpfs:sharemodes = no

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 ...

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.

> gpfs:leases = yes
> posix locking = yes
> kernel oplocks = no
> kernel share modes = yes
> fileid:algorithm = fsname
>
>
>
>     Have you tested that the DOS attributes are correctly being stored
>     in the GPFS file system?
>
>
> No, but they're all set to no, including map hidden which was missing
> above but according to man smb.conf is by default set to no, so wouldn't
> these not be mapped/stored in GPFS anyways? What EA file would these be
> stored in if these were set to yes?

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

I suggest that you explicitly test and make sure it is working.

>
>
>     It explicitly does work. The issues are all around Office trying to
>     preserve ACL's which the vast majority of software does not.
>
>
> Understood, but again, with the setup above, I had to turn sharemodes
> off to get it to work. Setting it to no was mentioned in a comment in u
> that samba bug by Volker, i.e. I just didn't think of that myself, so
> there must be some correlation.
>
>
>     Are you running with NFSv4 ACL's *ONLY* on GPFS? Using Posix or
>     Posix and NFSv4 together is likely to lead to problems.
>
>
> posix + nfs4, it can be problematic but we're working around it.
>

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.

I suggest you use a development/test GPFS cluster to verify it.


JAB.

-- 
Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
Fife, United Kingdom.