There is nothing wrong with your deployment when it comes to the xrootd version, it was just a bug on your side that will be fixed in the next release as it’s already addressed by this commit: https://gitlab.cern.ch/dss/eos/-/commit/840f5a88db74fd5d0921edea2c8d964b56e09b03
For the log line related to fsctl function this is normally the result of something trying to do an XRootD query againt the FST daemon. We only support a limited set of query commands that the FST can reply to. For example this query would trigger the same log signature that you have:
sudo xrdfs root://localhost:2001 query space /eos
[ERROR] Server responded with an error: [3010] Unable to execute fsctl function ; operation not permitted
This leaves the following sigature in the logs:
240131 09:09:02 24285 XrootdXeq: root.27136:35@localhost pvt IP64 login as root
240131 09:09:02 24285 FstOfs_fsctl: root.27136:35@localhost Unable to execute fsctl function ; operation not permitted
240131 09:09:02 24285 XrootdXeq: root.27136:35@localhost disc 0:00:00
I have pushed the following commit to actually display the command and the arguments passed to this call so we can more easily identify in the next release the exact command. https://gitlab.cern.ch/dss/eos/-/commit/b1962bc644043abcfbd2e50ad2d74f42ebe6e291
Using this the output in the logs looks like this:
240131 09:17:00 31857 XrootdXeq: root.988:60@localhost pvt IP64 login as root
240131 09:17:00 31857 FstOfs_fsctl: root.988:60@localhost Unable to execute fsctl function cmd=3 args="/eos"; operation not permitted
240131 09:17:00 31857 XrootdXeq: root.988:60@localhost disc 0:00:00
Once you’ll have the next release in production (5.2.9) we can more easily identify who/what is calling this API.