 |
 |
[vokac@ui1 tpc]$ gfal-copy root://golias100.farm.particle.cz/dpm/farm.particle.cz/home/atlas/1M root://dcache-atlas-xrootd-wan.desy.de:1094/pnfs/desy.de/atlas/dq2/atlasscratchdisk/SAM/1M Copying root://golias100.farm.particle.cz/dpm/farm.particle.cz/home/atlas/1M [FAILED] after 3s gfal-copy error: 42 (No message of desired type) - Error on XrdCl::CopyProcess::Run(): [ERROR] Server responded with an error: [4003] Authentication to golias100.farm.particle.cz:1094 failed; all protocols have been tried. [vokac@ui1 tpc]$ gfal-copy root://golias100.farm.particle.cz/dpm/farm.particle.cz/home/atlas/1M root://grid-se.physik.uni-wuppertal.de:1094/pnfs/physik.uni-wuppertal.de/data/atlas/atlasscratchdisk/SAM/1M Copying root://golias100.farm.particle.cz/dpm/farm.particle.cz/home/atlas/1M [DONE] after 1s
[log in to unmask]">Hi all,
we are currently updating the dCache instances in Wupeprtal and DESY-HH to be xrootd TPC ready.
We started with Wupeprtal and experience some problems where third party copies 'in one direction' work but fail in the other.
From the debug output, I assume that the difference between
--tpc only
and
--tpc delegate only
is like for HTTP TPC PUT vs. GET, i.e., if the Source or the Sink create the proxy and the other end point uses the proxy info to copy to/from, or?
The working copy
Wuppertal --> DESY-HH with --tpc delegate only
https://desycloud.desy.de/index.php/s/R2ZoQfENEqe8ixD/download
seems a bit odd, as first an authz handshake with the DESY-HH node seems to fail due to a denied permission.
And then falls back to "a third party fall back copy job", where it seems to request a TPC token from the Wupeprtal node. At the DESY-SE the client gets properly redirected to the pool dcache-dot18.desy.de, which has a 'TPC lite' support - what does that mean actually 🤔?
After whcih the transfer is actually started
The failing copy
Wuppertal --> DESY-HH with --tpc only
https://desycloud.desy.de/index.php/s/kGtefD6qN2H8qGR/download
starts apparently also handshaking with the DESY-HH node first - before it also(??) falls back to a "third party copy job" but mentions "We are NOT using delegation" 🤔 .
The client again is redirected to a sink pool dcache-dot23.desy.de but fails then due to a" Permission denied".
Is this permission denied due to the token not being accepted by dcache-dot23.desy.de or because the client authz fails to request the actual token? (but then why does the client mentions that it is not using delegation? 🤔)
Long story short: at which end of the two instances do we have an autghz(?) problem
Cheers and thansk for any ideas,
Thomas
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-L list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-L&A=1