Zugriff auf Nextcloupi

🌐 Non-english support 🇩🇪 Deutsch (german)
,
1

Hallo Forum!

Nach mehreren gescheiterten Versuchen, Nextcloud auf meinem Raspberry zum Laufen zu bringen, habe ich nun Nextcloudpi darauf installiert.

Nach dem Wizard habe ich nun noch einige Einstellungen (Localisation, NextCloudPi-Config etc.) vorgenommen, jetzt ist weder Nextcloud noch Nextcloudpi über das Webinterface erreichbar. SSH funktioniert.

Ich bekommen immer die klassische Meldung “Fehler: Netzwerk-Zeitüberschreitung”. Ich habe es schon mit allen möglichen Varianten probiert: IP.local, IP mit und ohne https, IP:4443, nextcloudpi.local usw.

Was tun?

LG

SMichel

2

Hast du auf dem Raspi vielleicht unbewusst eine Firewall (z.B. ufw) aktiviert? Das wäre meine erste Vermutung.

Wenn nein, dann würde ich erst einmal auf Client-Seite schauen, was mit einem Request passiert. Einfach in einem Browser die Developer-Console (F12) öffnen und einen Request absetzen (einfach die HTTPS-Adresse). Hier siehst du dann Redirects, etc.

Wenn es hier dann so aussieht, als ob der Request bei deinem Raspi ankommt, dann geht es mit der Fehlersuche auf der Server-Seite weiter. Hier wäre die erste Anlaufstelle die Logs des Webservers. Hier sollte dann auf jeden Fall eine Fehlermeldung protokolliert werden.

3

UFW habe ich aktiviert, in der Annahme, dass somit die notwendigen Ports freigeschaltet sind.

Das ist das, was bei einem Request in der Console herauskommt:

html

In welchem Log (/var/log/apache2) soll ich da was suchen? Die meisten Logs sind leer, oder ich werde nicht wirklich schlau daraus:

    [Sat Nov 10 12:17:30.378096 2018] [ssl:warn] [pid 1014:tid 1996095888] AH01909: localhost:443:0 server certificate does NOT incl$
[Sat Nov 10 12:17:30.378460 2018] [ssl:error] [pid 1014:tid 1996095888] AH02217: ssl_stapling_init_cert: can't retrieve issuer c$
 10 12:17:30.378096 2018] [ssl:warn] [pid 1014:tid 1996095888] AH01909: localhost:443:0 server certificate does NOT
include an ID which matches the server name[Sat Nov 10 12:17:30.378488 2018] [ssl:error] [pid 1014:tid 1996095888]
AH02604: Unable to configure certificate localhost:443:0 for stapling [Sat Nov 10 12:17:30.378460 2018] [ssl:error] [pid
1014:tid 1996095888] AH02217: ssl_stapling_init_cert: can't retrieve issuer certificate! [subject: CN=archlinux / issuer:
CN=archlinux / serial: F572DE720D75CA14 / notbefore: Oct 23 14:32:17 2018 GMT / notafter: Oct 20 14:32:17 2028 GMT] [Sat
Nov 10 12:17:30.378488 2018] [ssl:error] [pid 1014:tid 1996095888] AH02604: Unable to configure certificate
localhost:443:0 for stapling
4

Ich meinte in der Developer-Console eher den Punkt “Netzwerkanalyse”, wo man besser sehen kann, was mit dem Request passiert.

Die Log-Einträge sind hier alle abgeschnitten, da kann man nur rauslesen, dass irgendwas mit dem SSL-Zertifikat nicht stimmt. Das wäre aber keine Erklärung für den Timeout.

Wenn du ufw aktiviert hast, dann versuch doch erst einmal ufw disable. Wenn es danach geht, ist wirklich ufw die Ursache und man muss die verwendeten Ports (vermutlich 80/443) freischalten.

5

Danke für die Antwort!
Mittlerweile ist alles wieder neu (Image neu aufgespielt). Den wizard hab ich wieder absolviert, alles grün. Dann hab ich eine statische IP vergeben und die Ports im Router entsprechend weitergeleitet. Dann noch das Update eingespielt (bislang alles über die Browseroberfläche). Beim Update kam die Meldung “da ist etwas schiefgelaufen, lade die Seite neu” - sinngemäß. Jetzt geht über den Browser wiederum gar nichts mehr. Über Putti habe ich noch Zugriff, allerdings über die vom Router vergebene Adresse …15 und nicht über die statische IP …30.

Im Router ist der Raspi weder mit der statischen noch der DNS-Adresse aufgeführt, quasi nicht existent.

Hier noch die Ergebnisse der Netzwerkanalysen bei den verschiedenen Requests:

