UDMG as Server

When UDMG acts as a Server, it receives file transfers from external partners through supported protocols.

In this model, UDMG exposes server Endpoints that allow partners to connect using their preferred client or a web browser, depending on the protocol. Transfers are executed based on a defined Pipeline configuration, which determines how files are handled once received.

Access to UDMG as Server Pipelines is controlled through Account-based authentication, where external partners connect using protocol-specific credentials associated with configured Accounts and Account Groups.

UDMG as Server Pipelines support file uploads and, depending on the protocol and permissions, may also allow file downloads and folder management operations. In all cases, the Local Filesystem is used as the destination for files received through the server Endpoint.

Unlike UDMG as Client Pipelines, where transfers must be explicitly initiated through an API request, UDMG as Server Pipelines are triggered by external partner actions, such as connecting to the server Endpoint and performing file operations.

Supported Pipelines

Pipeline Name	Source Endpoint	Destination Endpoint	Description
Local AS2 Server to Local Filesystem	Local AS2 Server	Local Filesystem	Receives messages from a partner's AS2 client and writes them to the local filesystem.
Local FTP(S) Server to Local Filesystem	Local FTP Server	Local Filesystem	Transfers files between a partner's FTP(S) client and the local filesystem.
Local HTTPS Server to Local Filesystem	Local HTTPS Server (WTC)	Local Filesystem	Allows partners to upload, download, and manage files and folders through the Web Transfer Client (WTC), with files stored in the local filesystem.
Local SFTP Server to Local Filesystem	Local SFTP Server	Local Filesystem	Transfers files between a partner's SFTP client and the local filesystem.

Account Authentication

UDMG as Server Pipelines are integrated with the Account and Account Group model to control access:

In this scenario, Accounts connect to UDMG using protocol-specific credentials, and access is controlled by the Account Groups they belong to. Each Account Group is associated with one or more Pipelines, which define the available file transfer paths.

This integration ensures that:

• Only authenticated Accounts can initiate connections.
• Each Account can only access the Pipelines explicitly assigned through its Account Groups.
• Access control is enforced at the file transfer level without requiring external firewall or directory-based restrictions.

info

UDMG as Client Pipelines are not Account-based and do not integrate with the Account and Account Group model. These Pipelines are triggered using UDMG's Transfers Scheduled API.

Permissions

UDMG as Server Pipelines support permission-based access control to define what operations an Account can perform when interacting with the Local Filesystem through a server Endpoint.

Permissions are configured at the Pipeline level. These permissions determine which file and folder operations are allowed when a partner connects to UDMG.

The available permissions are:

• Download/Read File
• Upload/Write File
• Overwrite File
• Delete File
• List File
• Make Directory
• Remove Directory
• Rename File
• Share File

info

Not all permissions are available for every Pipeline type. The supported operations depend on the protocol. For details on permission availability, refer to the corresponding Pipeline page.

Virtual Path Hierarchy

UDMG as Server Pipelines — with the exception of Local AS2 Server to Local Filesystem — support multi-level Virtual Paths, allowing you to present a hierarchical folder structure to connecting partners. Each Virtual Path maps to a separate Pipeline with its own permission configuration.

The following example defines three Pipelines assigned to the same Account Group:

Pipeline	Virtual Path	Permissions
Pipeline 1	/acme/transfers/pull	Download/Read File, List File
Pipeline 2	/acme/transfers/push	Upload/Write File, List File
Pipeline 3	/acme/transfers/testfiles	All permissions

When a partner connects using an Account that belongs to that Account Group, UDMG automatically derives the intermediate directories /acme/ and /acme/transfers/ from the path hierarchy and presents them as browsable folders. No additional Pipeline configuration is required for those intermediate levels. The partner sees the following structure:

/acme/
└── transfers/
    ├── pull/
    ├── push/
    └── testfiles/

• /acme/ and /acme/transfers/: intermediate folders derived automatically. Partners can navigate into them but cannot transfer files at these levels.
• /acme/transfers/pull/: download only. Partners can list and download files, but cannot upload, delete, or modify anything.
• /acme/transfers/push/: upload only. Partners can list and upload files, but cannot download or manage existing content.
• /acme/transfers/testfiles/: full access. Partners can upload, download, overwrite, delete, rename, and manage folders.

info

Uniqueness is enforced on the full Virtual Path string. The paths /acme/transfers/pull and /acme/transfers/push are treated as distinct entries even though they share path segments.

Transfer Resume

