Investigating Login Failures
A login can fail because of the client configuration, network path, credentials, authentication method, or account state. Start with ExaVault's Activity log instead of relying only on the message shown by the client.
SFTP clients are especially likely to report every rejection as an authentication failure or invalid username and password. The SFTP protocol does not give ExaVault a useful way to return the detailed account reason to the client.
Find the Attempt in Activity
In ExaVault, open Activity, then select Activity Search. Filter by the closest available time range and use these fields to narrow the results:
Actions:
User LoginUsers: The affected username
Connection Type:
Web (HTTPS),FTP,FTPS,SFTP, orWebDAVIP Address: The client address, when known
A rejected login for a known user is recorded as a User Login event with a critical result. Open the activity details to compare the timestamp, username, client IP address, and connection type with the user's report.
An attempt with a username that does not exist may not create a user activity record. If the expected event is missing, verify the spelling and the appliance domain before assuming that the request never reached ExaVault.
Check the Connection Profile
Confirm that the client is reaching the intended appliance hostname and using the correct protocol and port:
SFTP
22
Select SFTP or SSH File Transfer Protocol.
Explicit FTPS
21
Require explicit TLS, sometimes labeled FTPeS or AUTH TLS.
Implicit FTPS
990
Require implicit TLS.
Plain FTP
21
No encryption. Use only for a legacy client that cannot use a secure protocol.
WebDAV
443
Use https://YOUR-EXAVAULT-DOMAIN/webdav.
Do not interchange SFTP and FTPS settings. They are different protocols even though both provide encrypted file transfer.
If the connection times out before authentication, investigate DNS, routing, and firewall rules first. The Firewall Configuration page lists the appliance ports.
Check Credentials and Authentication
Confirm the exact username and re-enter the password rather than relying on a saved credential. If SFTP uses an SSH key, confirm that the corresponding public key is attached to that ExaVault user and that the client is offering the intended private key.
Check the user's configured authentication method. A user configured for Active Directory or LDAP must authenticate against that directory; a local ExaVault password is not substituted. If directory-backed users are affected, follow Troubleshooting LDAP.
For web-interface logins, confirm that the user can complete any configured two-factor authentication step. ExaVault's 2FA applies to the web interface, not FTP, FTPS, SFTP, or WebDAV.
Check Account State
In Users, verify that the account is enabled and has not reached its expiration date. An expired password also prevents login until it is changed.
Repeated failed password attempts can temporarily lock an account. When the user record shows that it is locked, edit the user and select Unlock user, or wait for the temporary lockout to expire. Before retrying, correct any saved password that would immediately trigger more failures.
Compare Another Interface Carefully
For a password-based account, try the web interface with the same username. A failure there too points to the username, password, authentication method, or account state rather than the original protocol client.
A successful web login does not prove that an SFTP SSH key, FTPS security mode, WebDAV URL, or firewall rule is correct. Continue with the protocol-specific troubleshooting page:
Collect Evidence for Support
If the cause is still unclear, collect the username, protocol, client IP address, appliance hostname, exact timestamp with time zone, and the complete client log around the failure. Appliance service logs are stored under /data/exavault/logs/; compare entries using the same timestamp and protocol.
Do not include passwords, private keys, one-time codes, session tokens, or other credentials in a support request.
Last updated