Trouble using eups distrib install with extended ACLs

Hi,
I’m building DMstack (lsst_distrib) at SLAC, using the same version I recently set up at NERSC. It seems extended ACLs were recently enabled on our NFS space and this is causing trouble when cp is used during the build process. I’m wondering if anyone else has experienced this and if there might be a workaround.
Here is a related stack exchange link:

and here’s the tail end of the build.log for apr:

/usr/bin/install -c -m 644 apr.pc /nfs/farm/g/desc/u1/software/redhat6-x86_64-64
bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/lib/pkgconfig/apr-1.pc
for f in libtool shlibtool; do \
	    if test -f ${f}; then /usr/bin/install -c -m 755 ${f} /nfs/farm/g/de
sc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/build-1; fi; \
	done
/usr/bin/install -c -m 755 /nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/apr-1.5.2/apr-1.5.2/build/mkdir.sh /nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/build-1
for f in make_exports.awk make_var_export.awk; do \
	    /usr/bin/install -c -m 644 /nfs/farm/g/desc/u1/software/redhat6-x86_
64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/EupsBuildDir/Linux64/apr-1.5.2/apr-1.5.2/build/${f} /nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/build-1; \
	done
/usr/bin/install -c -m 644 build/apr_rules.out /nfs/farm/g/desc/u1/software/redh
at6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e
67/Linux64/apr/1.5.2/build-1/apr_rules.mk
/usr/bin/install -c -m 755 apr-config.out /nfs/farm/g/desc/u1/software/redhat6-x
86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/bin/apr-1-config
cp: preserving permissions for `/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/
1.5.2/ups/apr.cfg': Operation not supported
cp: preserving permissions for `/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/ups/apr.table': Operation not supported
cp: preserving permissions for `/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bi
t-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/ups/eupspkg.cfg.sh': Operation not supported
cp: preserving permissions for `/nfs/farm/g/desc/u1/software/redhat6-x86_64-64bit-devtoolset-3/DMstack/w_2017_26_py3/stack/miniconda3-4.2.12-7c8e67/Linux64/apr/1.5.2/ups/pkginfo': Operation not supported
+ exit -5

Thanks,
Heather

We might get away with modifying eupspkg.sh to use cp -p (possibly with additions if we really want symlinks) instead of cp -a.

Thanks, @ktl. I tried modifying eupspkg.sh, using -p didn’t change the result, but using -dR worked. That allowed me to get beyond the apr package, however, cfitsio failed with the same error. Apparently cfitsio’s Makefile includes a “/bin/cp -a”. I’ll try fixing that up and hope that no other packages similarly use “cp -a” during their build process. Meanwhile, the SLAC computing group is looking to disable the extended ACL on our end (not optimal as we want to use ACLs) or find some other solution.
Take care,
Heather

I think the problem is that the extended ACLs aren’t available on both sides (the source and destination of the copy). So either disabling them on the source side or enabling them on the destination would solve this.