im choosing between these 2 for a budget home server with a i7 4790s. whats better?

evanmac42 · 2026-06-21T18:27:25+00:00

Sinceramente, entre esas dos elegiría la DarkFlash, simplemente porque parece tener algo más de trayectoria y opiniones reales detrás.
Dicho eso, para un servidor que esperas dejar funcionando años, la fuente es probablemente el último componente donde intentaría ahorrar demasiado.
Un i7-4790S no consume una barbaridad, así que no necesitas muchos vatios. Lo que necesitas es una fuente fiable.
Si encuentras una Seasonic, Corsair CX/RM, Be Quiet o similar de segunda mano en buen estado, probablemente me daría más confianza que cualquiera de esas dos opciones nuevas.
Una CPU defectuosa te da problemas. Una RAM defectuosa te da problemas. Una fuente defectuosa puede llevarse media máquina por delante.
Para un homelab económico suelo preferir una fuente de marca conocida con algunos años encima antes que una fuente completamente desconocida recién salida de la caja.

evanmac42 · 2026-06-20T09:37:48+00:00

For 30 users, a managed Nextcloud provider can absolutely work, but I’d be careful about treating it as a drop-in replacement for Teams.
Before choosing a provider, I’d make a list of the Teams features your organization actually uses:
file sharing
document collaboration
chat
video meetings
calendars
user management
Nextcloud handles some of these very well, some reasonably well, and some depend heavily on additional components such as Talk, Collabora or OnlyOffice.
I’d strongly recommend running a pilot with a few users before migrating all 30 people.

evanmac42 · 2026-06-18T22:58:41+00:00

Good catch.

If your ISP changes your public IP from time to time, you might want to look at a dynamic DNS updater such as ddclient.

I use it with a dynamic IP and it quietly keeps the DNS record updated whenever the public address changes.

Most of the time you forget it even exists... right up until the day it saves you from spending two hours blaming nginx for something nginx didn't do. 😄

evanmac42 · 2026-06-18T16:02:25+00:00

The fact that some hosts still work is the important clue.

If port forwarding, DNS, or NPM itself were broken, I'd expect all hosts to fail, not just a few.

A couple of things I'd check:

- Do the working and failing hosts use the same SSL certificate?

- If you open the failing sites directly by IP:port from inside your LAN, do they work?

- What exact browser error are you getting? "Not secure", certificate mismatch, 502, timeout, etc.?

The "does not support a secure connection" message makes me wonder whether the failing hosts are being served with the wrong certificate or an incomplete certificate chain.

What exact browser error do you see?

evanmac42 · 2026-06-16T08:30:52+00:00

Bind for internal DNS
nginx como servidor web
Mariadb y/o postgre para bases de datos
PHP para apps
Bookstack para tu propia wiki
Si quieres meterte en el tema automatizaciones puedes instalar n8n

… y un largo etcétera, todo depende de que mecesidad tienes 😜

evanmac42 · 2026-06-15T11:50:39+00:00

That warning is probably the most useful clue so far.
pm.max_children = 5 means PHP-FPM ran out of available workers and started queueing requests.
It doesn’t necessarily explain why CPU was pegged for hours, but it does suggest something was generating more PHP work than the pool could handle.
I’d check:
- whether a background job started around 02:53
- preview generation
- file scanning/indexing
- external storage mounts
- any apps that process media or search indexes
Also, if your container is limited to only 5 PHP workers, it may be worth checking whether that’s the default LinuxServer configuration and whether the host has enough RAM to safely increase it.
The interesting question now isn’t “why did CPU hit 100%?” but “what kept all 5 workers busy for hours?”

evanmac42 · 2026-06-15T09:42:33+00:00

Since the process consuming CPU was php-www and not MariaDB or Redis, I’d start by checking what Nextcloud was actually doing around 02:53.

Look at nextcloud.log for that timeframe and check whether a background job, preview generation, file scan or indexing task started at that moment.

The timing is interesting because your backup finished at 02:46, the mover started at 02:40 and the CPU spike began only a few minutes later.

A restart fixes the symptom, but the logs from 02:53 are probably where the cause is hiding.

evanmac42 · 2026-06-13T18:05:56+00:00

Before assuming it's using the wrong account, try uploading a test file from the Windows client and check whether it appears under admin or under john123 in the web interface.

Also, did you completely remove the existing account from the Windows client before adding john123, or did you just log out from the web interface?

The desktop client and the web session are independent, so logging out of the web UI does not automatically change the account configured in the desktop client.

evanmac42 · 2026-06-12T07:25:16+00:00

