Fixing "Authentication failed! (401)"

One node opens normally, but selecting another node in the tree shows:

Authentication failed! (401)

The usual cause is that the node clocks are no longer synchronised. VM2Cloud authentication tickets are time-sensitive, so a node whose clock has drifted rejects a login that is otherwise valid.

Clearing the browser cache is not the fix

It is the common first guess and it does not help. The clocks are the problem.

How time synchronisation works here

Every node keeps its clock aligned to an accurate time source using NTP (Network Time Protocol). When that stops working on one node, its clock slowly drifts away from the rest of the cluster until tickets issued by other nodes are no longer accepted.

Time synchronisation is separate from the displayed time zone: changing the time zone does not correct an inaccurate clock. A node can show the right local time and still hold a system clock that is minutes out.

1. Confirm it is a clock problem

While cross-node authentication is failing, reach each node by its own management address rather than selecting it through another node.

1. Open a new browser tab.
2. Go to https://<node management address>:8006
3. Sign in with an administrative account.
4. Select that node in the left navigation tree and open System → Time.

Do this for each node in turn and compare the Server time each one reports. It is shown in the node’s own Time zone, the row above it, so compare only nodes set to the same zone. If they disagree by more than a few seconds — or one is minutes out — you have confirmed the cause.

2. Set the correct time zone on every node

1. Select the node.
2. Open System → Time.
3. Click Edit.
4. Select your approved site time zone.
5. Click OK.

Repeat on every node so they all agree.

This alone may not fix it

The Time screen sets the time zone. It does not change which time source the node synchronises against. If the clocks are still drifting after this, continue below.

3. Correcting the time source

Choosing and applying the NTP time source is not exposed in the web interface, so it is not a change you can complete yourself from the GUI.

Contact VM2Cloud support and we will correct the time source on each node with you. It helps if you have the following ready:

What to have ready	Why
The NTP server addresses approved by your network team	We will point every node at the same approved source
Confirmation that outbound UDP port 123 is open from the node management network, with return traffic allowed	NTP needs direct UDP access; an HTTP/HTTPS proxy does not carry it
Your approved site time zone	Set consistently across the cluster
A maintenance window, if a clock is more than five minutes out	Large corrections are applied one node at a time to preserve cluster quorum

Ask your network team for more than one source

Three or four independent servers, or a documented highly available pool, is the usual recommendation. A single server works but is a single point of failure. Do not assume a DNS server, a default gateway or plain internet access provides NTP — each has to be confirmed.

4. Test cluster access

Once the time source has been corrected on every node:

1. Sign out of the web interface.
2. Close any other VM2Cloud browser tabs.
3. Open your normal management URL and sign in again.
4. Select several other nodes in the navigation tree.
5. Repeat the test after 15 minutes.

Remote node pages should now open without the 401 error.

Checklist

• Every node reachable on its own management address
• The same time zone set on every node
• The same approved time source applied to every node
• Node clocks agree to within a few seconds
• A fresh sign-in works
• Other nodes open without a 401
• Access still works 15 minutes later

Preventing this on future installations

Set the time source during installation, so a node never joins a cluster with the wrong time. On the Management Network Configuration screen, open Advanced… and enter your approved NTP servers before completing the install, then confirm the node’s time is correct before joining it to a cluster. See Installing VM2Cloud VE.

If it still happens

Contact VM2Cloud support with a screenshot of the full error, the names of the node you signed in to and the node that rejected you, roughly when it started, and whether the failure is constant or intermittent.

Caution

Never include passwords, authentication cookies, private keys or session tickets in a support message.