Access Denied (Temporarely) to Virtual Directory for FTP User Account
I am having a problem with a Windows 2003 Server Standard Edition SP2 running IIS6.
On that machine is FTP configured using the IIS6 User Isolation feature. FTP Users are all local users. Because of the isolation mode, the home folder structure for the FTP server looks like this:
c:\FTPRoot
\LocalUser
\user1
\user2
User1 has access to the Web server root folder on the same drive. To do this, a virtual directory was created for user1, which maps to the web root folder (e.g. c:\WWW) That user1 is able to see the virtual directory, an empty folder was created under the FTP home directory of that user also. Like this c:\FTPRoot\LocalUser\user1
The user has full permission to all files and folders, including all levels of the FTP tree and WWW, in IIS and Windows permissions. The FTP user is not a server administrator. It's just a regular user.
One additional setting that I should mention is that for the FTP home directory and subsequent sub folders the access was restricted to only allow a few specified IP addresses from where user1 is allowed to connect to the server.
During regular file transfers does it occur frequently that user1 suddenly looses access to the WWW virtual directory, returning the error that user1 has insufficient permissions to access the folder/virtual directory. After 10-15 minutes being disconnected from the FTP, user1 has full access to the virtual directory again. User1 can always connect to the FTP and access his FTP home directory and only looses access to the VD. The FTP sipply returns an "Access Denied" error message.
I have no idea what causes this temporary lock-out. It seems to be related to the amount or frequency of connections made. The easiest way to cause the lock is to start a batch upload of many small files to the server with a FTP client that creates new connections for each file to transfer (like CuteFTP). Also the access with a source code editor with FTP support and frequent "saving" of a script on the server has the same effect.
I would be glad for any tips and ideas regarding the cause of this odd behavior and how to get around it. Thanks.
On that machine is FTP configured using the IIS6 User Isolation feature. FTP Users are all local users. Because of the isolation mode, the home folder structure for the FTP server looks like this:
c:\FTPRoot
\LocalUser
\user1
\user2
User1 has access to the Web server root folder on the same drive. To do this, a virtual directory was created for user1, which maps to the web root folder (e.g. c:\WWW) That user1 is able to see the virtual directory, an empty folder was created under the FTP home directory of that user also. Like this c:\FTPRoot\LocalUser\user1
The user has full permission to all files and folders, including all levels of the FTP tree and WWW, in IIS and Windows permissions. The FTP user is not a server administrator. It's just a regular user.
One additional setting that I should mention is that for the FTP home directory and subsequent sub folders the access was restricted to only allow a few specified IP addresses from where user1 is allowed to connect to the server.
During regular file transfers does it occur frequently that user1 suddenly looses access to the WWW virtual directory, returning the error that user1 has insufficient permissions to access the folder/virtual directory. After 10-15 minutes being disconnected from the FTP, user1 has full access to the virtual directory again. User1 can always connect to the FTP and access his FTP home directory and only looses access to the VD. The FTP sipply returns an "Access Denied" error message.
I have no idea what causes this temporary lock-out. It seems to be related to the amount or frequency of connections made. The easiest way to cause the lock is to start a batch upload of many small files to the server with a FTP client that creates new connections for each file to transfer (like CuteFTP). Also the access with a source code editor with FTP support and frequent "saving" of a script on the server has the same effect.
I would be glad for any tips and ideas regarding the cause of this odd behavior and how to get around it. Thanks.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Hi CJ,
The user will not be able to see the www directory, if I remove the physical directory in the user directory. He can still access it directly via the ftp client though, so I will give it a shot and let you know what comes out of it. Thanks.
Cheers!
The user will not be able to see the www directory, if I remove the physical directory in the user directory. He can still access it directly via the ftp client though, so I will give it a shot and let you know what comes out of it. Thanks.
Cheers!
I haven't had a chance to play around with the IIS FTP server much BUT ... if there is a virtual directory, as opposed to a physical one, that is created in the user directory then the virtual should still show up unless this is not a feature in FTP like it is in WWW. If you do not have the option of creating a virtual directory, try just placing a link in the user's directory and see if FTP will accept this as a valid directory reference and direct the user to the correct place without creating a physical directory.
ASKER
Hi CJ,
The IIS 6 Isolation Mode feature works a bit different than the traditional FTP setup.
Isolation mode requires a specific WINDOWS folder structure within the FTP root.
It also requires that real windows users are created and given appropriate permissions to access the required resources. In my case are all FTP users local users. The home folder directory structure must reflect that like this:
DRIVE:\FTProot\LocalUser\U
A domain user would require the existance of a physical home folder at
DRIVE:\FTProot\DomainName\
You have to make sure that the FTP users also have "scan" permission for the Drive root, the FTP root and also DomainName folder and/or LocalUser folder. Then you can specify the actual FTP permissions for the User home folder (e.g. read only, write, delete etc.)
In IIS is it not necessary to recreate the same folder structure as in Windows.
A virtual directory with the user name in the IIS FTP root that points to the appropriate Windows User Account Sub folder is sufficient. You have to make sure that the Windows user for the FTP account has the right permissions to access his virtual directory.
Such as:
FTPSiteNameInIIS\Username
If a FTP user requires access to another directory above his own user home folder within the FTP Root
(e.g. if 2 FTP Accounts need access to the same files) or outside the FTP root altogether, a virtual directory must be created below the users virtual home directory which points to the ppropriate Windows folder and has the right permissions (on IIS level AND Windows level)
For some weird reason that is not clear to me this time is it required to have a virtual dir in the root of the FTP for every folder outside the FTP server home directory.
That virtual directory also has to point to the same source, as the equally titled version on he user account level. It appears that the Virtual directory in the root of the FTP server is the Gate where all users with permission have to be funneled though. The virtual directory down at the user account level serves in this scenary only as a feed or door lock to get out of the isolation. There is no link between the two virtual directories with the exception that both point at the same target windows directory.
Or in other words, If you don't create the second virtual directory, then the user will not be able to access the folder outside the FTP directory structure, even if you created a virtual directory under the FTP user itself with all permissions etc.
So in my case was it necessary yo create the "WWW" virtual directory once as a virtual subdirectory in IIS like FTPSiteInIIS\VirtUserHome\
If you do not create a physical directory WWW under the physical home directory of the user, then the user won't see it. I tried that. If I type "dir' or 'ls', it won't show, but I can jump into it via 'cd www'.
Well, I provided all this background that more people will find this question and at least learn something from it and somebody might also has an answer to my question as well :)
The IIS 6 Isolation Mode feature works a bit different than the traditional FTP setup.
Isolation mode requires a specific WINDOWS folder structure within the FTP root.
It also requires that real windows users are created and given appropriate permissions to access the required resources. In my case are all FTP users local users. The home folder directory structure must reflect that like this:
DRIVE:\FTProot\LocalUser\U
A domain user would require the existance of a physical home folder at
DRIVE:\FTProot\DomainName\
You have to make sure that the FTP users also have "scan" permission for the Drive root, the FTP root and also DomainName folder and/or LocalUser folder. Then you can specify the actual FTP permissions for the User home folder (e.g. read only, write, delete etc.)
In IIS is it not necessary to recreate the same folder structure as in Windows.
A virtual directory with the user name in the IIS FTP root that points to the appropriate Windows User Account Sub folder is sufficient. You have to make sure that the Windows user for the FTP account has the right permissions to access his virtual directory.
Such as:
FTPSiteNameInIIS\Username
If a FTP user requires access to another directory above his own user home folder within the FTP Root
(e.g. if 2 FTP Accounts need access to the same files) or outside the FTP root altogether, a virtual directory must be created below the users virtual home directory which points to the ppropriate Windows folder and has the right permissions (on IIS level AND Windows level)
For some weird reason that is not clear to me this time is it required to have a virtual dir in the root of the FTP for every folder outside the FTP server home directory.
That virtual directory also has to point to the same source, as the equally titled version on he user account level. It appears that the Virtual directory in the root of the FTP server is the Gate where all users with permission have to be funneled though. The virtual directory down at the user account level serves in this scenary only as a feed or door lock to get out of the isolation. There is no link between the two virtual directories with the exception that both point at the same target windows directory.
Or in other words, If you don't create the second virtual directory, then the user will not be able to access the folder outside the FTP directory structure, even if you created a virtual directory under the FTP user itself with all permissions etc.
So in my case was it necessary yo create the "WWW" virtual directory once as a virtual subdirectory in IIS like FTPSiteInIIS\VirtUserHome\
If you do not create a physical directory WWW under the physical home directory of the user, then the user won't see it. I tried that. If I type "dir' or 'ls', it won't show, but I can jump into it via 'cd www'.
Well, I provided all this background that more people will find this question and at least learn something from it and somebody might also has an answer to my question as well :)
ASKER
p.s. You do not have to create the second virtual directory in the FTPRoot for creation virtual directories within the FTPRoot folder, such as from one User Account to another. There the one virtual directory under the user account virtual directory is sufficient.
ASKER
CJ, sorry for the delayed response. I did not encounter any lock-outs from the FTP that lasted more than a few seconds since I removed the physical directory, but I also would not want to bed my money on this and claim that this is the solution to the problem. The issue that certainly was created by the removal of the directory, is the fact that cannot see the www folder anymore from the FTP root, which adds some limitation to how the account is used. You can specify the www directory as the target folder in the FTP connection settings to jump right into it after the log-on, which works for most cases that I have to deal with.
I will close the question and award you with the points, but I wanted to make sure that anybody who comes across this question and comments will be clear about what there could be an option that works for him/her, but it might is not.
I hope comments will still be possible after i closed the question, in the case that somebody might has some additional ideas, explanations or suggestions etc.
I will close the question and award you with the points, but I wanted to make sure that anybody who comes across this question and comments will be clear about what there could be an option that works for him/her, but it might is not.
I hope comments will still be possible after i closed the question, in the case that somebody might has some additional ideas, explanations or suggestions etc.
ASKER
I don't want to repeat the last comment that I made myself to this question. Please have a look further down to check it out. Thanks.
Apparently using the virtual directory is the best way to get access to the content, but it is a "feature" that the reference does not show up in a dir/ls command when ftp'd into the server.
Creating a physical directory has problems from what I am reading.
MS knows of this problem and has released a new version of IIS FTP (7.5) which is supposed to make virtual directories viewable for FTP ... http://www.iis.net/extensions/ftp
I'm not seeing any references to updates released for IIS 6 to resolve this though.
Creating a physical directory has problems from what I am reading.
MS knows of this problem and has released a new version of IIS FTP (7.5) which is supposed to make virtual directories viewable for FTP ... http://www.iis.net/extensions/ftp
I'm not seeing any references to updates released for IIS 6 to resolve this though.
ASKER