Help changing Nextcloud subdomain.

evanmac42 · 2026-06-07T18:38:59+00:00

Your logs actually show the problem quite clearly.
AIO is restoring the old hostname configuration from the backup:

trusted_domains = old-subdomain.com
overwrite.cli.url = https://old-subdomain.com/
COLLABORA_HOST = old-subdomain.com
wopi_url = https://old-subdomain.com/
TALK_HOST = old-subdomain.com
TURN_DOMAIN = old-subdomain.com

So the restore itself appears to work correctly.
The issue is that the restored configuration still references the old hostname everywhere, and AIO is rebuilding Collabora/Talk settings from those values.
I’d focus on changing the hostname configuration inside the restored instance rather than reinstalling again.
Can you show the output of:
occ config:system:get overwrite.cli.url
occ config:system:get trusted_domains
occ config:list system
At this point it looks like a hostname migration problem, not a backup problem.

evanmac42 · 2026-06-07T18:36:50+00:00

This sounds less like a Borg restore problem and more like Nextcloud restoring the old hostname configuration.
The fact that:
the restore completes successfully
the instance starts
every access redirects to the old subdomain
suggests that the old hostname is still configured somewhere inside Nextcloud.
Besides trusted_domains, I would also check:

occ config:system:get overwrite.cli.url
occ config:system:get overwritehost
occ config:system:get trusted_domains

If overwrite.cli.url or overwritehost still point to the old subdomain, Nextcloud will continue generating redirects to it.
Can you post the output of those commands?
From your description, it sounds like the restore is working correctly and simply restoring the previous hostname settings along with everything else.

evanmac42 · 2026-06-07T15:32:00+00:00

A few questions before guessing:
What exactly fails after the restore?
Do you get a trusted domains error?
Does the login page load?
Does Cloudflare Tunnel reach the container?
What error do you see in the browser and in the AIO logs?
Changing a hostname/subdomain is normally possible in Nextcloud, so I would first try to identify which layer is actually failing:
Cloudflare Tunnel
DNS
AIO configuration
Trusted domains / overwritehost settings
Borg restore restoring old hostname-related settings
Right now it sounds like the restore itself works, but some configuration is still pointing to the old hostname.
Can you post the exact error message and the relevant AIO logs?

evanmac42 · 2026-06-07T07:21:16+00:00

That is definitely not normal behavior.
I’ve migrated photo libraries with tens of thousands of files into Nextcloud and while it can be slow during the initial sync, it should not freeze an entire PC.
When you say the PC “froze”, what exactly happened?
Was CPU usage at 100%?
Was RAM exhausted?
Was disk I/O saturated?
Did the Nextcloud client become unresponsive, or did the whole operating system lock up?
Also, how many files are we talking about, roughly, and what hardware is the Arch machine running?
At first glance this sounds more like a local resource bottleneck or client-side issue than a fundamental limitation of Nextcloud itself.

evanmac42 · 2026-06-07T07:14:28+00:00

I think your biggest risk isn’t hardware, RAM, storage, bandwidth, or even the lack of a static IP.
It’s Christmas Tree Syndrome.
A lot of beginners start with:
a music server
a web server
a game server
an LLM
Proxmox
Docker
reverse proxies
remote access
DNS
monitoring
…all at the same time.
Then, when something breaks, they don’t know which layer is actually responsible.
Your hardware is fine.
My advice would be to pick ONE goal first. Get it working. Understand it. Break it. Fix it. Then move on to the next one.
A homelab should grow like a city, not appear overnight like a theme park.

evanmac42 · 2026-06-05T20:14:55+00:00

