Files.com integrates with SharePoint in several ways.

The Remote Server Mount feature connects a specific folder on Files.com to a SharePoint location in real time. That folder becomes a client, or window, into the files stored on the remote server.

Once you configure a Mount, any operation performed on or inside that folder acts directly on the remote in real time. Dropping a file into the folder, deleting a file, creating a subfolder, or performing any other file or folder operation your Files.com user has permissions for passes through to the remote.

This enables a wide range of use cases: accessing files on a counterparty's cloud (client or vendor) without provisioning individual user access, reducing storage costs by using on-premise or bulk storage, and letting applications reach third-party clouds through the Files.com API, FTP, SFTP, or Files.com Apps.

Files.com's Sync feature is the alternative. A Sync pushes or pulls files between Files.com and SharePoint so that the files exist in both places at the end of the process.

A sync can be a "push," where files from your Files.com site are transferred to the remote server, or a "pull," where files are transferred from the remote server to your Files.com site.

Add SharePoint as a Remote Server

To connect to SharePoint, add your SharePoint server as a Remote Server in Files.com.

SharePoint can present folders as "sites", "libraries", "shared documents", and "pages". These terms are sometimes used interchangeably even though they represent different resources within SharePoint.

SharePoint resource paths typically take the form companyname.sharepoint.com/resource/resource_name, where resource can be "sites", "Shared Documents", or the name of a Library. A SharePoint site path looks like companyname.sharepoint.com/sites/MySite, while a Library path looks like companyname.sharepoint.com/MyLibrary.

SharePoint resource paths are case sensitive. Use the correct, exactly matching case when specifying the resource path. For example, if the resource path is companyname.sharepoint.com/sites/MYSITE/myfolder/MySubFolder, enter the path using that exact case.

When adding the SharePoint Remote Server, choose an Authentication Method: Sign In With Microsoft or Microsoft Entra ID App.

Once your Remote Server is connected, you can use it as either a Remote Server Mount or a Sync.

You can create as many SharePoint Remote Servers as you need, each with its own authentication method and credentials.

Remote Server Mounts are created by mounting them onto an empty folder in Files.com. The mount target is ideally not the Root of your site, although mounting at Root is supported if you need it.

When setting up a Remote Mount to SharePoint, leave the Remote folder setting blank and select the Choose a different folder option. Files.com then presents the available resources on the SharePoint server so that you can navigate to and select the exact resource folder you want to connect to.

You can also manually enter the full path to a SharePoint folder instead of selecting it, which is useful for hidden sites within SharePoint that aren't presented to Files.com through their API. For example, companyname.sharepoint.com/sites/HiddenSite/path/to/folder.

When entering the Remote folder path manually, confirm that it is valid and accessible by the credentials used in the Remote Server configuration. When in doubt, leave the Remote folder setting blank and use the Choose a different folder option to navigate to the resource instead.

After saving the configuration, the folder reloads and immediately lists the remote folders and files from the selected remote path.

You can also set up Syncs with your SharePoint site.

Case Sensitivity

Be aware of case sensitivity differences when copying, moving, or syncing files and folders between SharePoint and other storage locations. SharePoint is case insensitive, while other systems may be case sensitive. Files can be overwritten and folder contents merged when their case-insensitive names match.

Authentication Methods

A SharePoint Remote Server can authenticate two ways: as a signed-in Microsoft user or as a Microsoft Entra ID app registration with no user involved.

Sign In With Microsoft is the default authentication method. It redirects you to your SharePoint server's login page to authenticate, using OAuth for access delegation to SharePoint. It's the simpler of the two methods to set up, since it only needs a user to log in once, and it fits connections a person maintains directly.

Signing in this way creates an OAuth session that needs periodic re-authentication. How often varies by platform, and once that session expires or is revoked, authentication errors can occur even after the remote server has run smoothly for a while. When an authentication error occurs, Files.com disables the connection and records the error in your site alerts, also visible in the site warnings on the Administrator view's top bar. Re-enable the connection by re-saving its configuration, even when no fields have changed, so associated mounts and syncs start working again.

SharePoint Access and Permissions

Access controls and permissions are restricted to those of the SharePoint userID used to authenticate. For Files.com to access and retrieve files from SharePoint, that userID needs at least Read and List permissions on the relevant SharePoint sites, folders, and files. To transfer or upload files, it needs at least Create, Read, Update, Delete, and List permissions.

To confirm your SharePoint account has the access you need, log in directly to SharePoint with that account and verify that you can access those resources. Contact your SharePoint administrator if access fails.

Service Account Versus Named Users

Files.com acts in the context of the SharePoint userID used to authenticate the connection. As a best practice, create a SharePoint userID specifically for Files.com and use this "service account" to authenticate, then assign it a Microsoft 365 license. If you cannot use a dedicated service account, you can authenticate with regular SharePoint user credentials instead.

You can configure as many connections to SharePoint as you need, each with different SharePoint credentials, which lets you restrict access to specific parts of SharePoint to specific users.

Microsoft Entra ID App (SharePoint)

Use this method for a SharePoint Remote Server that drives unattended Syncs or Automations, since an expired session would break the connection with no one there to renew it.

A SharePoint Remote Server can authenticate as a Microsoft Entra ID app registration instead of a signed-in user. The connection runs as the app itself, so there's no interactive login and no periodic re-authentication. This also means it doesn't need a dedicated service account or the Microsoft 365 license that account would otherwise require, since it never authenticates as a SharePoint user.

OneDrive Remote Servers can't use this method. An app-only token has no signed-in user to resolve, and OneDrive needs a specific user's identity to know which drive to connect to.

