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.
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at gpfsug.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
