Why does SMB Mapping Fail Despite Successful Connection Test in MetaDefender Manage File Transfer?

Scenario

When your MetaDefender Managed File Transfer (MFT) jobs involving SMB mapping were failing, even though the SMB connection test completed successfully, the MFT server could not access the specified SMB share path, leading to errors that indicated the share was unavailable.

For example:

Important Clarification: What the SMB Connection Test Verifies

The SMB connection test only confirms that the configured port (typically TCP 445) on the target server is reachable. It does not validate whether:

• The provided credentials are correct
• The SMB share exists and is accessible
• The integration is properly configured to execute a job

At this point, no authentication or file system access is performed. Therefore, issues such as incorrect credentials or invalid share paths may still exist — even if the connection test reports success, as illustrated below:

The SMB integration was configured using "NetBIOS over TCP", and the environment used SMB V2+.

__

Recommendation

The most reliable way to verify the integration is to run an actual job using the correct share path and credentials. This ensures both connectivity and permissions are validated end-to-end.

For example, as shown in the screenshot below, when setting up the job, you need to provide the correct credentials and share path. Additionally, make sure that the specified user account has the appropriate permissions to access the path.

MFT cannot process jobs using the SMB share

Root Cause

1. The SMB method was incorrectly set to "NetBIOS over TCP", which is incompatible with SMB version 2 or later. SMB V2+ requires Direct TCP communication.
2. The SMB share path was misconfigured, using a full folder path and trailing slashes, which resulted in the MFT server failing to locate the intended share.

Solution Steps

Follow these steps to correctly configure the SMB integration for use with SMB V2+:

Before integrating with SMB storage, you should first verify the SMB version used in your environment. If the SMB share is hosted on a Windows system, you can check the active SMB version by running the following PowerShell command:

Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

1. Change the SMB Method when you are using SMB v2

• Navigate to the SMB integration settings in MetaDefender MFT.

2. Specify the Correct SMB Share Name

• Use only the share name as defined on the target file server. For example:

• The SMB Share Name should be:

scan

• Do not include trailing slashes (e.g., scan/ or scan\)

3. Validate SMB Share Permissions

• Ensure the SMB share name matches exactly with the shared folder configuration on the destination server.
• Confirm that the service account used in the integration has appropriate read/write access to the share.

Outcome

After applying the above changes, the SMB mapping issue was resolved and confirmed by the customer. Jobs using the SMB integration executed successfully without further errors.

Job starts successfully

Additional Notes

• Always match the SMB version and method appropriately:

  • SMB 1.x → NetBIOS over TCP
  • SMB 2.x/3.x → Direct TCP

• For environments using Active Directory, ensure DNS resolution is properly configured for the file server hostname.