Core FTP

In our SFTP Domain there is one user who has access to all subdirectories.
A second user is only allowed to use his home Directory; example:

Base directory of Domain: C:\intepub\ftproot\LocalUser
Home directory of user 2: C:\inetpub\ftproot\LocalUser\User2

For user 2 the check box "Lock user in home directory" is enabled.

This situation worked fine for several weeks.

Now there is a third user.
Home Directory of user 3: C:\inetpub\ftproot\LocalUser\User3
For user 3 the check box "Lock user in home directory" also is enabled.

SFTP Server restarted.
User 2 logs in: "Remote working directory is /"
User 2 logs out.
User 3 logs in: "Remote working directory is /"
User 3 logs out.
Until now all is correct. But then :
User 2 logs in: [b]"Warning: failed to resolve home directory: no such file or directory"[/b]
Nevertheless the dir command shows the correct files and subdirectories, but some sftp clients stop to work.

New try:
The check box "Lock user in home directory" is disabled for user 2 and 3.

SFTP Server restarted.
User 2 logs in: "Remote working directory is /User2/"
User 2 tries: "cd /" -> "Directory /: permission denied" (this is correct)
User 2 logs out.
User 3 logs in: "Remote working directory is /User3/"
User 3 logs out.
Until now all is correct. But then :
User 2 logs in: [b]"Remote working directory is /."[/b]
User 2: "dir" -> "Unable to open .: permission denied"
User 2: "cd User2" -> "Remote directory is now /./User2"

It looks like the server does not clean the directory info of the last user or does not always start in the users home directory.

Is there any way to "bypass" this error?

I found that the problem occurs when the home directories of one or more users should serve as virtual paths for another user.

In the documentation one finds the hint:
"As a reminder, if you lock a user in their home directory, they will not be able to access virtual paths."
This is wrong!
When you do so than the command "cd .." in an virtual path tries to go up within the physical path, which is not what the user expects.

I would strictly recommend to lock a user in his home directory.

But there are more confusing effects.

I found my solution:
Do not use virtual path. Use the windows command "mklink".