Issue accessing Nextcloud web interface via IP after restoring a full 1:1 virtual machine backup

ℹ️ Support
,
1
Support intro

Sorry to hear you’re facing problems. :slightly_frowning_face:

The community help forum (help.nextcloud.com) is for home and non-enterprise users. Support is provided by other community members on a best effort / “as available” basis. All of those responding are volunteering their time to help you.

If you’re using Nextcloud in a business/critical setting, paid and SLA-based support services can be accessed via portal.nextcloud.com where Nextcloud engineers can help ensure your business keeps running smoothly.

Getting help

In order to help you as efficiently (and quickly!) as possible, please fill in as much of the below requested information as you can.

Before clicking submit: Please check if your query is already addressed via the following resources:

(Utilizing these existing resources is typically faster. It also helps reduce the load on our generous volunteers while elevating the signal to noise ratio of the forums otherwise arising from the same queries being posted repeatedly).

Nextcloud Server version:
Nextcloud Hub 25 Autumn (32.0.6)

Summary of the issue:
After restoring a full 1:1 virtual machine backup, accessing the Nextcloud web interface via IP address does not work. The interface redirects to the domain configured in config.php, making it impossible to reach the instance by IP.

The main issue seems to be that trusted_domains in config.php contains only the domain name. Guidance is needed on how to safely access the instance via IP after restoring a VM backup, without breaking security or web interface behavior.

2

Then add the IP as well?

Do you really need access via IP address? I never do this.

SSL certificates are usually for domain names, and if you have to accept manually a certificate that is not valid for the IP, that could be a potential security risk.

3

Are you saying accessing by IP worked prior to restoring? Or are you saying you’d simply also like your instance to be reachable by IP (the restore being then irrelevant)?

You also failed to fill out the support template. This makes it challenging to help because there are multiple possibilities/factors.

You might also find the Admin Manual of assistance, since it documents all relevant configuration parameters including trusted_domains and overwrite* among others.

4

Thanks for your response.

To clarify: accessing the instance via IP never worked before. The production instance is deployed using the standard Nextcloud AIO setup and works perfectly when accessed via the configured domain name.

Our environment uses regular VM backups. In case of a restore, I can start a new VM from the backup and access the data directly from the filesystem. However, sometimes it would be useful to access the Nextcloud web interface on the restored VM, for example to view file versions or inspect metadata through the UI.

The issue is that when I try to access the restored instance via its IP address, the web interface redirects to the configured domain name. Since this restored instance is isolated and DNS is not configured for it, the redirect prevents accessing the UI.

I tried adding the IP address to trusted_domains and experimented with some configuration changes to bypass the redirect, but I was not able to make it work.

The goal is not to run the production instance via IP, but simply to temporarily access the UI of a restored backup instance using its IP address for troubleshooting or data inspection.

For context, the deployment is:

  • Nextcloud Hub 25 Autumn (32.0.6)

  • Nextcloud AIO installation

  • Nginx Proxy Manager used as reverse proxy in production

5

so you try to access another copy of your application while the original is still running and accessible.
The redirect to the “primary” URL is expected and by design which brakes your scenario “access backup copy”

I think best solution would be to change the backup to another URL see OVERWRITE* parameters (and 101: reverse proxy) as already recommended by jtr

6

Your suggestion to use the overwrite* parameters makes sense. In this case I assume the correct approach would be to temporarily change the configuration of the restored instance to a different hostname and point it via reverse proxy.

For example:

  • change overwritehost / overwrite.cli.url in config.php

  • add the new hostname to trusted_domains

  • create a temporary host entry in Nginx Proxy Manager pointing to the restored VM

Would this be the recommended way to temporarily access a restored instance without interfering with the production environment?

7

depending on the config more work might be required e.g. to separate DB, passkeys or SSO. In general AiO is not intended to spin up multiple instances - you might need a completely different VM (or use docker rootless to start multiple instances).

I think this approach the easiest and most reliable problem to access a separate copy of your instance - this allows the “new” copy to act completely independent from the original system.

