Dmitry Litvintsev

Restart of client (or pool) apparently kills that connection and file can be copied again! This issue is affecting us badly.

``` dunegpvm09(rw,lt=nfsv4_1_files:flex_files) ``` is in `/etc/exports` We do not know what is the cause and effect here. An attempt to run `cp` on a file ends up with no interaction...

[nfs.dump.gz](https://github.com/dCache/dcache/files/8035634/nfs.dump.gz) Here we go, dcpdump attached ``` tcpdump -i eth0 -w /tmp/nfs.dump host mu2egpvm01 ```

access file for this interaction: ``` level=INFO ts=2021-11-01T14:37:05.685-0500 event=org.dcache.ftp.hello session=door:GFTP0-fndca4b-AAXPv01F4lA@gridftp0-fndca4bDomain socket.remote=131.225.67.13:43624 socket.local=131.225.69.121:2811 reply="220 GSI FTP door ready" level=INFO ts=2021-11-01T14:37:05.687-0500 event=org.dcache.ftp.response session=door:GFTP0-fndca4b-AAXPv01F4lA@gridftp0-fndca4bDomain command="AUTH GSSAPI" reply="334 ADAT must follow" level=INFO ts=2021-11-01T14:37:05.702-0500 event=org.dcache.ftp.response...

Excellent suggestions, Paul, as always. The Issue has been created as a place holder to go back to if team has no immediate ideas what that might be. It is...

``` doors=`zgrep -B1 'TooLongFrameException' gridftp0-fndca4bDomain.log-20211102.gz | grep GFTP | awk '{ print $5}' | sed -e 's/[\(\)]//g'` [root@fndca4b dcache-log]# for d in $doors ; do zgrep "$d" gridftp0-fndca4bDomain.access.2021-11-01.gz | grep...

I vouch that this is expected behavior. You see you need to know file ID to get the metadata which is not possible if you can't query it by path....

So here we go. I would leave it as is ;)

Has this been looked at? I just deployed trunk and I see the same exception on upload

There is also issue https://github.com/dCache/dcache/issues/6783 on that same problem. That issue observed on the clean install of trunk on all servers. So all is consistent.