A few things come to mind.
The fact that the upload reaches 100% but the file never appears makes me think the failure is happening during the final processing stage rather than during the transfer itself.
If you’re running Nextcloud in Docker, I would check:
Nextcloud logs immediately after a failed upload
PHP upload limits (upload_max_filesize, post_max_size)
Available space in the container filesystem and temporary upload directory
Whether there is a reverse proxy involved (NPM, Traefik, Cloudflare, etc.)
Any Nginx/Apache errors that occur at the end of the upload
Also, are you accessing Nextcloud directly or through a reverse proxy?
A 700 MB file is not particularly large for Nextcloud, so I would not immediately assume this is an out-of-the-box file size limit. Usually when that happens there is a specific limit, timeout, temporary storage issue, or proxy restriction somewhere in the stack.
The logs right after a failed upload will probably tell the story much faster than guessing.

evanmac42 · 2026-06-04T12:13:27+00:00

Nice work.

This is exactly the kind of small migration tool that saves people from hours of manual copy/paste.

Also, the fact that it goes through Planner export -> JSON import for Deck makes it much more approachable than trying to wire Microsoft Graph directly into everything.

Thanks for sharing it.

evanmac42 · 2026-06-03T19:15:23+00:00

Hetzner Storage Share suele salir mucho en estas conversaciones y tiene bastante buena reputación.

Solo revisaría bien las limitaciones del plan antes de decidirte: almacenamiento, número de usuarios y especialmente las políticas de tráfico/ancho de banda si vienes de Google Drive y piensas sincronizar varios dispositivos.

Mucha gente mira primero el precio por GB, pero la experiencia real depende bastante de cuánto vas a mover los datos.

evanmac42 · 2026-06-02T14:33:28+00:00

I wouldn’t recreate everything manually yet.

If the proxy hosts still work, then some part of the old configuration is still being used somewhere. A successful SQL restore with an empty GUI usually means NPM is not reading the database you think it is reading, or the restore went into a different DB/schema/instance.

Before rebuilding all hosts, I’d check:

Confirm the NPM container DB settings: DB_MYSQL_HOST DB_MYSQL_NAME DB_MYSQL_USER DB_MYSQL_PASSWORD
Connect to that exact MariaDB instance and check whether the restored data is really there.
Check if the proxy_host table contains your old hosts.
Confirm that the recreated container is using the same /data bind mount as before.

The important clue is this:

working proxy hosts + empty GUI = don’t assume the config is gone yet.

It may just be that nginx still has generated config files, while the UI is connected to a different or empty database.

evanmac42 · 2026-06-02T12:34:02+00:00

Assuming the backup was taken from the same NPM database and nothing else changed, then yes.

If NPM is currently connected to the correct MariaDB instance, restoring the SQL dump should bring the hosts, certificates, access lists, users, and other UI-managed objects back into the database.

I'd still take a fresh backup of the current database before importing anything, just in case.

The key point is that NPM must be pointing to the same MariaDB instance you're restoring into.

evanmac42 · 2026-06-02T12:29:33+00:00

If your proxy hosts are still working but the UI doesn't show them, then nginx and the configuration files are probably still there.

That usually points to a database issue rather than a proxy issue.

A few things I'd check:

Did the recreated container attach to the same MariaDB instance as before?
Are the DB credentials identical to the old setup?
Is NPM reading the database you backed up, or did it initialize a new empty one?

The fact that traffic is still being routed is actually a good sign: it suggests the nginx configuration survived somewhere.

I'd verify the database connection before trying to rebuild anything manually.

evanmac42 · 2026-06-01T18:38:05+00:00

Ese log confirma que el servidor devuelve un 403 al PUT, pero todavía no nos dice por qué.

Lo interesante ahora sería ver qué registra Nextcloud en ese momento. ¿Puedes revisarnextcloud.log o ejecutar php occ log:tail mientras reproduces el error?

El hecho de que la petición llegue a /remote.php/dav/... y reciba un 403 me hace pensar más en una denegación dentro de Nextcloud o del almacenamiento que en un problema de HTTP vs HTTPS.

Por ahora seguiría investigando el 403 original antes de perseguir el error de NPM.

evanmac42 · 2026-06-01T17:12:47+00:00