154443
1544431237×127 28.8 KB

4443
44431240×136 29.7 KB

Nachdem ich über Putty noch Zugriff habe, habe ich zuerst von dort aus das Update eingespielt - diesmal OK.

Danach habe ich noch die lokalen Einstellungen geändert, file-system-expand, beim Update von raspi-config gab es eine Fehlermeldung: “E: dpkg was interrupted, you must manually run ‘sudo dpkg --configure -a’ to correct the problem.”

Dem geforderten Reboot beim Beenden von raspi-config habe ich zugestimmt. Danach war der Raspi auch wieder in der Devices Summary meines Routers mit der statischen IP aufgeführt. Unter dieser ist er jedoch via Browser weiterhin nicht erreichbar und über Putty auch nicht mehr.

UFW habe ich diesmal nicht aktiviert.

LG
SMichel

6

Ich denke, dass hier mit der Netzwerk-Konfiguration etwas nicht stimmt.
Du meintest ja, dass du nicht über die statische IP Zugriff hast, sondern über die vom Router vergebene. Damit funktionieren vermutlich auch die Portfreigaben nicht. Hier würde ich zunächst nochmal die Netzwerk-Einstellungen des Raspi kontrollieren, so dass dieser auch wirklich nur mit der statischen IP erreichbar ist (siehe hier).
Um alles weitere kann man sich dann im Anschluss kümmern.

7

Hallo!
OK, wieder neu aufgesetzt und diesmal versucht ohne den Wizard auszukommen, weil da ja die statische IP nicht drin ist und ich den Verdacht habe, dass sich da was spiesst, wenn man zuerst die Portweiterleitung etc. über den Wizard macht und danach erst die statische IP vergibt.

Diese habe ich nun über die Web-Oberfläche vergeben, der Raspi wird mir in der Rout-Konfig auch mit dieser Adresse angezeigt, und die Ports sollten lt. diesem Test offen sein.

Allerdings findet sich in /etc/network/interfaces kein Eintrag, der auf eine statische IP hindeuten würde, der Raspi ist jedoch über Putty unter der statischen IP erreichbar.

No-IP-Konfigurieren - OK
dnsmasq - OK
pretty URL - OK
…

Nur bei letsencrypt habe ich plötzlich Fehlermeldungen:

[ letsencrypt ]
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
An unexpected error occurred:
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 138, in _new_conn
(self.host, self.port), self.timeout, **extra_kw)
File "/usr/lib/python3/dist-packages/urllib3/util/connection.py", line 75, in create_connection
for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
File "/usr/lib/python3.6/socket.py", line 745, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -3] Temporary failure in name resolution

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 594, in urlopen
chunked=chunked)
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 350, in _make_request
self._validate_conn(conn)
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 837, in _validate_conn
conn.connect()
File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 281, in connect
conn = self._new_conn()
File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 147, in _new_conn
self, "Failed to establish a new connection: %s" % e)
requests.packages.urllib3.exceptions.NewConnectionError: : Failed to establish a new connection: [Errno -3] Temporary failure in name resolution

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/requests/adapters.py", line 423, in send
timeout=timeout
File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 643, in urlopen
_stacktrace=sys.exc_info()[2])
File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 363, in increment
raise MaxRetryError(_pool, url, error or ResponseError(cause))
requests.packages.urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))

During handling of the above exception, another exception occurred:

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError(': Failed to establish a new connection: [Errno -3] Temporary failure in name resolution',))
Please see the logfiles in /var/log/letsencrypt for more details

Hier noch das Log dazu:

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 423, in send
    timeout=timeout
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 643, in urlopen
    _stacktrace=sys.exc_info()[2])
  File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 363, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
