This is version 1 2 3 4 5 . It is not the current version, and thus it cannot be edited.
[Back to current version]   [Restore this version]

CrushFTP supports many different protocols for the VFS that a user can access.

FILE://#

This is your standard type of folders on your local drives. This could also reference a UNC location on windows if the service is running as a domain user that can access the UNC locations.

FTP:// FTPS:// FTPES://#

This allows you to use a remote FTP server as the VFS for a user. Some people use an already established IIS FTP server as the back end, but put CrushFTP as the front end giving more controls and protocols.

SFTP://#

This allows you to use a SFTP server as the back end. OpenSSH on a Linux server is often used as the back end.

SMB://#

This allows you to connect to a Samba or Windows file server as the backend and provide the credentials. Usually in the format of "smb://user\domain:pass@servername/share/".

HTTP:// HTTPS://#

This allows you to point to another CrushFTP server and use that as the back end. The HTTP methods used are only valid to another CrushFTP server. It uses specific calls a CrushFTP server expects for file management.

WEBDAV:// WEBDAVS://#

This allows you to use a standard webdav server as the back end. It makes all the queries about files and dir listings using the webdav XML calls.

GDRIVE://#

(Disabled due to changes made by google. May come back at a later date after re-evaluating.)

RFILE://#

Special VFS method that launches new "shells" impersonating the user logging in. Its not super fast, and has a lot of overhead, but some unique scenarios need this method of impersonation if the SMB:// method doesn't work for them.

MEMORY://#

Implements a VFS in memory, but if the server is restarted, all the data disappears too. Temporary usage, and frequently just for special cases in Jobs.

S3://#

Allows you to use a S3 bucket as the backend filesystem. However since S3 isn't hierarchical, you only get simulated folders, and no ability to rename, and some other gotchas about how S3 works. These aren't limitations we impose, but just due to the design decisions S3 made in that its intended for static item consumption and not as a location for holding and manipulating file names.

S3CRUSH://#