I ran into this with UniFi OS Server 5.1.37 on Windows 11.

Remote Access refused to work even though the computer clearly had Internet access and the date/time were correct.

I eventually found two separate problems inside the UniFi OS Server container.

This guide walks through exactly what I did.

What I was seeing

When trying to enable Remote Access, UniFi first said:

“You must have an active internet connection.”

After fixing that, it changed to:

“An incorrect date/time is preventing you from establishing remote connectivity.”

If you're seeing either of these on the Windows version of UniFi OS Server, this is worth checking.

Part 1 — Get into the UniFi OS Server Linux environment

Open PowerShell.

Run:

wsl -l -v 

You should see something similar to:

NAME STATE VERSION Ubuntu Running 2 podman-uosserver Running 2 

The important one is:

podman-uosserver 

Enter it:

wsl -d podman-uosserver 

It will tell you that you're being placed into a nested process namespace. That's normal.

Your prompt should look something like:

[user@COMPUTER ~]$ 

Part 2 — Find the UniFi container

Run:

podman ps -a 

You should see a container with a name similar to:

uosserver_c81806a0 

Your random letters/numbers will probably be different.

Use your container name in the commands below.

Enter the container:

podman exec -it uosserver_c81806a0 sh 

You should now have a prompt like:

# 

You are now inside the actual UniFi OS Server container.

Part 3 — Check whether DNS is broken

Run:

cat /etc/resolv.conf 

Mine contained:

search localdomain nameserver 169.254.1.1 nameserver 10.255.255.254 

Now test Internet access:

curl -I --connect-timeout 10 https://unifi.ui.com 

Mine failed with:

curl: (28) Resolving timed out after 10000 milliseconds 

That was the reason UniFi claimed it didn't have Internet access.

Temporary DNS fix

Run:

cp /etc/resolv.conf /etc/resolv.conf.bak 

Then:

printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\n' > /etc/resolv.conf 

Check it:

cat /etc/resolv.conf 

You should now see:

nameserver 1.1.1.1 nameserver 8.8.8.8 

Test again:

curl -I --connect-timeout 10 https://unifi.ui.com 

If it is working, you should get an HTTP response instead of a DNS timeout. Mine returned:

HTTP/2 302 

At this point the “You must have an active internet connection” error disappeared.

Important: This DNS change is currently a workaround. I would not assume it will survive UniFi recreating the container during an update.

Part 4 — Fix the “incorrect date/time” error

After fixing DNS, UniFi started telling me:

“An incorrect date/time is preventing you from establishing remote connectivity.”

The funny part was that the time wasn't wrong.

Check it:

date 

and:

date -u 

Mine was correct.

Then check what UniFi actually cares about:

timedatectl show --property=NTP --property=NTPSynchronized 

Mine returned:

NTP=no NTPSynchronized=yes 

Running:

timedatectl status 

showed:

System clock synchronized: yes NTP service: n/a 

So the clock was synchronized, but there was no NTP service inside the UniFi container.

Trying:

timedatectl set-ntp true 

resulted in:

Failed to set ntp: NTP not supported 

That is the problem.

Other users have reported the same UniFi OS Server Remote Access behavior: unifi-core rejects Remote Access when it cannot see an active NTP service inside the container, even though the actual system time is correct.

Install the missing NTP service

Still inside the UniFi container at the # prompt, run:

apt-get update 

Then:

apt-get install -y systemd-timesyncd 

Now create an override that allows systemd-timesyncd to run inside the container:

mkdir -p /etc/systemd/system/systemd-timesyncd.service.d 

Then copy/paste this whole block:

cat > /etc/systemd/system/systemd-timesyncd.service.d/override.conf <<'EOF' [Unit] ConditionVirtualization= EOF 

Reload systemd:

systemctl daemon-reload 

Enable the service:

systemctl enable systemd-timesyncd 

Start it:

systemctl restart systemd-timesyncd 

Then:

timedatectl set-ntp true 

Finally check:

timedatectl show --property=CanNTP --property=NTP --property=NTPSynchronized 

Mine then showed the NTP functionality working.

After doing this, I tried Remote Access again and it worked immediately.

Part 5 — Windows Time is worth checking too

My Windows Time service also happened to be stopped.

Open PowerShell as Administrator and run:

Set-Service W32Time -StartupType Automatic Start-Service W32Time w32tm /resync w32tm /query /status 

A healthy result should show a successful synchronization and an NTP source such as:

Source: time.windows.com,0x9 

This wasn't the entire problem in my case—the missing NTP service inside the UniFi container was still the critical issue—but there's no reason to leave the Windows host's time service disabled.

The short version

If you don't care why it happens, here's what fixed mine.

Enter UniFi's WSL environment:

wsl -d podman-uosserver 

Find the container:

podman ps -a 

Enter it, replacing the name with yours:

podman exec -it uosserver_c81806a0 sh 

Fix DNS:

cp /etc/resolv.conf /etc/resolv.conf.bak printf 'nameserver 1.1.1.1\nnameserver 8.8.8.8\n' > /etc/resolv.conf 

Install the missing NTP service:

apt-get update apt-get install -y systemd-timesyncd 

Allow it to run inside the container:

mkdir -p /etc/systemd/system/systemd-timesyncd.service.d cat > /etc/systemd/system/systemd-timesyncd.service.d/override.conf <<'EOF' [Unit] ConditionVirtualization= EOF 

Then:

systemctl daemon-reload systemctl enable systemd-timesyncd systemctl restart systemd-timesyncd timedatectl set-ntp true 

Check it:

timedatectl show --property=CanNTP --property=NTP --property=NTPSynchronized 

Then try enabling Remote Access again.

One important warning

I have confirmed that this gets Remote Access working on my UniFi OS Server 5.1.37 installation. I have NOT yet confirmed that everything survives a reboot or, more importantly, a UniFi OS Server update that recreates the Podman container. The /etc/resolv.conf change in particular should be considered temporary until a persistent Podman DNS fix is configured. So this is currently a WORKAROUND rather than a permanent upstream fix. Hopefully Ubiquiti fixes the container configuration itself, because neither error message accurately described what was actually wrong.I have confirmed that this gets Remote Access working on my UniFi OS Server 5.1.37 installation.