Folders in SFTP Gateway
Use cases for Folders
Folders in SFTP Gateway are logical mappings. They map an SFTP subdirectory to a Cloud Connection.
In other words, Folders let you map SFTP folders to different cloud locations.
By default, SFTP Gateway has a root Folder that maps to the default Cloud Connection:
/ <-- maps to default Cloud Connection
SFTP Gateway comes with a default Folder structure that looks like this:
/ <-- maps to default Cloud Connection /users/ <-- a regular Folder that inherits from the parent directory /users/userA/ <-- an inherited Folder that acts as the Home Directory of userA /users/userB/ <-- an inherited Folder that acts as the Home Directory of userB
From the SFTP user's point of view, their file system will be chrooted to their Home Directory. For example,
userA will log in and see the following:
This chroot directory corresponds to this Folder:
And any uploaded files will end up in S3:
Folders in SFTP Gateway create SFTP subdirectories?
When creating a Folder, you can select one of two options:
- Cloud Connection
Folder is set Inherited
Inherited is the default option.
When you use the Inherited option, file uploads will go to the Cloud Connection defined by the parent Folder. For example, you can have a chain of Inherited Folders that all point to the default Cloud Connection:
/ <-- maps to default Cloud Connection /users/ <-- inherits from the root path "/" /users/userA/ <-- inherits from /users/
It's important to note that an Inherited Folder will create an SFTP subdirectory of the same name. For example, these Folder objects:
/users/ <-- inherited /users/userA/ <-- inherited
will create the following paths in S3:
Folder is set to Cloud Connection
You can point a Folder directly to a Cloud Connection. For example:
/ <-- maps to default Cloud Connection /users/ <-- inherited Folder /custom/ <-- points to "Cloud Connection B"
Files uploaded to the
/custom/ Folder will end up in
Cloud Connection B rather than the default Cloud Connection.
It's important to note that when a Folder points to a Cloud Connection, it does not create a subdirectory. This is necessary, because you might want to point the Folder to the root of a Bucket:
/custom/ <-- points to s3://custom-bucket/
You can use Folders and Cloud Connections for more complicated setups. For example, you want to share files between different accounts. Or, you want to transfer files between Cloud providers.
Here are some configuration examples:
Use case 1: multiple Storage Accounts
For example, an SFTP user can have two subfolders under their chroot directory:
/ |--folderA/ <-- maps to S3 bucket A |--folderB/ <-- maps to S3 bucket B
Each Folder maps to its own S3 bucket and path.
Use case 2: group folder
You can use Folders for file sharing.
/ |--userA/ <-- maps to a location dedicated to UserA |--group/ <-- maps to a shared location
A second user can be configured in the same way:
/ |--userB/ <-- maps to a location dedicated to UserB |--group/ <-- maps to a shared location
userB have their own folder.
They also have a
group folder mapped for sharing files.
Use case 3: multi-cloud transfer
You can use SFTP Gateway to transfer files between cloud providers:
/ |--aws-folder/ <-- maps to an S3 bucket |--azure-folder/ <-- maps to an Azure Blob Storage Account
This configuration lets you drag and drop files between AWS and Azure.
Folders are logical mappings that map an SFTP folder to a cloud location.
Deleting a Folder only deletes the mapping -- it does not delete the underlying objects in S3.
Also, the folder will not appear in S3 until you have logged in as the SFTP user. This is to avoid generating a lot of intermediary folders in S3 as you tweak your Folder structure.