NFS root unexpectedly squashed

While experimenting with setting up ltsp on Fedora 18, I came across a strange NFS behaviour which took quite some time to iron out.

I was already exporting /opt as a read only file system; however, with root squashed. LTSP added another export for /opt/ltsp with no_root_squash option. 

/opt *(ro,sync,no_subtree_check)
# export for LTSP version 5
/opt/ltsp   *(ro,no_root_squash,async,no_subtree_check)

Everything seemed to be sort of working with a few strange effects, e.g. I could not use passwords and some ltsp scripts were failing.
The problem was that root seemed to be still squashed:

[anil@localhost ~]$ sudo mount amd:/opt/ltsp/x86_64 /mnt
[anil@localhost ~]$ cd /mnt/home
[anil@localhost home]$ ls -l
total 8
drwxrwx--- 2 anil  anil  4096 Apr  6 13:04 anil
drwx------ 2 guest guest 4096 Apr 10 12:35 guest
[anil@localhost home]$ sudo su
[root@localhost home]# cd anil
bash: cd: anil: Permission denied

A workaround was to use fsid=0 although whatever documentation I came across seemed to suggest that it was no longer needed:

/opt/ltsp   *(ro,fsid=0,no_root_squash,sync,no_subtree_check)

Unfortunately, I had forgotten that /opt was also being exported and noticed it only after finding the work-around and getting ltsp to work on Fedora 18.

Importance of Error Messages

I was trying out Asterisk server and Sip clients. I used ekiga as a client. It would just fail to register.

I tried on Fedora and Ubuntu in a VM. Same symptoms. I was running the server and the client on the same machine.

Googling did not help. Then on Ubuntu, I installed an alternate client - Twinkle. The message now was - port 5060 already in use. It was obvious - both the Asterisk server and the client were trying to listen on 5060 and I should have known that. I used an alternate port for Twinkle and it worked.

I tried Ekiga from Fedora with Asterisk running under Ubuntu in a VM. It worked!

If only Ekiga had a little finer exception handling and gave the reason for failing to register!

Lesson in Programming on Western Railway - Exception Handling

Even after over 30 years, some of the memories of traveling in Western Railway of Bombay suburban are very vivid. Some of these experiences have made me conscious of a number of critical programming concepts.
For example, exception handling is a must. If you can't handle a problem, pass it to someone else who can.
I was returning home and crowd was the usual size. We try to rush in and, hopefully, into the compartment so that we are not hanging from the door.
I try to get in from the left side of a pole in the center of the door. I suddenly find that a fellow passenger is trying to get in from the right side of the pole. Nothing wrong with it except that his arm is going around my neck. Neither can get on board and the harder he tries, the worse my condition.
To this day I cannot figure out how such a configuration occurred; but many problems in a multi-threaded application do not make any sense either. For a few seconds, I was sure that this was the absurd end to my life. However, other passengers realizing the deadlock, made the other passenger release his grip and I could board the train and then so could he.
I did not get an apology. Did not expect it either. I was just grateful for the release.