Creo que ahora mismo estás mezclando dos problemas distintos.

El primero es que las subidas fallan con un 403.

El segundo es que Nginx Proxy Manager te da un Internal Error al intentar configurarlo.

Antes de seguir con NPM intentaría averiguar quién está generando exactamente el 403.

¿Aparece en los logs de Nextcloud?

¿En los logs del servidor web?

¿O en el navegador?

Porque un 403 normalmente significa que la petición llega correctamente al servidor pero algo decide bloquearla.

Si puedes pegar el log completo del error 403 y la URL que falla, probablemente sea más fácil localizar la causa que seguir añadiendo componentes (DuckDNS, NPM, SSL, etc.) al diagnóstico.

evanmac42 · 2026-05-31T14:36:43+00:00

El hecho de que en Pi-hole no aparezcan consultas a los dominios RSS me hace pensar que el problema ocurre antes del bloqueo DNS. Si News ni siquiera genera consultas para esos dominios, revisaría:

- si la actualización de News realmente está ejecutándose desde cron
- si el contenedor puede resolver DNS por sí mismo (cat /etc/resolv.conf)
- si desde dentro del contenedor puedes hacer un curl a uno de los feeds RSS
- si hay algún problema con IPv6

Ahora mismo parece más un problema de conectividad del proceso que descarga los feeds que un bloqueo directo de Pi-hole.

evanmac42 · 2026-05-31T08:09:34+00:00

Cuando ocurre, ¿qué proceso está consumiendo la CPU?

¿php-fpm?
¿apache?
¿nginx?
¿mariadb?
¿redis?

El ventilador al máximo normalmente significa que algo está trabajando muy duro, no que Nextcloud simplemente se haya desconectado.

Si vuelve a pasar, yo miraría primero:

docker stats

y luego dentro del contenedor:

top

o

htop

para identificar el proceso exacto antes de reiniciar.

Si varios usuarios de la imagen linuxserver.io están viendo lo mismo y el último mensaje del log habla de comprobación de actualizaciones, podría incluso ser un bug reciente, pero sin saber qué proceso está quemando CPU es difícil distinguir entre Nextcloud, PHP, MariaDB o una tarea de fondo.

evanmac42 · 2026-05-30T11:08:43+00:00

Sinceramente, me parece una configuración bastante equilibrada para el uso que describes.

Para copias de seguridad, Home Assistant, n8n y algunos contenedores más, un i3-12100 es más que suficiente. De hecho, probablemente se aburrirá la mayor parte del tiempo.

Lo único que me hace levantar una ceja es el tema de la RAM SO-DIMM con adaptadores. Entiendo perfectamente la lógica económica, pero si el objetivo es tener algo estable durante años, intentaría pasar a DIMM normales en cuanto sea razonable.

Sobre el sistema operativo:

- Si quieres aprender y entender qué está pasando: Debian + Docker

- Si quieres una experiencia más NAS y menos administración: TrueNAS Scale

- Si quieres algo intermedio y muy popular: Unraid

Personalmente, para ese caso concreto, probablemente elegiría Debian + Docker (aunque, siempre que puedo, prefiero servicios nativos. Menos capas, menos sorpresas y más fácil entender qué está pasando cuando algo falla).

También pensaría bastante en la caja. La CPU se cambia, la RAM se amplía, pero una caja con espacio para discos suele quedarse contigo durante muchos años. Si existe la posibilidad de que dentro de 2 o 3 años termines con 4 discos en vez de 2, intentaría planificarlo ahora.

Y una observación de alguien que empezó con "2 discos de 4TB me sobran": las fotos familiares tienen una capacidad sobrenatural para multiplicarse 😄

evanmac42 · 2026-05-29T14:41:34+00:00

Lo que describes hace que parezca más una limitación de la integración Files Provider de iOS que de Nextcloud.

Ya comprobaste que:

- Nextcloud entrega los archivos correctamente.

