It most likely indicates a problem with NFS file locking on your machine.
It does look like the proper NFS utils are running, and portmapper seems to be doing OK:
ganymede: 09:00pm# rpcinfo -p
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100021 1 udp 32769 nlockmgr
100021 3 udp 32769 nlockmgr
100021 4 udp 32769 nlockmgr
100024 1 udp 892 status
100024 1 tcp 895 status
Can you try something else for me? Can you leave the hung process sitting in one window, and try to run your script a second time in another window? Also, let the hung process sit there for at least 15 minutes and see if it ever completes.
I’ve seen some problems like this, where an fcntl lock fails the first time, but not the second. For example, if you create an mbox file and do:
mutt -f mboxfile
mutt will hang for a couple of minutes, and will give an error about not being able to lock the file. However, if you then run the same command from a second terminal, it works OK.
I have seen this happen to some users (with mutt, bogofilter, and other programs which lock using fcntl), but I haven’t had much luck figuring out what the exact problem is - maybe some obscure NFS bug.
To be clear, user home directories are mounted via NFS (network file system). /tmp is a local disk, which is why you’re not seeing the same problem in /tmp. You could (as a workaround) use a .lock file instead of fcntl locking, or else you could perform the operation in /tmp and copy the resulting files to your home dir.