requests.packages.urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='acme-v02.api.letsencrypt.org', port=443): Max retries exceeded with url: /directory (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x75997b50>: Failed to establish a new connection: $

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/bin/letsencrypt", line 11, in <module>
    load_entry_point('certbot==0.27.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1364, in main
    return config.func(config, plugins)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1238, in certonly
    le_client = _init_le_client(config, auth, installer)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 641, in _init_le_client
    acc, acme = _determine_account(config)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 520, in _determine_account
    config, account_storage, tos_cb=_tos_cb)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 180, in register
    acme = acme_from_config_key(config, key)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 50, in acme_from_config_key
    return acme_client.BackwardsCompatibleClientV2(net, key, config.server)
  File "/usr/lib/python3/dist-packages/acme/client.py", line 761, in __init__
    directory = messages.Directory.from_json(net.get(server).json())
  File "/usr/lib/python3/dist-packages/acme/client.py", line 1095, in get
    self._send_request('GET', url, **kwargs), content_type=content_type)
  File "/usr/lib/python3/dist-packages/acme/client.py", line 1044, in _send_request
    response = self.session.request(method, url, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 488, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python3/dist-packages/requests/sessions.py", line 609, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python3/dist-packages/requests/adapters.py", line 487, in send
    raise ConnectionError(e, request=request)

2018-11-15 20:23:38,551:DEBUG:certbot.main:certbot version: 0.27.0
2018-11-15 20:23:38,556:DEBUG:certbot.main:Arguments: ['-n', '--no-self-upgrade', '--webroot', '-w', '/var/www/nextcloud', '--hsts', '--agree-tos', '-m', 'admin@mopet.org', '-d', 'mopet.ddns.net']
2018-11-15 20:23:38,560:DEBUG:certbot.main:Discovered plugins: PluginsRegistry(PluginEntryPoint#manual,PluginEntryPoint#null,PluginEntryPoint#standalone,PluginEntryPoint#webroot)
2018-11-15 20:23:38,601:DEBUG:certbot.log:Root logging level set at 20
2018-11-15 20:23:38,605:INFO:certbot.log:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2018-11-15 20:23:38,608:DEBUG:certbot.plugins.selection:Requested authenticator webroot and installer None
2018-11-15 20:23:38,609:DEBUG:certbot.plugins.selection:Single candidate plugin: * webroot
Description: Place files in webroot directory
Interfaces: IAuthenticator, IPlugin
Entry point: webroot = certbot.plugins.webroot:Authenticator
Initialized: <certbot.plugins.webroot.Authenticator object at 0x75a25870>
Prep: True
2018-11-15 20:23:38,619:DEBUG:certbot.plugins.selection:Selected authenticator <certbot.plugins.webroot.Authenticator object at 0x75a25870> and installer None
2018-11-15 20:23:38,619:INFO:certbot.plugins.selection:Plugins selected: Authenticator webroot, Installer None
2018-11-15 20:23:40,702:DEBUG:acme.client:Sending GET request to https://acme-v02.api.letsencrypt.org/directory.
2018-11-15 20:23:41,045:DEBUG:requests.packages.urllib3.connectionpool:Starting new HTTPS connection (1): acme-v02.api.letsencrypt.org
2018-11-15 20:23:51,064:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 138, in _new_conn
    (self.host, self.port), self.timeout, **extra_kw)
  File "/usr/lib/python3/dist-packages/urllib3/util/connection.py", line 75, in create_connection
    for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
  File "/usr/lib/python3.6/socket.py", line 745, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -3] Temporary failure in name resolution

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 594, in urlopen
    chunked=chunked)
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 350, in _make_request
    self._validate_conn(conn)
  File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 837, in _validate_conn
    conn.connect()
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 281, in connect
    conn = self._new_conn()
  File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 147, in _new_conn
    self, "Failed to establish a new connection: %s" % e)
requests.packages.urllib3.exceptions.NewConnectionError: <requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x75997b50>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution

Es hätte ja weitgehend recht gut ausgesehen, aber jetzt steh ich wieder an.

LG

SMichel

8

Ok, da war noch ein Denkfehler drin, mit dem Portcheck habe ich lediglich die öffentliche IP getestet und die geht logischerweise, ich bin ja online.

In der System Info des Raspi, werden die beiden notwendigen Ports jedoch als closed bezeichnet, und ich kommt nicht so recht dahinter, woran das liegt bzw. wie ich die beiden aufkriege.

sudo ufw allow 443 hab ich schon versucht, die Regel wird hinzugefügt, aber das ändert nichts.
NC

Portforwarding auf die statische IP *.30 habe ich gesetzt.

PF

9

Mittlerweile habe ich so einige Varianten ausprobiert: UMF deaktiviert, DDNS-noIP, deaktiviert etc.

Beim Versuch der Portweiterleitung über das Webinterface bekomme ich einerseits grünes Licht:

Unbenannt

andererseits wird aber neben der Portweiterleitung kein Haken gesetzt:

q

dafür erhalten ich nachstehende Meldung:

