We have the following scenario using schooldistrictsite as an example.

Primary Portal running as schoolDistrictSite
Sub Portal running as highschoolSite

Our sub portal has the following portal aliases
schooldistrictsite.com/highschoolsite
www.schooldistrictsite.com/highschoolsite

When we browse to schooldistrictsite.com/highschoolsite we get redirected to schooldistrictsite.com/Default.aspx?alias=schooldistrictsite.com/highschoolsite as expected...

The problem arises when we begin to navigate through the site... If we try to click on the about us page, the URL reads schooldistrictsite.com/highschoolsite/SchoolInfo/About.aspx and the page is displayed... but any subsequent click result in a "The resource cannot be found." error... and the sub portal "folder" get's removed from the url resulting in schooldistrictsite.com/SchoolInfo/Classes.aspx (notice the dropped /highschoolsite/)

Why is the sub portal "folder" getting dropped out of the urls after the first initial click into the site?  Am I missing something?  

Typically Sub Portals would have their own domain pointed to them, but in this case, it is not needed.

Any help wold be greatly appreciated.

Thanks in advance.

Generally if you get into a situation where all the generated links ( menus  breadcrumbs etc)  are incorrect is because the wrong portal alias has been identified by the request, and so all the links are pointing in the wrong place.

I haven't seen this problem myself, but my first place to check would be the list of portal aliases for both the parent and the child portal.  I would enter the example.com and www.example.com entries for the parent and the example.com/child and www.example.com/child for the child portal. 

You can also do a roundabout check on this by including a &portalid=x with the request to see if that helps bring up the right links (by explicitly specifying the portal).  This would be just to check if it's the wrong portal being identified that is causing the issue.  With parent portals/ child portals, it's easier to get into trouble because the Url Rewriting has to determine the portal based on the domain name, and in this type of situation they look very similiar.

Has this ever worked since the portal was created? Have you tried creating a test portal to see if the behavior is consistent?

Jeff