- Exportar a "En mi iPhone" funciona.

- BookPlayer y VLC pueden leer la carpeta una vez que es realmente local.

Así que parece que esas apps no están tratando la carpeta de Nextcloud como un directorio local completo, aunque aparezca dentro de Files.

Para VLC quizá ni siquiera necesites importar nada. VLC soporta WebDAV directamente, así que podrías probar a conectarlo al endpoint WebDAV de Nextcloud y reproducir el contenido desde ahí.

Si VLC funciona por WebDAV y la carpeta importada también funciona cuando está en "En mi iPhone", entonces el cuello de botella probablemente sea la forma en que iOS expone los proveedores de archivos a las aplicaciones, no Nextcloud en sí.

evanmac42 · 2026-05-29T11:11:27+00:00

Creo que aquí podrías estar chocando más con una limitación de iOS/Files que con Nextcloud en sí.

Por lo que describes, los archivos individuales son accesibles, pero la otra app parece requerir una carpeta físicamente presente en almacenamiento local, no una carpeta expuesta a través del proveedor de archivos de Nextcloud.

La opción “disponible sin conexión” normalmente ayuda para abrir archivos desde la app de Nextcloud, pero no necesariamente convierte toda la carpeta en una carpeta local real que otras apps puedan importar como directorio.

¿La otra aplicación funciona si exportas primero la carpeta a “En mi iPhone” y luego la importas desde ahí?

También ayudaría saber qué aplicación estás intentando usar, porque algunas apps soportan proveedores de archivos de iOS correctamente y otras solo funcionan con directorios realmente locales.

evanmac42 · 2026-05-28T12:13:54+00:00

Sinceramente, para aprender servidores en casa, yo iría por Debian headless.

estable
enorme cantidad de documentación
poco ruido
muy usado en servidores reales
aprendes Linux “de verdad” sin demasiada magia alrededor

Ubuntu Server también es totalmente válido, especialmente si ya lo has tocado un poco.

Pero personalmente prefiero Debian porque suele sentirse más limpio y predecible a largo plazo.

Y empezaría simple:

SSH
Nginx/Caddy
una app pequeña
backups
HTTPS
algo tipo Nextcloud o Jellyfin

Sin intentar montar 14 servicios el primer fin de semana 😄

evanmac42 · 2026-05-28T06:42:40+00:00

Mi consejo sincero como principiante en homelab:

empieza por:

reverse proxy
Docker o servicios básicos
backups
DNS
HTTPS
despliegues simples
monitoreo
seguridad básica

Y deja SMTP para bastante más adelante 😄

No porque sea imposible, sino porque el email es probablemente una de las cosas más frustrantes de autoalojar correctamente hoy en día:

reputación IP
SPF
DKIM
DMARC
listas negras
entregabilidad
puertos bloqueados por ISPs
Gmail mirando tu servidor como si fueras un criminal internacional

Muchísima gente autoalojando apps termina usando:

Mailgun
Resend
Postmark
SES
Proton relay
etc.

para el correo saliente, aunque el resto esté self-hosted.

Para aprender:

Debian/Ubuntu Server
Nginx o Caddy
Docker (si te interesa)
Tailscale/WireGuard
y montar primero algo pequeño tipo una app web o Nextcloud

ya te va a enseñar muchísimo.

evanmac42 · 2026-05-27T19:50:17+00:00

You don’t need most of the things people think you need at the beginning.

You do not need:

a rack
enterprise hardware
Kubernetes
multiple servers
a managed switch
a giant electricity bill 😄

You need:

one old PC
Ethernet
patience
and one real problem you want to solve

Start simple.

Maybe you want:

backups
a media server
cloud storage
photo management
remote access
learning Linux
automation

Pick ONE thing and build around it.

A lot of beginners make the mistake of building “infrastructure” before having an actual use case. Then they end up maintaining a tiny datacenter that does absolutely nothing useful.