[ nc-forward-ports ]
upnpc : miniupnpc library test client, version 2.1.
(c) 2005-2018 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
desc: http://192.168.0.1:80/RootDevice.xml
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://192.168.0.1:80/WANIPConnection
Local LAN ip address : 192.168.0.30
UPNP_DeletePortMapping() returned : 0
upnpc : miniupnpc library test client, version 2.1.
(c) 2005-2018 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
desc: http://192.168.0.1:80/RootDevice.xml
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://192.168.0.1:80/WANIPConnection
Local LAN ip address : 192.168.0.30
UPNP_DeletePortMapping() returned : 0
upnpc : miniupnpc library test client, version 2.1.
(c) 2005-2018 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
desc: http://192.168.0.1:80/RootDevice.xml
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://192.168.0.1:80/WANIPConnection
Local LAN ip address : 192.168.0.30
ExternalIPAddress = xxx.xxx.xxx.xxx
InternalIP:Port = 192.168.0.30:443
external xxx.xxx.xxx.xxx:443 TCP is redirected to internal 192.168.0.30:443 (duration=0)
upnpc : miniupnpc library test client, version 2.1.
(c) 2005-2018 Thomas Bernard.
Go to http://miniupnp.free.fr/ or https://miniupnp.tuxfamily.org/
for more information.
List of UPNP devices found on the network :
desc: http://192.168.0.1:80/RootDevice.xml
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1

Found valid IGD : http://192.168.0.1:80/WANIPConnection
Local LAN ip address : 192.168.0.30
ExternalIPAddress = xxx.xxx.xxx.xxx
InternalIP:Port = 192.168.0.30:80
external xxx.xxx.xxx.xxx:80 TCP is redirected to internal 192.168.0.30:80 (duration=0)

Die Ports bleiben geschlossen. In der Systeminfo wird mir geraten die Ports zu öffnen - ja eh…

Ich tendiere dazu, das Ding zum 30. mal neu aufzusetzen, aber ich wüsste jetzt auch nicht, was ich anders machen sollte.

LG

SMichel

10

Jetzt habe ich noch “Initialisierung” versucht und somit alles wieder auf defaults gesetzt, mit dem Erfolg, dass die Ports scheinbar per detault geschlossen sind…

So, alles neu (Image wieder einmal neu aufgespielt). Zuerst über Putty die lokalen Einstellungen und das Passwort geändert.

Dann über das Webinterface: Auf den Wizard hab ich verzichtet, statische IP eingerichtet, da wird mir auf dem Webinterface zwar die IP *.30 angezeigt, in der System-Info steht aber immer noch die Vergabe des Routers, der *.15 zugewiesen hat. Im Interface des Routers wird aber nur die Verbindung über die Statische angezeigt, die *.15 ist ja gar nicht vergeben, und das Webinterface habe ich ja auch über *.30:4443 geöffnet???

1

2

Wie diese Ausgaben paralell zustande kommen können ist mir rätselhaft.

Zumindest sind die Ports auf der IP *.15 geöffnet, was mich aber nicht weiterbringt. Ein bisschen zumindest: Aufgrund der offenen Ports konnte ich wenigstens das Update anstossen. Auch das Update wirft eine Frage auf: Da wird mir ausgeworfen: “438 not upgraded”, soll ich das über Putty und sudo apt update && sudo apt upgrade machen?

Abgesehen davon endet das Update mit “Something went wrong. Try refreshing the page”. Also refresh: Das hat wiederum den Erfolg, dass NPC über das Webinterface gar nicht mehr erreichbar ist, weder über xxx.30:4443 noch über xxx.15:4443. Im Router ist nach wie vor nur die Statische (*.30) aufgeführt, lt. Router gibt es nichts, was über *.15 läuft_ oder über eine andere IP und Raspi heisst.

Dafür ist NPC via Putty unter *.15 und *.30 erreichbar…

11

Liebes Tagebuch!

Neues Spiel neues Glück:

Raspi-SD neu formatiert, auf Fehler gescannt - alles gut. Image neu aufgespielt…

Habe nach dem letzten fehlerhaften Updateversuche nun das Update als erstes und von der Putty-Konsole aus angestossen. Ist sauber durchgelaufen. Dann noch das Benutzerpasswort geändert und die lokalen Einstellungen angepasst.

Seltsamerweise bekomme ich über die Weboberfläche jetzt überhaupt keinen Zugang mehr.

Habe die statische IP wieder auf xxx.30 gesetzt. Die Portweiterleitung funktioniert nicht, es gibt da die Meldung, dass es ein Problem mit der IP gäbe, offenbar läuft der Raspi wieder mit 2 IPs (xxx.15 und die Statische xxx.30). Lt. ifconfig scheint dort tatsächlich noch die xxx.15 auf. Keine Ahnung wie ich das jetzt reparieren soll.

pi@nextcloudpi:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.15  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 xxx:xxx:xxx:xxx  prefixlen 64  scopeid 0x20<link>
        ether xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 3348  bytes 1148693 (1.0 MiB)
        RX errors 0  dropped 5  overruns 0  frame 0
        TX packets 2096  bytes 451391 (440.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Lokale Schleife)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether xx:xx:xx:xx:xx:xx  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

