#1
|
|||
|
|||
Need understand what controls local folder external 'lands in'
Hello,
I'm using VShell 4x on Windows Server 20xx. Reasonably experienced with the product, except I'm suddenly unclear on exactly what factors go into controlling what local folder on my server a 3rd party will 'land in' when they connect. ** At this point, I notice the VShell documentation clearly states that Virtual Roots only apply to file transfer, not to shell, etc. My 3rd party is saying the folder they 'land in' on connection is wrong. They are able to interactively query that session, like using LS, is that a Shell session? ** Say I've got the following local simplified folder structure (again, Windows, not Linux/Unix): C:\sftp\coresystem C:\sftp\coresystem\3rdparty C:\sftp\coresystem\3rdparty\incoming C:\sftp\coresystem\3rdparty\outgoing Assumptions: There is a local account on my SFTP server, '3rdparty'. I've already gone into the Properties of the file system and set the NTFS permissions, the Access control list or ACL. The ACL I've set defines that, amongst other things, the local account '3rdparty' has NO PERMISSIONS until the folder path 'C:\sftp\coresystem\3rdparty', at which point I set '3rdparty' as having 'Modify' permissions and I chose for that permissions to inherit onwards to subfolders. In VShell, under Virtual Roots, I've created a Virtual Root and named it 'coresystem', set its path to 'C:\sftp\coresystem' and I've associated the local account '3rdparty' with that particular root. I'm not using Impersonation. I'm not using user variables, not using a single virtual root. For '3rdparty' actual permissions in Virtual Roots, I've set each box EXCEPT nominating the Virtual Root as the HOME and without checking the DELETE permission. I understand that Virtual Roots can only be used to further restrict what Windows file permissions are already doing, it cannot 'open up' that which Windows permissions are blocking. Given all that, what folder should the 3rd party expect to 'land in' upon connection to my environment? |
#2
|
|||
|
|||
Hi dverbern,
Quote:
Quote:
![]() The difference is really only the phrasing of the Use single virtual root option or parent folder as it is known now. I assume the notation of "not using a single virtual root" means this option is disabled for you. The included link describes functionality of the option as it was known prior to VShell v4.4.x (Use single virtual root) but the functionality is the same. When disabled (default in current version) users will land in their *first assigned root* (when HOME and any other factors that could have an effect are not in play). So in your scenario, the user would land in C:\sftp\coresystem except you stated you have given that directory NO PERMISSIONS and so they would be disconnected with a message that they have no roots available. If there is a specific problem you are trying to solve, it would be better to contact support@vandyke.com directly. Then, through review of VShell debug logs, we can probably help you sort out the issue. ![]()
__________________
Thanks, --Brenda VanDyke Software Technical Support support@vandyke.com (505) 332-5730 |
#3
|
|||
|
|||
Hello Brenda, thank you for your response - apologies for my delay responding. If I require further assistance, I'll take you up on emailing through instead of using forum, which I do remember being reminded to do last time I had an issue.
|
![]() |
Tags |
root virtual |
Thread Tools | |
Display Modes | |
|
|