Accessing Existing Storage
An organization may already keep project files in cloud storage, receive data on an SFTP server, or depend on a file server inside its network. Moving those files can disrupt the applications and people that use them. Sometimes the immediate need is to give more people a consistent way to reach the existing files while keeping that storage in place.
Files.com can connect to the storage and present a remote folder inside your site's file tree. Users reach it through their Files.com accounts, apps, and permissions. The remote service continues to hold the files, and operations through the mounted folder act on that service.
This arrangement separates two decisions: where the files belong and how people should access them. It lets IT introduce Files.com for one working area without first migrating the surrounding systems.
The Connection and the Folder
A Remote Server defines how Files.com connects to the other system: its service or protocol, address, credentials, and connection settings. A Remote Server Mount attaches a location on that connection to a folder on your Files.com site.
For example, an engineering team might keep project documents in an existing cloud-storage folder. IT creates the connection, then mounts that remote location at a Files.com path such as engineering/projects. The team sees the project files at that path in the web interface or Desktop App. It does not need a separate set of remote-service credentials on every workstation.
The Files.com path and the remote path refer to the same working files. Uploading through the mount adds a file to the remote location; deleting through it deletes from that location, subject to the connection's settings and permissions. Changes made directly on the remote service also affect the files the team is using.
Storage inside a private network can be connected through the On-Premise Agent. The Agent provides the connection to that storage; the people using it can still work through their normal Files.com apps.
Access to the Original or a Separate Copy
A mount is appropriate when the remote location should remain the working source. Its availability depends on the remote system and connection. It does not maintain an independent copy that the team can rely on when that system is unavailable.
A Sync or an Automation serves a different requirement: transferring files into another location. That may be appropriate when a department needs its own collected copy, a receiving application needs a delivery, or the organization is migrating storage. The destination can differ from the source between transfers, so decide which copy people should edit and which system owns subsequent changes.
For the engineering example, mounting the existing project folder preserves one working location for staff and the applications already using it. Copying it to another folder would introduce a second version to manage. If the goal later becomes retiring that storage service, plan the transfer and the point at which the new location becomes authoritative.
Permissions on Both Sides
The Remote Server connection uses credentials that must be permitted to perform the required operations on the remote service. Files.com folder permissions separately determine which users can perform those operations through your site. Administrator access to Files.com does not grant the remote account additional rights.
This gives IT a shared access point without distributing the remote credentials to the team. It also makes the connection an operational dependency: its owner must maintain those credentials and understand which remote folders they allow Files.com to reach.
Begin with the remote access the job actually needs. A team reviewing project documents may need read access. A team maintaining them needs appropriate write and replacement access on the remote service and Full permission on its Files.com working folder. Use Groups to keep the team's Files.com permissions consistent as membership changes.
Connecting One Working Area
A Site Administrator or Workspace Administrator configures the connection and mount. Choose the Workspace that will own the work, and begin with a small remote folder containing files suitable for the first access check.
- Open Remote Servers and add the connection for the storage service or protocol. Use its integration reference for the required credentials and connection settings. Reuse an existing connection when it already has the appropriate scope.
- Use the connection's Browse action to locate the intended remote folder and open a known file. This establishes that Files.com can reach that location before user access is introduced.
- Create an empty folder on Files.com for the mount, such as
engineering/projects. Under Mounts, add a Remote Server Mount, select the connection and remote folder, and select that empty local folder. - Grant the team's Group the intended folder permissions. Have a team member use their own account to open the mounted folder and retrieve the known file. If the job includes editing, verify a permitted change to a sample and confirm the result on the remote service.
The Files.com mount folder must be empty because mounting changes which storage serves that path. It displays the remote contents rather than merging them with files already on Files.com. Starting with a subfolder also keeps the change limited to the working area being introduced.
The administrator's Remote Server browser and the team member's file view establish different parts of the arrangement. A successful connection test alone does not establish that the user has the correct Files.com permissions.
Operating the Shared Location
Once the mount is available, desktop access gives people a way to open these files in local applications. A separate Desktop App connection to the underlying storage service is unnecessary; the app reaches the mounted folder through Files.com.
Coordinate with applications that also change files directly on the remote system. A person moving a document can remove a path another process expects, and two writers can replace each other's changes. Establish which working folders people may change and where completed files are handed to automated processes.
The remote system continues to determine capabilities such as available file information and recovery of deleted or replaced data. Native Files.com retention does not back up the mounted folder. Files, Storage & Mounts explains those boundaries, including connections where uploads are buffered before onward delivery. Preserve the remote storage's operating and recovery arrangements while extending access through Files.com.