pi@nextcloudpi:~ $

sudo ufw disable führt jetzt dazu, dass ich vom Raspi aus pingen kann, was bislang noch nie, oder nur kurzzeitig der Fall war. Laut Open Port Check Tool - Test Port Forwarding on Your Router sind auf beiden IP-Adressen immer noch alle relevanten Ports zu. Vielleicht wäre es ja hilfreich den Raspi aus dem Fenster zu werfen und einen neuen zu kaufen.

Obwohl laut Router ja bereits eine statische IP läuft, habe ich jetzt trotzdem noch zusätzlich unter /etc/dhcpcd.conf diese IP konfiguriert.

Nach einem reboot scheint jetzt in der ifconfig wenigstens die gewünschte statische IP auf. Der Raspi ist jetzt auch nicht mehr über Putty unter der vom Router vergebenen IP erreichbar. Gut so.

Ping geht auch noch. Lt. Open Port Check Tool - Test Port Forwarding on Your Router sind immer noch alle Ports zu.

Wieder zu sudo raspi-config: nc-forward-ports (UPnP aktiviert): Endet mit Done. Press any key... Gut so. Laut “yout get signal” sind immer noch alle ports zu, ping geht aber. Zugriff über Webinterface (192.168.0.30:4443) endet nach wie vor mit “Fehler. Verbindung fehlgeschlagen.” Die Netzwerkanalyse dazu ist nichtssagend:

Unbenannt
Unbenannt1254×122 28 KB

Änderungen unter nc-webui bringen keinerlei Verbesserung.

Unbenannt

Wobei ich jetzt nicht sagen kann, ob das gut oder schlecht ist:

Launching nc-webui
./nc-webui.sh: Zeile 25: a2ensite: Kommando nicht gefunden.
ncp-web enabled
Done. Press any key...

Dann: DDNS_no-ip eingetragen: Endet mit Done. Press any key… Wird die no-ip-Domain aufgerufen, endet dies mit “Fehler. Netzwerkzeitüberschreitung.”

Dann: dnsmasq: Endet mit dnsmasq enabled Done. Press any key... Sehr gut. Die WebUI bleibt sowohl unter 192.168.0.30, 192.168.0.30:4443 und unter der no-ip-Domain unerreichbar. Laut “you get signal” sind alle Ports geschlossen.

Dann schau ich mir halt nochmal die UFW an:

Unbenannt

…ändert auch nichts daran, dass ich das Webinterface nicht erreiche…

Ich hasse meinen Raspi…

Wie kann es eigentlich sein, dass die Pings fehlerfrei funktionieren, wenn andererseits alle Ports zu sind und z. B. letsencrypt meldet Connection refused???

12

Liebes Tagebuch!

Eigentlich bin ich ja auf Nextcloudpi gekommen, weil das einfacher zu konfigurieren sein soll als eine Nextcloud-Installation von Hand. Mag sein, ich krieg keines von beiden zum Laufen.

Launching nc-init

…

NC init done
Done. Press any key...

…

Alle Ports zu.
Kein Webinterface.
Gute Nacht.

13

Sorry, lange nicht hier gewesen…

Ehrlich gesagt habe ich noch nie NextcloudPi ausprobiert. Ich weiß nur, dass hier vieles mit irgendwelchen Scripts automatisch gemacht wird, um das ganze möglichst einfach zu machen. Genau hier scheint bei dir der Wurm drin zu sein. Aus den ganzen Logs, etc. werde ich allerdings auch nicht schlau.

Ich sehe da nun zwei Möglichkeiten:

  • Frage doch mal im Forum für NextcloudPi nach (https://help.nextcloud.com/c/support/appliances-docker-snappy-vm). Ich kann mir vorstellen, dass sich nicht viele Leute ins deutsche Forum “verirren”. Im englischen Forum solltest du schneller eine Antwort bekommen.
  • Du hast ja nun wohl schon etliche Stunden in das Projekt investiert. Vermutlich wäre es schneller, wenn du Nextcloud einfach manuell installieren und konfigurieren würdest. Das sollte ein einmaliger Aufwand von 2-3 Stunden sein, aber dann weißt du ganz genau, was du gemacht hast und auch an welchen Stellschrauben du drehen müsstest, wenn irgendwas nicht mehr funktionieren sollte.
14

Hallo und danke für die Antwort.
Von da (Nextcloud von Hand auf dem Pi aufsetzen) komme ich her…

Aber ich werde es in dem von dir vorgeschlagenen Forum auf englisch versuchen.

Nochmals vielen Dank!

SMichel