8

Thanks for the explanation and the link.

I’m not trying to run multiple instances in parallel for users. The production instance continues to run normally.

My goal is simply to start a temporary VM restored from backup in an isolated environment to inspect data through the web interface (for example file versions).

Since the restored instance keeps the original configuration, accessing it via IP redirects to the primary domain, which prevents opening the UI.

So I was considering temporarily adjusting the restored instance configuration (e.g. trusted_domains and overwrite*) to run it under a different hostname.

Would that be an acceptable approach for this backup inspection scenario?

9

Hi, I think what you would be looking for your use case after a restore is this: GitHub - nextcloud/all-in-one: 📦 The official Nextcloud installation method. Provides easy deployment and maintenance with most features included in this one Nextcloud instance. · GitHub

10

Thanks a lot for the suggestion and the link. I’ll try changing the domain in the configuration.json as described and see if that allows me to access the restored instance. I’ll report back with the results.

11

I restored a Nextcloud AIO backup to a temporary VM and want to use a new domain (test-nextcloud.example.domain) to inspect file versions.

Steps I did:

  1. Edited configuration.json in the master container:
sudo docker run -it --rm --volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config:rw alpine sh -c "apk add --no-cache nano && nano /mnt/docker-aio-config/data/configuration.json"
  • Changed "domain" to "test-nextcloud.example.domain"
  1. Updated trusted_domains and overwrite.cli.url in config.php inside the Nextcloud container

After restarting the containers, the config.php values are reset/overwritten back to the original domain.

Question: is there a reliable way to make the restored backup instance use a temporary domain without being overwritten by the AIO system?

Maybe it will still be possible to somehow open access by IP, or I no longer understand what I’m doing wrong

12

Yes, follow GitHub - nextcloud/all-in-one: 📦 The official Nextcloud installation method. Provides easy deployment and maintenance with most features included in this one Nextcloud instance. · GitHub

13

I’ve followed the “How to change the domain?” instructions from the AIO documentation for my temporary VM, but after restarting the containers some settings still redirect to the primary production domain.

Could you please provide more detailed guidance on what exactly needs to be done to fully reset the instance for a backup inspection scenario? Do I need to follow additional steps beyond changing the domain, or is there a recommended procedure for safely unblocking the temporary VM?

14

Indeed, some settings still will use the former values as mentioned in the section if you read a bit further in the docs. They then need to be changed by hand.

15

You might considering add a hosts file entry on your workstation to access to temporary instance.

Note there are other caveats to running a parallel restored instance (think background jobs and interactions with things like notifications/etc).

16

I’ve tried following the previous advice, but it still doesn’t work. Here’s what I’ve done so far:

  • On my Windows server, I created a DNS record test-nextcloud.example.domain pointing to 172.20.0.47.

  • In NPM, I added a proxy from test-nextcloud.example.domain to http://ip_nextcloud:11000, SSL certificate: None.

  • Restored a clean backup of the VM, updated network settings: IP = ip_nextcloud, DNS = Windows server IP where the record was added.

  • Stopped the master container and changed the domain in configuration.json to test-nextcloud.example.domain. Tried to clear the instance lock with:

    docker run --rm -v nextcloud_aio_mastercontainer:/mnt/docker-aio-config alpine rm /mnt/docker-aio-config/data/instance.lock

    but there was no instance.lock file.

  • Updated config via occ:

    docker exec -it --user www-data nextcloud-aio-nextcloud php occ config:system:set trusted_domains 1 --value=test-nextcloud.example.domain
docker exec -it --user www-data nextcloud-aio-nextcloud php occ config:system:set overwrite.cli.url --value=https://test-nextcloud.example.domain

From the client device, DNS resolution seems fine:

C:\Users\ds.andreev>nslookup test-nextcloud.example.domain
Server:  UnKnown
Address:  172.20.0.30

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
Name:    test-nextcloud.example.domain
Address:  172.20.0.47

However, when I try to access https://test-nextcloud.example.domain/, I get:

