Bug 7498 - robocopy fails to a GPFS share when setting the date
Summary: robocopy fails to a GPFS share when setting the date
Alias: None
Product: Samba 3.5
Classification: Unclassified
Component: VFS Modules (show other bugs)
Version: 3.5.7
Hardware: All Linux
: P3 major
Target Milestone: ---
Assignee: Karolin Seeger
QA Contact: Samba QA Contact
Depends on:
Reported: 2010-06-07 14:00 UTC by chris
Modified: 2011-03-01 14:33 UTC (History)
1 user (show)

See Also:
bjacke: review+

Packet capture during robocopy run with a test file (8.59 KB, application/octet-stream)
2010-06-07 14:06 UTC, chris
no flags Details
smbd debug log (35.78 KB, text/plain)
2010-06-07 14:09 UTC, chris
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description chris 2010-06-07 14:00:51 UTC
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.

Comment 1 chris 2010-06-07 14:06:05 UTC
Created attachment 5763 [details]
Packet capture during robocopy run with a test file

Packet capture
Comment 2 chris 2010-06-07 14:09:43 UTC
Created attachment 5764 [details]
smbd debug log

smbd debug log
Comment 3 JR 2010-06-17 11:56:01 UTC
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.
Comment 4 John H Terpstra (mail address dead( 2010-07-14 22:07:47 UTC
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.
Comment 5 Michael Adam 2010-08-03 15:08:19 UTC
Could you please add the following details:

* version of gpfs
* version of ctdb
* samba config

Comment 6 JR 2010-08-04 12:29:57 UTC
(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
gpfs2:/space$ rpm -qa |grep ctdb
gpfs2:/space$ rpm -qa |grep gpfs

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;
Comment 7 chris 2010-08-04 12:47:36 UTC
As requested:

conas-01 ~ # rpm -qa | grep samba

conas-01 ~ # rpm -qa | grep gpfs

        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

        deadtime = 60
        guest ok = no
        map to guest = Never

        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
Comment 8 Björn Jacke 2011-03-01 03:54:03 UTC
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.
Comment 9 Björn Jacke 2011-03-01 04:05:06 UTC
sorry, the commit hash that we miss is 385d925f7e0fedca7d480e4f25d89e3194433b88. *That* one needs to be picked to 3.5 :-)
Comment 10 Karolin Seeger 2011-03-01 14:33:20 UTC
(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.