Cross-posted to: https://sh.itjust.works/post/14975090

---

Solution

I'm still not really sure exactly what the root cause of the issue was (I would appreciate it if someone could explain it to me), but I disabled HTTPS on the Nextcloud server nextcloud.disable-https and it, all of a sudden, started working. My Caddyfile simply contains the following: nextcloud.domain.com { server-LAN-ip:80 }

Original Post

I am trying to upgrade my existing Nextcloud server (installed as a Snap) so that it is sitting behind a reverse proxy. Originally, The Nextcloud server handled HTTPS with Let's Encrypt at domain.com; now, I would like for Caddy to handle HTTPS with Let's Encrypt at nextcloud.domain.com and to forward the traffic to the Nextcloud server.

With my current setup, I am encountering an error where it is saying 301 Moved Permanently. Does anyone have any ideas on how to fix or troubleshoot this?

Caddyfile: https://nextcloud.domain.com { reverse_proxy 192.168.1.182:443 header / Strict-Transport-Security max-age=31536000; } And here is the output of curl -v https://nextcloud.domain.com/: ```

• Host nextcloud.domain.com:443 was resolved.
• IPv6: (none)
• IPv4: public-ip
• Trying public-ip:443...
• Connected to nextcloud.domain.com (public-ip) port 443
• ALPN: curl offers h2,http/1.1
• TLSv1.3 (OUT), TLS handshake, Client hello (1):
• CAfile: /etc/ssl/certs/ca-certificates.crt
• CApath: none
• TLSv1.3 (IN), TLS handshake, Server hello (2):
• TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
• TLSv1.3 (IN), TLS handshake, Certificate (11):
• TLSv1.3 (IN), TLS handshake, CERT verify (15):
• TLSv1.3 (IN), TLS handshake, Finished (20):
• TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
• TLSv1.3 (OUT), TLS handshake, Finished (20):
• SSL connection using TLSv1.3 / TLS_CHACHA20_POLY1305_SHA256 / x25519 / id-ecPublicKey
• ALPN: server accepted h2
• Server certificate:
• subject: CN=nextcloud.domain.com
• start date: Feb 21 06:09:01 2024 GMT
• expire date: May 21 06:09:00 2024 GMT
• subjectAltName: host "nextcloud.domain.com" matched cert's "nextcloud.domain.com"
• issuer: C=US; O=Let's Encrypt; CN=R3
• SSL certificate verify ok.
• Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
• Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
• Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption
• TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
• using HTTP/2
• [HTTP/2] [1] OPENED stream for https://nextcloud.domain.com/
• [HTTP/2] [1] [:method: GET]
• [HTTP/2] [1] [:scheme: https]
• [HTTP/2] [1] [:authority: nextcloud.domain.com]
• [HTTP/2] [1] [:path: /]
• [HTTP/2] [1] [user-agent: curl/8.6.0]
• [HTTP/2] [1] [accept: /] > GET / HTTP/2 > Host: nextcloud.domain.com > User-Agent: curl/8.6.0 > Accept: / > < HTTP/2 301 < alt-svc: h3="public-ip:443"; ma=2592000 < content-type: text/html; charset=iso-8859-1 < date: Wed, 21 Feb 2024 07:45:34 GMT < location: https://nextcloud.domain.com:443/ < server: Caddy < server: Apache < strict-transport-security: max-age=31536000; < content-length: 250 <

301 Moved Permanently

<h1>Moved Permanently</h1> <p>The document has moved here.</p>

• Connection #0 to host nextcloud.domain.com left intact ```

Workaround

I'm not sure what was going wrong with what I was doing initially, but, thanks to @[email protected], as suggested, I disabled the tftp server system service, and, instead, started it with the following command: sudo in.tftpd -L /srv/tftp --verbose --permissive -s and it then flashed successfully.

Original Post

cross-posted from: https://sh.itjust.works/post/11735447

> I'm trying to flash firmware to a router (Archer C7) using TFTP, but, when the router makes the request for the firmware file over TFTP, the TFTP server responds with the following error > > Error code: Access violation (2) > Error message: Only absolute filenames allowed > > > --- > > This is the config for tftpd in /etc/conf.d/tftpd: > > TFTP_OPTIONS="-s" > TFTP_DIRECTORY="/srv/tftp" > TFTP_USERNAME="tftp" > TFTP_ADDRESS="192.168.0.66:69" > > I have the firmware file in /srv/tftp, and both the firmware file, and /srv/tftp have chmod 777 permissions. > > The TFTP server is running on Archlinux, and is installed as tftp-hpa from the arch repos.

---

If I test as a client, I can get it to download if I specify the full (absolute) path to the file /srv/tftp/filename, so it seems that the config isn't pointing the server to /srv/tftp as the relative path... How would I go about fixing that?

I bought a Eaton Ellipse Eco 650 USB DIN for my Homelab. I connected it to my nas which is running OpenMediaVault because OMV has a NUT Plugin. I conneced it, it got recognised and i thought i should test it. So i switched the breaker off and my nas turned off safely after my entered time. I then went to turn the breaker back on, but after a few seconds the ups shuts the power off all devices and applies it after a second. This only happens when the nas is connected via usb.

• is there a setting that i missed in nut?
• is my ups broken (i dont think so)
• what could be the problem?

Edit: Wow, the Eaton Germany Support is terrible. I called them multiple times and i think they dont even have a Call Center. I now submitted a Support Ticket. They could at least tell you that they dont have telephone support right now. If i get a response i will update this.

Edit2: It turns out, it was a issue with the integrated nut tools in OpenMediaVault. After removing them and installing them via apt and configuring it with the config files, it works without any power loss.