9G4HTGTB kk38ģvv On 6 Jul 2016 15:46, "Christof Schmitt" <[email protected]> wrote: > > The message in the trace confirms that this is triggered by: > https://git.samba.org/?p=samba.git;a=commitdiff;h=4 > > I 2asuspect that the Samba version used misses the patch > https://git.samba.org/?p=samba.git;a=commitdiff;h=fdbca5e13a0375d7f18639679a627e67c3df647a > > The CES build of Samba shippied in Spectrum Scale includes the mentioned > patch, and that should avoid the problem seen. Would it be possible to > build Samba again with the mentioned patch to test whether that fixes the > issue seen here? > > Regards, > > Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ > [email protected] || +1-520-799-2469 (T/L: 321-2469) > > > > From: "Sobey, Richard A" <[email protected]> > To: gpfsug main discussion list <[email protected]> > Date: 07/06/2016 05:23 AM > Subject: Re: [gpfsug-discuss] Snapshots / Windows previous versions > Sent by: [email protected] > > > > Thanks Daniel – sorry to be dense, but does this indicate working as > intended, or a bug? I assume the former. So, the question still remains > how has this suddenly broken, when: > > [root@server ict]# mmgetacl -k nfs4 .snapshots/ > .snapshots/: Operation not permitted > > …appears to be the correct output and is consistent with someone else’s > GPFS cluster where it is working. > > Cheers > > Richard > > From: [email protected] [ > mailto:[email protected]] On Behalf Of Daniel > Kidger > Sent: 06 July 2016 12:51 > To: [email protected] > Cc: [email protected] > Subject: Re: [gpfsug-discuss] Snapshots / Windows previous versions > > Looking at recent patches to SAMBA I see from December 2015: > https://download.samba.org/pub/samba/patches/security/samba-4.1.21-security-2015-12-16.patch > , > (link found at https://bugzilla.samba.org/show_bug.cgi?id=11658 which > includes the comment: > Failing that, smbd_check_access_rights should check Unix perms at that > point. > ) > > diff --git a/source3/modules/vfs_shadow_copy2.c > b/source3/modules/vfs_shadow_copy2.c > index fca05cf..07e2f8a 100644 > --- a/source3/modules/vfs_shadow_copy2.c > +++ b/source3/modules/vfs_shadow_copy2.c > @@ -30,6 +30,7 @@ > */ > > #include "includes.h" > +#include "smbd/smbd.h" > #include "system/filesys.h" > #include "include/ntioctl.h" > #include <ccan/hash/hash.h> > @@ -1138,6 +1139,42 @@ static char *have_snapdir(struct vfs_handle_struct > *handle, > return NULL; > } > > +static bool check_access_snapdir(struct vfs_handle_struct *handle, > + const char *path) > +{ > + struct smb_filename smb_fname; > + int ret; > + NTSTATUS status; > + > + ZERO_STRUCT(smb_fname); > + smb_fname.base_name = talloc_asprintf(talloc_tos(), > + "%s", > + path); > + if (smb_fname.base_name == NULL) { > + return false; > + } > + > + ret = SMB_VFS_NEXT_STAT(handle, &smb_fname); > + if (ret != 0 || !S_ISDIR(smb_fname.st.st_ex_mode)) { > + TALLOC_FREE(smb_fname.base_name); > + return false; > + } > + > + status = smbd_check_access_rights(handle->conn, > + &smb_fname, > + false, > + SEC_DIR_LIST); > + if (!NT_STATUS_IS_OK(status)) { > + DEBUG(0,("user does not have list permission " > + "on snapdir %s\n", > + smb_fname.base_name)); > + TALLOC_FREE(smb_fname.base_name); > + return false; > + } > + TALLOC_FREE(smb_fname.base_name); > + return true; > +} > + > > Daniel > > > > > > Dr Daniel Kidger > IBM Technical Sales Specialist > Software Defined Solution Sales > > +44-07818 522 266 > [email protected] > > > > > > > ----- Original message ----- > From: "Sobey, Richard A" <[email protected]> > Sent by: [email protected] > To: gpfsug main discussion list <[email protected]> > Cc: > Subject: Re: [gpfsug-discuss] Snapshots / Windows previous versions > Date: Wed, Jul 6, 2016 10:55 AM > > Sure. It might be easier if I just post the entire smb.conf: > > [global] > netbios name = store > workgroup = IC > security = ads > realm = IC.AC.UK > kerberos method = secrets and keytab > > vfs objects = shadow_copy2 syncops gpfs fileid > ea support = yes > store dos attributes = yes > map readonly = no > map archive = no > map system = no > map hidden = no > unix extensions = no > allocation roundup size = 1048576 > > disable netbios = yes > smb ports = 445 > # server signing = mandatory > > template shell = /bin/bash > interfaces = bond2 lo bond0 > allow trusted domains = no > > printing = bsd > printcap name = /dev/null > load printers = no > disable spoolss = yes > > idmap config IC : default = yes > idmap config IC : cache time = 180 > idmap config IC : backend = ad > idmap config IC : schema_mode = rfc2307 > idmap config IC : range = 500 - 2000000 > idmap config * : range = 3000000 - 3500000 > idmap config * : backend = tdb2 > winbind refresh tickets = yes > winbind nss info = rfc2307 > winbind use default domain = true > winbind offline logon = true > winbind separator = / > winbind enum users = true > winbind enum groups = true > winbind nested groups = yes > winbind expand groups = 2 > > winbind max clients = 10000 > > clustering = yes > ctdbd socket = /tmp/ctdb.socket > gpfs:sharemodes = yes > gpfs:winattr = yes > gpfs:leases = yes > gpfs:dfreequota = yes > # nfs4:mode = special > # nfs4:chown = no > nfs4:chown = yes > nfs4:mode = simple > > nfs4:acedup = merge > fileid:algorithm = fsname > force unknown acl user = yes > > shadow:snapdir = .snapshots > shadow:fixinodes = yes > shadow:snapdirseverywhere = yes > shadow:sort = desc > > syncops:onclose = no > syncops:onmeta = no > kernel oplocks = yes > level2 oplocks = yes > oplocks = yes > notify:inotify = no > wide links = no > async smb echo handler = yes > smbd:backgroundqueue = False > use sendfile = no > dmapi support = yes > > aio write size = 1 > aio read size = 1 > > enable core files = no > > #debug logging > log level = 2 > log file = /var/log/samba.%m > max log size = 1024 > debug timestamp = yes > > [IC] > comment = Unified Group Space Area > path = /gpfs/prd/groupspace/ic > public = no > read only = no > valid users = "@domain users" > > From: [email protected] [ > mailto:[email protected]] On Behalf Of Barry Evans > Sent: 06 July 2016 10:47 > To: [email protected] > Subject: Re: [gpfsug-discuss] Snapshots / Windows previous versions > > Can you cut/paste your full VFS options for gpfs and shadow copy from > smb.conf? > > On 06/07/2016 10:37, Sobey, Richard A wrote: > Quick followup on this. Doing some more samba debugging (i.e. increasing > log levels!) and come up with the following: > > [2016/07/06 10:07:35.602080, 3] > ../source3/smbd/vfs.c:1322(check_reduced_name) > check_reduced_name: > admin/ict/serviceoperations/slough_project/Slough_Layout reduced to > /gpfs/prd/groupspace/ic/admin/ict/serviceoperations/slough_project/Slough_Layout > [2016/07/06 10:07:35.611881, 3] ../source3/smbd/dosmode.c:196(unix_mode) > unix_mode(admin/ict/serviceoperations/slough_project/Slough_Layout) > returning 0644 > [2016/07/06 10:07:35.613374, 0] > ../source3/modules/vfs_shadow_copy2.c:1211(check_access_snapdir) > user does not have list permission on snapdir > /gpfs/prd/groupspace/ic/admin/ict/.snapshots > [2016/07/06 10:07:35.613416, 0] > ../source3/modules/vfs_shadow_copy2.c:1380(shadow_copy2_get_shadow_copy_data) > access denied on listing snapdir > /gpfs/prd/groupspace/ic/admin/ict/.snapshots > [2016/07/06 10:07:35.613434, 0] > ../source3/modules/vfs_default.c:1145(vfswrap_fsctl) > FSCTL_GET_SHADOW_COPY_DATA: connectpath /gpfs/prd/groupspace/ic, failed > - NT_STATUS_ACCESS_DENIED. > [2016/07/06 10:07:47.648557, 3] > ../source3/smbd/service.c:1138(close_cnum) > 155.198.55.14 (ipv4:155.198.55.14:51298) closed connection to service > IPC$ > > Any takers? I cannot run mmgetacl on the .snapshots folder at all, as > root. A snapshot I just created to make sure I had full control on the > folder: (39367 is me, I didn’t run this command on a CTDB node so the UID > mapping isn’t working). > > [root@icgpfs01 .snapshots]# mmgetacl -k nfs4 @GMT-2016.07.06-08.00.06 > #NFSv4 ACL > #owner:root > #group:root > group:74036:r-x-:allow:FileInherit:DirInherit:Inherited > (X)READ/LIST (-)WRITE/CREATE (-)MKDIR (X)SYNCHRONIZE (X)READ_ACL > (X)READ_ATTR (X)READ_NAMED > (-)DELETE (-)DELETE_CHILD (-)CHOWN (X)EXEC/SEARCH (-)WRITE_ACL > (-)WRITE_ATTR (-)WRITE_NAMED > > user:39367:rwxc:allow:FileInherit:DirInherit:Inherited > (X)READ/LIST (X)WRITE/CREATE (X)MKDIR (X)SYNCHRONIZE (X)READ_ACL > (X)READ_ATTR (X)READ_NAMED > (X)DELETE (X)DELETE_CHILD (X)CHOWN (X)EXEC/SEARCH (X)WRITE_ACL > (X)WRITE_ATTR (X)WRITE_NAMED > > From: [email protected] [ > mailto:[email protected]] On Behalf Of Sobey, > Richard A > Sent: 20 June 2016 16:03 > To: gpfsug main discussion list <[email protected]> > Subject: Re: [gpfsug-discuss] Snapshots / Windows previous versions > > Thanks Kevin. We are upgrading to GPFS 4.2 and CES in a few weeks but our > customers have come to like previous versions and indeed it is sort of a > selling point for us. > > Samba is the only thing we’ve changed recently after the badlock debacle > so I’m tempted to blame that, but who knows. > > If (when) I find out I’ll let everyone know. > > Richard > > From: [email protected] [ > mailto:[email protected]] On Behalf Of Buterbaugh, > Kevin L > Sent: 20 June 2016 15:56 > To: gpfsug main discussion list <[email protected]> > Subject: Re: [gpfsug-discuss] Snapshots / Windows previous versions > > Hi Richard, > > I can’t answer your question but I can tell you that we have experienced > either the exact same thing you are or something very similar. It > occurred for us after upgrading from GPFS 3.5 to 4.1.0.8 and it persists > even after upgraded to GPFS 4.2.0.3 and the very latest sernet-samba. > > And to be clear, when we upgraded from GPFS 3.5 to 4.1 we did *not* > upgrade SAMBA versions at that time. Therefore, I believe that something > changed in GPFS. That doesn’t mean it’s GPFS’ fault, of course. SAMBA > may have been relying on a bug<ctrl-h><ctrl-h><ctrl-h>undocumented feature > in GPFS that IBM fixed for all I know, and I’m obviously speculating here. > > The problem we see is that the .snapshots directory in each folder can be > cd’d to but is empty. The snapshots are all there, however, if you: > > cd /<mount point of fs>/.snapshots/<data and time snapshot was > taken>/rest/of/path/to/folder/in/question > > This obviously prevents users from being able to do their own recovery of > files unless you do something like what you describe, which we are > unwilling to do for security reasons. We have a ticket open with DDN… > > Kevin > > On Jun 20, 2016, at 8:45 AM, Sobey, Richard A <[email protected]> > wrote: > > Hi all > > Can someone clarify if the ability for Windows to view snapshots as > Previous Versions is exposed by SAMBA or GPFS? Basically, if suddenly my > users cannot restore files from snapshots over a CIFS share, where should > I be looking? > > I don’t know when this problem occurred, but within the last few weeks > certainly our users with full control over their data now see no previous > versions available, but if we export their fileset and set “force user = > root” all the snapshots are available. > > I think the answer is SAMBA, right? We’re running GPFS 3.5 and > sernet-samba 4.2.9. > > Many thanks > > Richard > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > > — > Kevin Buterbaugh - Senior System Administrator > Vanderbilt University - Advanced Computing Center for Research and > Education > [email protected] - (615)875-9633 > > > > > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > > -- > Barry Evans > Technical Director & Co-Founder > Pixit Media > Mobile: +44 (0)7950 666 248 > http://www.pixitmedia.com > > This email is confidential in that it is intended for the exclusive > attention of the addressee(s) indicated. If you are not the intended > recipient, this email should not be read or disclosed to any other person. > Please notify the sender immediately and delete this email from your > computer system. Any opinions expressed are not necessarily those of the > company from which this email was sent and, whilst to the best of our > knowledge no viruses or defects exist, no responsibility can be accepted > for any loss or damage arising from its receipt or subsequent use of this > email. > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > > > > > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