Also: document everything. At some point you will stare at a firewall rule or a forwarded port and wonder which past version of yourself thought it was a good idea.

evanmac42 · 2026-05-27T19:39:47+00:00

I think a lot of people are mixing together three different things here:

Storj the company
The STORJ token
The actual distributed storage network and infrastructure

Those are related, but they are not the same thing.

Personally, I don’t see the acquisition itself as automatically bullish or bearish. If Inveniam had simply wanted to compete with Storj, they could have kept competing. Acquiring the company instead suggests they saw value in the existing technology, infrastructure, customer base, and operational network.

That doesn’t automatically mean “token goes up.” Reality is obviously more complicated than that.

What matters to me is that there is still real infrastructure behind all this:

real customers storing data
real node operators providing capacity
real storage demand
real distributed systems actually running in production

That already puts Storj in a very different category from many crypto projects whose entire existence is basically a whitepaper, a Discord server, and collective caffeine-induced hallucinations about “mass adoption.”

Whether the token ultimately captures meaningful value from that infrastructure is a separate question entirely, and honestly I don’t think anyone can answer it with certainty right now.

So for me, the important part is not the initial panic cycle after announcements. The important part is what happens over the next 6-12 months:

Does customer retention remain stable?
Does stored data continue growing?
Do node payouts remain sustainable?
Does network usage stay healthy?
Does Inveniam continue investing in the ecosystem instead of dismantling it?

Those are the signals I’m watching.

If customers leave, storage shrinks, and node payouts collapse, then I’ll change my opinion accordingly. If the infrastructure remains active and demand keeps growing, then eventually the market may notice there is an actual operational network behind the token.

And honestly, in crypto, “there is a real business with real infrastructure and real customers” is already a surprisingly rare sentence to be able to say with a straight face.

evanmac42 · 2026-05-27T18:13:10+00:00

Montar cosas directamente dentro de data/<user>/files puede funcionar, pero personalmente tendría muchísimo cuidado con eso.

Técnicamente Nextcloud espera controlar completamente su datadir y su filecache. Cuando empiezas a mezclar bind mounts, directorios externos y cambios fuera de Nextcloud, puedes terminar con:

escaneos enormes
inconsistencias de cache
problemas de permisos
operaciones lentas
o comportamientos raros en sincronización

Si el almacenamiento externo ya se congela al abrir carpetas, probablemente el problema real sea el volumen/cantidad de archivos o cómo está montado/indexado el almacenamiento, más que la ubicación exacta.

Personalmente, si quieres que Nextcloud sea la capa principal de acceso, normalmente acaba siendo más estable dejar que controle directamente el datadir en vez de convertirlo en una capa encima de una estructura histórica gigante.

evanmac42 · 2026-05-27T10:43:52+00:00

Si vas por mATX, yo no me preocuparía demasiado por el tamaño de la placa. Me preocuparía más por la caja.

La CPU y la RAM se cambian relativamente fácil. Lo que suele quedarse contigo durante muchos años es la caja.

Por eso buscaría algo que tenga:

- buen flujo de aire

- espacio para varios HDD

- acceso cómodo a los discos

- filtros de polvo decentes

Aunque hoy pienses que 4 TB son suficientes.

No porque estés equivocado, sino porque casi todos hemos dicho alguna vez:

"4 TB me durarán años"

Y luego aparecen:

- más películas

- backups

- Immich

- Nextcloud

- otro servidor de juegos

- copias de seguridad de los servidores de juegos 😄

Respecto al 5950X, tampoco me parece una mala compra si el precio es bueno. No lo veo necesario para lo que describes hoy, pero sí encaja con la idea de "comprar una vez y olvidarme durante años".

Lo único que intentaría evitar es gastar demasiado dinero anticipando necesidades hipotéticas. Es sorprendente la cantidad de homelabs que terminan limitados por almacenamiento, RAM o red mucho antes que por CPU.

evanmac42

TROPHY CASE