Authenticating as a Microsoft Entra ID app requires the app registration's Directory (tenant) ID and Application (client) ID, plus either a client secret or a PEM-encoded certificate and private key. These credentials can be entered directly on the Remote Server form or stored in the Remote Server Credential Manager and reused across multiple SharePoint Remote Servers.

Register the Entra ID app in your organization's Entra admin portal and grant it permissions. That doesn't mean the credentials last forever, though. A client secret's lifetime is capped at 24 months by Entra itself and must be rotated before it expires. A certificate has no such enforced limit, but Microsoft recommends rotating it within 180 days as a security best practice.

When setting up the SharePoint Remote Server connection in Files.com, a site scope choice controls how much of SharePoint the connection can reach. Choose All Sites for one connection that reaches every site in the tenant, without maintaining a separate Remote Server per site. Choose Specific Site when you only need access to a single site, or when your organization won't grant tenant-wide Entra permissions.

All Sites

All Sites lets the connection browse every site in the tenant, listing each site as its own top-level folder. This requires the app registration to have the Sites.ReadWrite.All Microsoft Graph permission.

Grant it under the app registration's API permissions in Entra, as an Application permission rather than a Delegated permission, since this app has no signed-in user to delegate from. Entra's permission picker also lists a separate legacy SharePoint API, but Sites.ReadWrite.All only exists under Microsoft Graph, not that entry.

Add the permission and have an Entra admin grant consent for it. That's the whole process. Access takes effect as soon as consent is granted.

Specific Site

Specific Site works with the narrower Sites.Selected permission. This limits the selected site's root to read-only. Files can only be created, modified, or deleted inside a document library within the site.

The Remote Server form shows a SharePoint Site URL field when Specific Site is selected. It takes the site's full URL, including https://, for example https://companyname.sharepoint.com/sites/MySite. Each Remote Server scopes to exactly one site. If you need Sites.Selected access to several specific sites, set up a separate Remote Server for each. All of them can share the same Entra app registration's credentials through the Remote Server Credential Manager.

Grant it under the app registration's API permissions in Entra, as an Application permission rather than a Delegated permission, since this app has no signed-in user to delegate from. Entra's permission picker also lists a separate legacy SharePoint API, but Sites.Selected only exists under Microsoft Graph, not that entry.

Adding the permission and getting an Entra admin's consent only allows the app to be granted access to specific sites later. It doesn't grant access to any of them yet. Assigning that access happens through a separate Microsoft Graph API call, since Entra has no portal screen for it. Resolving a site's ID and granting the app access to it are both covered in Microsoft's own documentation. The app registration's Application (client) ID is the same value entered as the Remote Server's client ID.

Files.com Access Is Controlled Separately

The app registration's Graph permission only controls which SharePoint sites the connection can reach, whether scoped to All Sites or Specific Site. It doesn't grant access to any Files.com user. Which Files.com users and groups can use this Remote Server and what they can do with it is controlled the same way as any other Remote Server, through folder permissions on your Files.com site.

Sync and SharePoint

SharePoint modifies certain files after they are uploaded. Office documents and similar file types get SharePoint metadata injected directly into the file, which changes the file's size and checksum. The file stored in SharePoint is no longer identical to the original.

Left alone, that difference would put a Sync into an endless loop. Each sync run would see a source file that never matches its copy in SharePoint, transfer it again, and SharePoint would modify it again.

Files.com prevents this loop with a remote resync. When a sync run detects that SharePoint modified a delivered file, Files.com copies SharePoint's version of the file back to the sync source. The file is then identical in both places, and later runs treat it as already synced. This appears in the sync run logs as a sync_remote_resync event.

A remote resync is the one case where a sync changes its own source. The version of the file that ends up in both locations is the SharePoint-modified version, not the original upload.

Because the resync writes to the sync source, the source location must be writable. When the source location lacks write permission, the resync fails. Every following run then re-transfers the same files in an endless sync loop, which can produce excess transfer charges.

File Locking

Files stored in SharePoint become locked for various reasons. When your SharePoint instance has file checkin and checkout enabled, checking out a file for editing locks it. When checkin/checkout is not enabled, a file being edited in SharePoint stays locked until the user closes it. When multiple people edit the file at the same time, SharePoint locks it to prevent conflicting changes. When an antivirus scan or another external program opens the file, the file can be locked the same as if it were being edited in SharePoint.

Locked files cannot be synced by Sync processes. The External Logs do not list files that the sync skipped due to SharePoint locks.

When a file does not sync because it is locked in SharePoint, check whether any users have it checked out. A file open in Microsoft Office Online in a separate browser tab also locks the file. Check whether the cache within the Microsoft Office Upload Center needs to be cleared.

Rate Limiting

Microsoft enforces rate limits on the number of connections to SharePoint. A Sync or Automation targeting a SharePoint remote server with large quantities of files can trigger these limits.

Files.com reacts to being rate-limited by slowing reconnection attempts and reattempting the actions later.

Microsoft sets the rate limit, and the limit is not known until it is reached.

Your SharePoint license plan determines the Application Throttling Limit applied to the connection.

If your SharePoint license plan has a low rate limit, configure your Syncs and Automations to run less frequently, target fewer files and folders, or both.

Tuning around the rate limit requires experimentation. Try different configurations to find the combinations that work without triggering the throttle.

On-Premise SharePoint

This integration does not support on-premises instances of SharePoint. It's built on Microsoft's Graph API, which only reaches the cloud-hosted Microsoft 365 service, not on-premises SharePoint Server. Files.com uses that same Graph API code to support OneDrive as well, which only exists as a cloud service.

The WebDAV integration can be used to connect with on-premise SharePoint servers, provided that your firewall is configured to allow WebDAV connectivity to pass through.