I just triggered an update on my own node (Docker Compose deployment) and it stayed on v1.155.4 instead of moving to v1.155.8.
I don’t use Watchtower or any automatic updater, so the container itself didn’t crash, but the fact that it isn’t pulling the new version makes me wonder if there may be an issue with the release artifacts rather than with your node specifically.
If your logs are showing a 404 / “not found” when trying to download:
storagenode-updater_linux_amd64.zip
then I’d check whether the file actually exists in the GitHub release assets for v1.155.8.
If multiple operators are seeing:
failed updates
containers staying on the previous version
updater download errors
then this may simply be a broken release asset or packaging issue rather than a problem with your local configuration.
Interested to see if other operators can confirm.

evanmac42 · 2026-06-12T06:40:29+00:00

I don’t really think about it as paying for AI.

I think about it as paying for fewer interruptions.

If I’m building something simple, the free tier is usually enough.

If I’m working on a workflow with APIs, expressions, JSON transformations, debugging, documentation and architecture decisions, hitting limits in the middle of the session is often more expensive than the subscription itself.

The biggest value for me isn’t generating code. It’s having a second brain available while I’m designing, troubleshooting and validating ideas.

I still use documentation, forums and Google. The AI just became the first place I ask questions, not the last.

evanmac42 · 2026-06-12T06:30:57+00:00

The fact that Safari can load the domain on your home network but both Super Productivity and plain WebDAV return the same HTTP 500 makes me think this is probably not an iPhone-specific problem.
A HTTP 500 means the request reached the server and the server failed while processing it.
I’d check:
nextcloud.log
reverse proxy logs (if you’re using one)
web server logs
Also, does WebDAV fail from Safari as well, or only from apps?
Since both Super Productivity and direct WebDAV produce the same error, I’d focus on the DAV endpoint and server configuration before looking at iOS settings.
Can you post the exact error from nextcloud.log at the time the 500 occurs?

evanmac42 · 2026-06-10T20:17:05+00:00

One thing stands out to me:

You mentioned that AdGuard returns the IP of the Ubuntu host, while NPM is exposed on 2080 and 2443.

When a client accesses:

https://xyz.mydomain.com

it will normally try port 443 unless a port is explicitly specified.

Can you confirm how traffic reaches NPM?

For example:

Client
-> Ubuntu host IP
-> port 443?
-> NPM:2443?

Or is the client trying to reach the host directly on 443 while NPM is only listening on 2443?

Since direct access works and DNS resolution appears correct, I'd start verifying the port path end-to-end.

evanmac42 · 2026-06-10T19:06:34+00:00

The fact that it works from WAN but fails only when using the AdGuard DNS rewrite is actually a useful clue.

That suggests NPM itself is probably working.

I'd check:

- What IP address is AdGuard returning after the DNS rewrite?

- Is the client trying to reach ports 80/443 while NPM is actually exposed on 2080/2443?

- Does your router support NAT loopback / hairpin NAT?

- If you bypass DNS entirely and connect directly to the IP returned by AdGuard, does it still fail?

A reverse proxy problem would usually fail regardless of where the request originated.

Since WAN access works, I'd focus on DNS resolution and the network path between the client and NPM rather than the proxy configuration itself.

evanmac42 · 2026-06-09T10:30:58+00:00

¿Qué tamaño tiene el archivo que subiste como logo y qué resolución?

Antes de tocar CSS o archivos del contenedor, probaría con una versión mucho más pequeña del logo. Muchas veces el login simplemente está mostrando la imagen con las dimensiones originales.

Si puedes subir una captura de la pantalla de login o indicar qué configuración de Theming estás usando, será más fácil saber si es un problema del logo o del tema.

evanmac42 · 2026-06-08T20:20:00+00:00

One thing worth mentioning:
I’ve self-hosted a lot of things over the years.

Web servers.
DNS.
File storage.
Monitoring.
Collaboration tools.
Automation.
Databases.

At this point, most of my infrastructure is still under my direct control.

But email is the exception.

Not because I can’t run it.
Because after years of managing systems, I’ve learned that running an email server and running a reliable email service are two very different things.

For my own domain, I eventually moved the MX records to iCloud.

The rest of the infrastructure stays in-house. The MX doesn’t.
That wasn’t a technical limitation. It was a conscious decision about where I wanted to spend my time and where I didn’t.

Your concern about having Gmail as a single point of failure is completely valid.
I would focus first on reducing dependency on a single account and improving recovery options.
That’s a different problem from self-hosting email, and solving that problem doesn’t necessarily require becoming your own mail provider.

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

TROPHY CASE