Yes, the server side shows no messages and doesn't seem to be affected. (At least it shows no messages where I looked but since I'm not an expert it's possible that I just dont know where to look at the server side)

And yes, the client can re-connect without any problems after the client has rebooted.

I did some tests in tty1 and got at least a little bit of information. Strange is, that not all tests runs showed the same behaviour.

First test: 
Copy a 4 GB File from a NFS share to the second (magnetic, sdb5) harddisk on my computer. 

Result: 
For one or two minutes nothing happened. Then the conosle showed some error-messages. Unfortunately I only have the second part of the messages, because the first page was 'out of screen' before I could take a picture.
The error messages are the following:
[5351.183955] end_request: I/O error, dev sdb, sector 131925003
(... this error repeadted a lot of times with different sector numbers ...)
[5351.203631] Aborting journal on device sdb5
[5351.203691] end_request: I/O error, dev sdb, sector 126666835
[5351.305377] EXT3-fs (sdb5): ext3_journal_start_sb: Detected aborted journal
[5351.305508] EXT3-fs (sdb5): ext3_journal_start_sb: remounting filesystem read-only
cp: schreiben von "bigfile.mkv": Read-only file system
("schreiben von" = "writing of")
After this error messages (of which, as I said, I unfortunately don't have the first part) the console was still working and I also could switch back to tty7 (GUI). As it stated in the messages it had remounted sbd5 with 'ro' (read-only).

So I decided to repeat the test to catch also the first part of the error messages, but..:

Second test: 
Copy again a 4 GB File from a NFS share to the second (magnetic, sdb5) harddisk on my computer. 
 
Result:
I waited for about 10 minutes, but nothing happened this time. No error messages but also no finishing of the copy proccess.
Yet I could switch to other text-consoles (tty2.. tty3.. didn't try to go to tty7 this time).
After those 10 minutes I tried to abort the copy proccess by hitting Ctrl+C which then seemed to lock-up also the console (I couldn't switch to other text-consoles anymore). So I rebooted the machine.

Third test:
Copy again a 4 GB File from a NFS share to the second (magnetic, sdb5) harddisk on my computer. 

Result:
I waited for about 40 minutes this time, but again: nothing happened. I still could switch to other text-consoles but when I tried to switch to the graphical 'tty7' I just had a black screen and couldn't do anything (also not switching back to tty1) then. So I had to reboot the machine again. 


Because of the error messages from the first test which looked likae a harddisk problem, I wanted to do a fourth test which should copy not to the magnetic harddisk but to the SSD harddisk I also have in my computer (note that of course I also tested copying to both disks long time before, so it's not the first time I try to copy to the SSD)


Fourth test:
Copy  a 4 GB File from a NFS share, this time to the first (solid-state, sda1) harddisk on my computer. 

Result:
I waited for about 20 minutes this time.. again: nothing happened. Same thing as in tests 2 and 3.


Something that I noticed during the testing:
While it 'tries' to perform the copy proeccess, the HDD-LED does not blink, so it does not indicate any activity on the Harddisk. (At least not after some minutes, I didn't pay attention in the first moments)
BUT during the whole 'pseudo' copy proccess the LED on the Network Switch indicates big activity on the port to which the client is connected. Strangely it does NOT indicate this activity on the port to which the server is connected... (and neither on the port to which the router/modem is connected). So it looks like "ghost traffic".. it comes from or goes to nowhere - at least according to the LEDs of the network switch.
(Another thing I noticed is, that most [or any?] of the affected people are using gigabit ethernet instead of 10/100)


I'm not sure what this test results tell us. On one hand we saw some odd behaviour in the first test... on the other hand, the other three tests (two of them were exactly the same setting as test 1) didn't show any error messages but just not finished the job.