In trying to use robocopy to push files to a GPFS backed share it errors with "ERROR 50 (0x00000032) Time-stamping destination file <filename> The network request is not supported". The file is copied but since an error is returned robocopy believes that the file copy failed. Looking in the smbd log everything looks good until the end (when the timestamp is applied) and a big fat "vfs_gpfs_ntimes: set GPFS ntimes failed -1" w/ NT_STATUS_NOT_SUPPORTED is thrown on the SET_FILE_INFO. I'll be attaching a packet capture and debug log. Thanks!
Created attachment 5763 [details] Packet capture during robocopy run with a test file Packet capture
Created attachment 5764 [details] smbd debug log smbd debug log
Has anyone found a work around for this issue? On another clustered filesystem we've tried (gluster) setting /FFT would get past another issue related with timestamps but this doesn't work with GPFS.
Since this problem has been reported from at least two sources can someone please review this to determine a possible solution, or at perhaps report what needs to be done to fix this. Perhaps one of the reporters is willing to fund a fix? -John T.
Could you please add the following details: * version of gpfs * version of ctdb * samba config Thanks!
(In reply to comment #5) > Could you please add the following details: > > * version of gpfs > * version of ctdb > * samba config We're running the following versions: gpfs2:/space$ rpm -qa |grep samba3|grep -v deb samba3-client-3.5.4-43.suse111 samba3-cifsmount-3.5.4-43.suse111 samba3-doc-3.5.4-43.suse111 samba3-winbind-3.5.4-43.suse111 samba3-3.5.4-43.suse111 samba3-utils-3.5.4-43.suse111 gpfs2:/space$ rpm -qa |grep ctdb ctdb-1.0.112.23-1j gpfs2:/space$ rpm -qa |grep gpfs gpfs.gui-3.3.0-6 gpfs.base-3.3.0-6 gpfs.gpl-3.3.0-6 gpfs.msg.en_US-3.3.0-6 gpfs.docs-3.3.0-6 gpfs.gplbin-2.6.27.45-0.1-default-3.3.0-6 I believe that you may have been made aware recently by JHT that this same problem makes it impossible to run smbtorture. I've applied the following patch which appears to have hidden the problem. I'm reluctant to say anything is "fixed" but robocopy behaves as you'd expect and the copied files have the correct timestamp. smbtorture, as well, runs now. --- samba-3.5.4/source3/modules/vfs_gpfs.c 2010-08-02 23:54:20.000000000 -0600 +++ samba-3.5.4/source3/modules/vfs_gpfs-mod.c 2010-08-02 23:54:07.000000000 -0600 @@ -1096,8 +1096,8 @@ ret = set_gpfs_winattrs(CONST_DISCARD(char *, path), GPFS_WINATTR_SET_CREATION_TIME, &attrs); if(ret == -1){ - DEBUG(1,("vfs_gpfs_ntimes: set GPFS ntimes failed %d\n",ret)); - return -1; + DEBUG(1,("vfs_gpfs_ntimes: set GPFS ntimes failed (I3 always succeed) %d\n",ret)); + /* return -1; */ } return 0;
As requested: conas-01 ~ # rpm -qa | grep samba yast2-samba-client-2.17.11-1.35 samba-client-3.5.3-2 samba-3.5.3-2 yast2-samba-server-2.17.9-0.1.1 samba-winbind-3.5.3-2 conas-01 ~ # rpm -qa | grep gpfs gpfs.base-3.3.0-6 gpfs.gplbin-2.6.27.45-0.1-default-3.3.0-6 gpfs.docs-3.3.0-6 gpfs.msg.en_US-3.3.0-6 gpfs.gpl-3.3.0-6 [global] clustering = yes netbios name = conas workgroup = DOMAIN passdb backend = tdbsam groupdb:backend = tdb load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes realm = domain.com server string = NAS head security = ADS #log level = 3 auth:10 sam:10 winbind:10 idmap:10 log file = /var/log/samba/users/%U.log ldap ssl = start tls ldap admin dn = cn=serviceaccount,dc=domain,dc=com ldap idmap suffix = ou=Idmap ldap suffix = dc=domain,dc=com idmap backend = ldap:ldap://ldap-01.domain.com,ldap://ldap-02.domain.com #idmap backend = tdb2 idmap uid = 150000-550000 idmap gid = 150000-550000 template shell = /bin/bash #winbind use default domain = yes allow trusted domains = yes socket options = IPTOS_LOWDELAY TCP_NODELAY SO_KEEPALIVE deadtime = 60 guest ok = no map to guest = Never [share] browseable = yes access based share enum = yes comment = batchserver follow symlinks = yes path = /gpfs1 read only = no inherit acls = yes map acl inherit = yes nt acl support = yes force group = "domain\domain admins" admin users = @"domain\domain admins" vfs objects = gpfs fileid shadow_copy2 shadow:snapdir = /gpfs1/.snapshots shadow:basedir = /gpfs1 shadow:fixinodes = yes fileid:mapping = fsname gpfs:sharemodes = No force unknown acl user = yes nfs4: mode = special nfs4: chown = yes nfs4: acedup = merge FYI - I'm also running the patch from bug #6762
I've seen this, too and 15e10c6a84c450fd5bc1b50a45bb1cfa049fb00d, which is the same thing that the patch from comment #6 addresses fixes that for the 3.5 setup that I had. Karolin, we need to pick that to 3.5.
sorry, the commit hash that we miss is 385d925f7e0fedca7d480e4f25d89e3194433b88. *That* one needs to be picked to 3.5 :-)
(In reply to comment #9) > sorry, the commit hash that we miss is > 385d925f7e0fedca7d480e4f25d89e3194433b88. *That* one needs to be picked to 3.5 > :-) > Pushed to v3-5-test. Closing out bug report. Thanks!