Missing Folders on Remote Mounts

Remote Server Mounts reflect the structure of a remote system inside Files.com. In some cases, a folder that was previously visible through a mount may be moved, deleted, or temporarily inaccessible on the remote system without going through Files.com. This page explains how Files.com handles those situations, why it matters, and how your existing configuration is protected.

You will care about this behavior if you use Automations, permissions, or Folder Settings on folders within a mount and want to understand what happens when changes occur outside of Files.com.

This handling applies only to changes detected on the remote system. Folders deleted through Files.com are removed immediately, along with their associated metadata.

Why Missing Folders Are Hard to Interpret

When Files.com interacts with a remote mount, it relies on the remote system's APIs to list and access files and folders. These APIs are not always perfectly reliable. Transient or temporary network conditions can cause a file or folder to appear missing even though it still exists on the remote system.

If Files.com were to immediately delete local metadata whenever a folder appears missing, these temporary conditions would cause serious disruption. Automations could break, permissions would disappear, and configured Folder Settings would be lost even though the remote folder later reappears unchanged.

How Files.com Handles Missing Folders

When Files.com detects that a file or folder on a remote mount is missing during a list or lookup operation, it does not immediately delete the corresponding local metadata. Instead, Files.com records the missing path and defers any cleanup decision.

This deferred approach allows Files.com to distinguish between a folder that has truly been removed from the remote system and a folder that is only temporarily inaccessible.

Deferred Deletion and Revalidation

When a missing file or folder is detected, Files.com places its path into a deferred deletion queue. Over a defined validation window of 72 hours, background processes periodically recheck the path against the remote system.

If the folder or file is confirmed to exist again during this window, Files.com stops checking for the missing path and no changes are made. Permissions, Folder Settings, notifications, and other associated configuration remain intact.

If the folder or file continues to be missing after repeated checks, Files.com treats it as permanently removed.

What Happens When a Folder Is Permanently Removed

When a mounted folder is confirmed to be permanently missing, Files.com removes its associated metadata in the same way it would if the folder had been deleted directly through Files.com. This includes Folder Settings, permissions, notifications, and other objects tied to that folder.

This cleanup ensures that Files.com remains accurate and does not retain stale configuration for folders that no longer exist on the remote system.

What This Means for Your Processes

This design protects your workflows from instability caused by transient remote system issues. Changes made outside of Files.com do not immediately break automations or erase configuration, and legitimate removals are eventually reflected in a consistent and predictable way.

If a folder is intentionally moved or deleted on the remote system, Files.com will reconcile that change after the validation window. If a folder disappears temporarily due to remote-side issues, Files.com preserves your configuration until the folder can be confirmed as truly gone.