ALICE TPC - Operation nor supported


The external, MonALISA, TPC test from ALICE is currently failing on our EOS/CTA instance with the (client) message

xrdcp (TPC==1) exited with exit code 50: [ERROR] Operation not supported: Destination does not support third-party-copy

I can’t understand whence this error since I do have the following directive defined in /etc/

ofs.tpc autorm ttl 80 90 xfr 200 pgm /etc/xrootd/

where the contents of the /etc/xrootd/ are


/usr/bin/xrdcp --server -f $1 root://$2

I noiticed that the above ofs.tpc directive doesn’t appear in the log after restarting the eos@mgm service which makes me suspect that it is ingnored by EOS but why? Do you have any ideas?



You have to check if your FSTs configure TPC:|

ofs.tpc pgm /opt/eos/xrootd/bin/xrdcp

Unless you want delegated TPC transfers, you don’t need any entry in the MGM config file.

Cheers Andreas.

Hi Andreas,

Thanks for the reply. I inserted the ofs.tpc directive in the FST config trying both /usr/bin/xrdcp and the script with the line
/usr/bin/xrdcp --server -f $1 root://$2

but I get an auth error for the source file now,

211204 13:36:31 time=1638624991.422830 func=fileOpen level=ERROR logid=30a2eade-5507-11ec-a26f-1c34da4b345c tid=00007f7ac82f0700 source=XrdIo:285 tident= sec= uid=0 gid=0 name= geo="" error= “open failed url=root://, errno=0, errc=204, msg=[FATAL] Auth failed”

The client-side error is

xrdcp (TPC==1) exited with exit code 54: [ERROR] Server responded with an error: [3012] sync - TPC open failed for src_url=root://

You need in /etc/sysconfig/eos_env on your FSTs:


Cheers Andreas.

Many thanks for the amazing response; it worked.

I understand that this flag disables SSS auth when doing an XRootD
transfer with another FST node.

In this thread

Elvin made the following comment “This env can be used for instances that you control (both source and destination) but is not a recommended way for doing TPC with external sites” which sounds like against using the EOS_FST_NO_SSS_ENFORCEMENT



Hi George,
yes, if you use an external proxy xrootd to do transfers, you can configure the MGM to redirect TPC transfers to that one. EOS_FST_NO_SSS_ENFORCEMENT is not really an issue. The only ‘issue’ is, that if you do a TPC transfer in XRootD4, the open path + the single file token is transferred unencrypted on the wire. Once we all run Xrootd5 the open path the file token will also be encrypted, but this has really nothing to do with using sss or not. You can connect an FST in any case without sss. On the other hand the token is valid for a limited time and only grants read or write access to a single file, so the ‘risk’ is not really very high.

Cheers Andreas.

Hi Andreas,

Thanks for clarifying sll this.

I noticed that while the MonALISA TPC test had been green from some time, at some point it started failing again with the a “Permission denied” error which looks like the one below. It is not the “Auth failed” error which I got in the beginning before finalising the config.

I do notice the incorrect “uid=0 gid=0” in the error. I wonder why this happens?

Is there some funny cacheing going on with the auth? I have noticed that occassionaly “eos whoami” shows me as “daemon” whereas it should show me as root according to

tident:"":gid => root
tident:"":uid => root

which is it does if I open another ssh session to the MGM…

211214 15:42:30 time=1639496550.230776 func=fileOpen level=ERROR logid=3285f484-5cf2-11ec-bce4-1c34da4b345c tid=00007ff8635fb700 source=XrdIo:285 tident= sec= uid=0 gid=0 name= geo="" error= “open failed url=root://, errno=3010, errc=400, msg=[ERROR] Error response: Permission denied”