I think I found out what is happening as I had the same problem.

Actually, when i first setup FTP accounts on my IIS server, service pack
1 for win 2003 was already installed. FTP worked just fine.

I uninstalled service pack 1 to try to resolve another problem i was
having with frontpage 2002 extensions search components displaying
results from other web sites at the bottom of the results (although
clicking on the results doesn't open the page thank goodness.)

MS knows there are some issues with service pack 1 and IIS6 and I
believe are in the process of fixing service pack 1 for some IIS6
issues. (nothing like needing a service pack to fix a service pack
eh?!)

Anyhow, when i reinstalled service pack 1 since there were more problems
without it in my configuration now, then with it, this new problem you
are describing i also had.

I found out what was happening - service pack 1 installed on top of
existing FTP sites, will change them all into being isolated user mode,
even though the IIS setting does not show it as isolated user mode.
Chances are if you look in your web root directory, you'll see a
directory name spelled the same as the userid you are using to FTP in.
And that is the directory you are being taken to when FTPing in.

The solution I will now try, will be to change the path of the FTP
account in IIS6, and this should work as long as your userid is spelled
the same as your web root directory name. It's a workaround not a bug
fix though keep in mind.

... continued from above post number 13 ***

However - some of the FTP sites on my server *work*.

Which sites are getting switched automatically into ftp isolated mode
and why i'm not sure.

The two so far that i have looked at where this happened, both use
frontpage extensions, and have some unique NTFS permissions in the /fpdb
folder to make their frontpage wizard MS Access databases writeable by
anon internet user and by network service (i add network service now by
habit in IIS6 with write permissions just as i do with IUSR_xxx anon
internet user, as i needed to do that to resolve an ASP.NET issue in
IIS6.)

Note also in my environment PASV mode is disabled and not allowed in our
firewall.

Also in my environment, of the 2 FTP sites I have this issue with that i
know of so far (havn't had time to test them all yet and have only had 2
customers report the problem yet i installed service pack 1 just a few
days ago), the userid is the same as the root web directory name of the
web site.

To further complicate the issue - i think i was able to login just fine
this morning unless i was seeing a cache of the directory listing.
While my customer was reporting the problem.

At any rate my workaround does work. You change the path in the FTP
account in IIS6, one level deeper, and as long as your root web
directory name is the same as your userid, it'll fool this problem into
working, as instead of say putting you into D:\inetpub\acme\acme which
is what this bug is doing, while the IIS FTP site is configured to put
you into D:\inetpub\acme\, you change the IIS path to put you into
D:\inetpub - and as dangerous as that sounds, it works regarding this
bug.

Speaking of dangerous though - when MS fixes this bug fix, I hope I
remember to change the path back to the real path not the mother inetpub
path, or else there could be a security breach. I doubt it though as
the NTFS permissions would not allow the other user to read or write
anything. At that time the customers will complain again they dont' see
their files and i'll have to change their FTP account path to their real
one.

... continued from posts 13 and 14 ...

To further complicate the issue, (because i noticed one of the 2 sites i
had this issue on had the userid directory name in double while the
other one didn't)

D:\inetpub\acme\acme - an extra \acme directory which was the one that
FTP was putting the FTP user into.

So i first deleted the 2nd acme directory out. Changed the FTP account
path to the real one (D:\inetpub\acme not D:\inetpub which is the
workaround path). Turned the FTP site off then back on. And got in
fine this time.

I changed the path on the other site, turned the ftp site off then on
again, and got in fine as well.

I am now thinking it may be certain FTP programs are triggering this, or
it could be that it just happens randomly. The one customer was using
CUTE FTP when they reported the problem. While I use IE Browser as my
FTP program.

I'll ask the other customer what he was using.

I'll report back here with another followup post if it happens again to
these same customers tomorrow, and if so, whether or not the workaround
is a permanent fix for now until service pack 1's service pack 1 is
released. : )

... continued from previous posts ...

Well as a followup, this problem went away in my case. I don't know if
it is because i removed the \inetpub\acme\acme 2nd acme directory in
that one case, or because i changed FTP site paths to one level deeper,
then after removing the 2nd \acme directory changed it back, or what.
But the problem of installing service pack 1 for windows 2003 server on
a production web/ftp server switching ftp accounts into user isolated
mode does not exist anymore on my server.

fred