java.io.IOException: Could not copy remoting.jar into '/export/build' on agent

Communication between jenkins and the agents fails with

[12/13/21 17:53:49] [SSH] Checking java version of /usr/lib/jvm/java-openjdk/bin/java
[12/13/21 17:53:49] [SSH] /usr/lib/jvm/java-openjdk/bin/java -version returned 1.8.0_302.
[12/13/21 17:53:49] [SSH] Starting sftp client.
[12/13/21 17:53:49] [SSH] Copying latest remoting.jar...
java.io.IOException: Could not copy remoting.jar into '/export/build' on agent
	at hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:739)
	at hudson.plugins.sshslaves.SSHLauncher.access$400(SSHLauncher.java:112)
	at hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:457)
	at hudson.plugins.sshslaves.SSHLauncher$1.call(SSHLauncher.java:422)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalArgumentException: invalid len argument
	at com.trilead.ssh2.SFTPv3Client.read(SFTPv3Client.java:1232)
	at com.trilead.ssh2.jenkins.SFTPClient$SFTPInputStream.read(SFTPClient.java:172)
	at com.google.common.io.ByteStreams.toByteArrayInternal(ByteStreams.java:184)
	at com.google.common.io.ByteStreams.toByteArray(ByteStreams.java:224)
	at hudson.plugins.sshslaves.SSHLauncher.readInputStreamIntoByteArrayAndClose(SSHLauncher.java:797)
	at hudson.plugins.sshslaves.SSHLauncher.copyAgentJar(SSHLauncher.java:708)
	... 7 more
[12/13/21 17:53:49] Launch failed - cleaning up connection
[12/13/21 17:53:49] [SSH] Connection closed.

If I remove the remote.jar manually then it works for a short time, but then the error comes back. Jenkins is version 2.325, as provided by Jenkins’ Debian repository. Java is AdoptOpenJDK 8u292.

Seems to be related to JENKINS-67258, but apparently this serious problem has been ignored, so every helpful comment is highly appreciated.

PS: Its JDK 8u302.
some more text has to be added here to make the web interface happy

Is /export/build an NFS file system? NFS file systems have a different locking mechanism than local file systems and may behave differently than local file systems.

If it is an NFS file system, does the same problem exist if you configure the agent to place the remoting jar file on a local file system?

Is the network connection between the agent and the controller allowed to transfer large files?

Looks like a known issue - I’m run also into after update Jenkins to 2.332.2 - solution: [JENKINS-67258] Could not copy remoting.jar - Jenkins Jira - Update SSH Build Agents plugin