ERR_SSL_UNRECOGNIZED_NAME_ALERT
The site can’t be reached.

I’m not entirely sure what I need to do next. Am I on the right track, or is there a step I’m missing to properly access the temporary VM through the new domain?

17

I generated a certificate for test-nextcloud.example.domain and added it to Nginx Proxy Manager as a custom SSL certificate.
The proxy host is configured as:

  • Domain: test-nextcloud.example.domain

  • Forward to: http://172.20.0.47:11000

The SSL error is now gone, but when I open https://test-nextcloud.example.domain, it still redirects me to the original production domain (nextcloud.example.domain).

So it looks like the Nextcloud instance itself is forcing the redirect to the old domain somewhere in its configuration.

At this point I’m not sure what else needs to be changed to make the restored VM fully use the temporary domain. Am I missing another configuration location where the domain is stored?

18

Did you edit the domain in configuration.json as outlined in GitHub - nextcloud/all-in-one: 📦 The official Nextcloud installation method. Provides easy deployment and maintenance with most features included in this one Nextcloud instance. · GitHub?

19

Yes:
root@nextcloud:/home/user# sudo docker run -it --rm --volume nextcloud_aio_mastercontainer:/mnt/docker-aio-config:rw alpine sh -c “apk add --no-cache nano && cat /mnt/docker-aio-config/data/configuration.json”

(1/3) Installing ncurses-terminfo-base (6.5_p20251123-r0)

(2/3) Installing libncursesw (6.5_p20251123-r0 )

(3/3) Installing nano (8.7-r 0)

Executing busybox-1.37.0-r30.trig ger

OK: 8964 KiB in 19 pack ages

{

“password”: “************************************** ****”,

“secr ets”: {

“INSTANCE_ID”: “”************************************** ****“,”,

“NEXTCLOUD_PASSWORD”: “”************************************* *****“,”,

“BORGBACKUP_PASSWORD”: “”************************************ ******“,”,

“TURN_SECRET”: “”*********************************** *******“,”,

“SIGNALING_SECRET”: “”********************************** ********“,”,

“TALK_INTERNAL_SECRET”: “”********************************* *********“,”,

“DATABASE_PASSWORD”: “”******************************** **********“,”,

“REDIS_PASSWORD”: “”******************************* ***********“,”,

“ONLYOFFICE_SECRET”: “”****************************** ************“,”,

“RECORDING_SECRET”: “”***************************** *************“,”,

“FULLTEXTSEARCH_PASSWORD”: “”**************************** **************“,”,

“IMAGINARY_SECRET”: “”*************************** ***************“,”,

“WHITEBOARD_SECRET”: “”************************** ****************“,”,

“BORGBACKUP_VIEWER_PASSWORD”: “”************************ ********* *********“,”

},

“domain”: “test-nextcloud.example.domain”,

“bor g_restore_password”: “”,

“ti mezone”: “Europe/Moscow”,

“isClamavEnabled” : 1,

“isOnlyofficeEnabled”: 0,

“isCollaboraEnabled”: 1,

“isTalkEnabled”: 1,

“isTalkRecordingEnabled”: 1,

“isImaginaryEnabled”: 1,

“isFulltextsearchEnabled”: 1,

“isDockerSocketProxyEnabled”: 0 ,

“isWhiteboardEnabled”: 1,

“AIO_URL”: “172.20.0.37:8080” ,

“wasStartButtonClicked”: 1,

“install_latest_major”: “”,

“AIO_TOKEN”: “”******** **********************************“,”,

“borg_backup_host_location”: “”,

“borg_remote_repo”: “”****** ******************************* *****“,”,

“backup-mode”: “backup”,

“nextcloud_memory_limit”: “2048M”,

“nextcloud_datadir”: " /mnt/ncdata",

“apache_port”: “1 1000”,

“apache_ip_binding”: “0.0.0.0”,

" aio_ community_containers": “borgb ackup-viewer”

}

root@nextcloud:/home/user#

20

After adjusting the domain, you need to stop and start the containers again to populate the data to the sibling containers.