The FrontPage client doesn't like it when it can't write to files in it's web space. This became a problem for us because we run a cronjob every night that processes a user's web log and puts the results in www/http-analyze. The job runs as root, so the output directory is owned as root, and therefore is not writable by the FrontPage client. This was discovered after a user reported that whenever he published his site, he would get the error "Server error: Cannot change permissions on file: /home/user/www/http-analyze/index.html". Uh, yeah, that's a server error isn't it. :-)

The solution to this problem is kind of a hack, but it works. We changed the permissions on the http-analyze directory to 751 so that normal users and the FrontPage clients could still enter the directory, but could not list the files. After making this change, the FrontPage client stopped complaining after making this change. So I guess the baby logic behind that is that if the FrontPage client can't see it, then it doesn't bother with it. The better solution for us would be to modify the stats output program to chown the files after writing them to disk, which is something we will probably do. But there may be cases where you can't do that. So thus, I present this solution to you.

If you are hosting virtual domains on a shared server you will need to put a file called postinfo.html in each virtual domain user's web directory. This file has a variable line in it called BaseUrl= that holds the name of the domain to which the site is being published. This value is the full hostname that the user should publish their site to. Note that if that user tries to switch back and forth between publishing to their virtual domain and their ~username address, the FrontPage bots will not work for the address that they did not publish too. This is a very lame "feature" of FrontPage that should be fixed but probably won't be. Sigh.