Transfer resume allows an interrupted transfer to continue from where it left off, rather than restarting from the beginning. When the external transfer client reconnects and uses its built-in resume command, UDMG continues from the last byte transferred.

Transfer resume is supported only for uploads and downloads in UDMG as Server Pipelines, but it is not available for all Pipeline types. The following table summarizes the support for transfer resume across different Pipeline types:

Pipeline Type	Transfer Resume
	Uploads	Downloads
Local SFTP Server to Local Filesystem	Requires the Local Filesystem Endpoint to have its Stage Files in a Temporary Folder toggle disabled.	Always supported
Local FTP(S) Server to Local Filesystem	Requires the Local Filesystem Endpoint to have its Stage Files in a Temporary Folder toggle disabled.	Always supported
Local HTTPS Server to Local Filesystem	Not supported	Not supported
Local AS2 Server to Local Filesystem	Not supported	Not supported

Each resumed transfer creates a new Transfer Record with a new transfer ID. The file continues from where it left off at the byte level, but a separate entry appears in the Transfers Dashboard for each resume attempt.

Resuming a Transfer

No UDMG-side action is required. To resume an interrupted transfer, use the resume command built into your FTP or SFTP client. Refer to your client's documentation for details on how to resume transfers using the following commands:

SFTP

• Upload (interrupted upload to UDMG): reput <localfile> <remotepath>
• Download (interrupted download from UDMG): reget <remotepath> <localfile>

For uploads (reput), the client stats the destination before writing. If a partial file exists on UDMG, UDMG responds with its current size and the client resumes writing from that offset. If no partial exists, the client starts the transfer from the beginning.

For downloads (reget), the client checks its own local file size to determine how many bytes it already has, then reads the remote file starting from that offset. UDMG serves the file from the requested position.

FTP

• Upload (interrupted upload to UDMG): send SIZE <filename>, then REST <offset>, then STOR <filename>
• Download (interrupted download from UDMG): send SIZE <filename>, then REST <offset>, then RETR <filename>

Tracking a Resumed Transfer

In UDMG as Server Pipelines, when the partner client does not disconnect between an interrupted transfer and the retry, both Transfer Records share the same Session ID. You can use this to track a resumed transfer in the UDMG Admin UI:

1. From the Sidebar, click Monitoring > Transfers.
2. Click Columns and enable Session ID.
3. Look for Transfer Records with the same Session ID.

When the partner client disconnects between the interrupted and resumed transfer, the Session ID will differ. In this case, you can still track a resumed transfer by filtering Transfers by the fields that must match, i.e., Pipeline, Source Path and Destination Path.

info

WinSCP SFTP uploads: WinSCP writes to a temporary .filepart file during upload and renames it to the final filename on completion. Both the interrupted and resumed Transfer Records show the .filepart path as the Source Path, not the final filename. When filtering by Source Path to track a resumed WinSCP SFTP upload, use the .filepart filename — for example, filename.exe.filepart.

Once you have filtered the Transfers by these fields, you can identify the interrupted and resumed Transfer Records by their Status and Bytes Transferred / File Size values:

Uploads

Original (interrupted) transfer

Status	Bytes Transferred	File Size	Cause
Failed	Partial bytes received.	0	Interrupted by a network failure, system error, UDMG instance issue, or partner client disconnect or abort.
Cancelled	Same as Failed.	Same as Failed.	Canceled by an Admin or by UDMG due to a cluster state change.
Completed	Same as Failed.	Partial bytes written (not 0).	The partner client closed the connection cleanly after uploading partial data. Compare the Started timestamps of matching records to identify the partial and resumed ones.

Resumed transfer

Status	Bytes Transferred	File Size
Completed	Only bytes transferred in this session (less than File Size).	Full file size (recorded when the resumed transfer completes).

Downloads

Original (interrupted) transfer

Status	Bytes Transferred	File Size	Cause
Failed	Partial bytes sent (less than File Size).	Full file size.	Interrupted by a network failure, system error, UDMG instance issue, or partner client disconnect or abort.
Cancelled	Same as Failed.	Same as Failed.	Canceled by an Admin or by UDMG due to a cluster state change.
Completed	Same as Failed.	Same as Failed.	The partner FTP client closed the connection cleanly after receiving partial data. Compare the Started timestamps of matching records to identify the partial and resumed ones.

Resumed transfer

Status	Bytes Transferred	File Size
Completed	SFTP: equal to or slightly greater than File Size. Some SFTP clients re-read a small amount of data at the resume offset for integrity checking, which can cause this value to slightly exceed File Size. FTP: less than File Size.	Full file size.