only via local network (with an invalid certificate, but that doesn't bother me)
Did you follow the macom guide? Do you have this line in your config.php file?:
'overwrite.cli.url' => 'https://your.url/nextcloud',
Or like this, if it is a subdomain:
'overwrite.cli.url' => 'https://nextcloud.your.url',
It's really not important, this already works. I'm just surprised it works like this for you locally.
Alles anzeigenHi guys,
I'm on OMV 6 now
I'm also aware it's not 100% stable, but currently I'm fine with this.
Thanks to KM0201 I managed to set up Nextcloud and Swag again
"ports:
- 450:443"
uncommented.
This means compared to the old set up I changed the ports as follows (equal to those in the manual mentioned above):
192.168.0.101:443 --> OMV admin interface
192.168.0.101:450 --> Nextcloud
<MY_EXTERNAL_IP>:443 --> Nextcloud
However, the original problem (local connection to Nextcloud is quite slow in uploading data) persists.
I've tried to set a so-called DNS-Rebind-Protection in my router with nextcloud.MYDOMAIN.duckdns.org. This didn't help.
The general issue with DNS is that I can't set the required port (as DNS doesn't understand ports afaik). This made me wonder how chente accomplished this with DNS? Did you change your OMV admin interface port?
Does anyone have another idea on how to solve this?
Also, I'm a bit unsure about my way to "measure" the connection. What I currently do to find out if it works is:
- Uploading an example file to Nextcloud (and seeing that it's slow compared to SMB). But it could be that Nextcloud itself is just slow in accepting the uploaded data.
- And: tracert nextcloud.MYDOMAIN.duckdns.org
Getting:
1 1 ms <1 ms <1 ms fritz.box [192.168.0.1]
2 1 ms 1 ms 1 ms XXXXXXXXX.dip0.t-ipconnect.de [<MY_EXTERNAL_IP>]
Maybe someone can tell me if this is a reliable way to detect the routing?
Thank you
When you're going to "myexternalip:443".. is this secured or are you just forwarding ports?
If you read that whole post start to finish and do as I put, it should work just fine or you're having some other issue. I'm confused, because nowhere in that did I put anything about "externalip:443". Externally you should be using your subdomain, that's the whole point.
Did you follow the macom guide? Do you have this line in your config.php file?:
'overwrite.cli.url' => 'https://your.url/nextcloud',
Or like this, if it is a subdomain:
'overwrite.cli.url' => 'https://nextcloud.your.url',
It's really not important, this already works. I'm just surprised it works like this for you locally.
I followed this guide from @KM0201
Works like a charm. Then I started adapting the solution so my local traffic would stay local (according to tracert).
So my config.php looks now like this:
<?php
$CONFIG = array (
'memcache.local' => '\\OC\\Memcache\\APCu',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => 'redis',
'port' => 6379,
),
'datadirectory' => '/data',
'instanceid' => 'XXXXXXXXXX',
'passwordsalt' => 'XXXXXXXXXX',
'secret' => 'XXXXXXXXXX',
'trusted_domains' =>
array (
0 => '192.168.0.101:443',
1 => 'nextcloud.MY_DOMAIN.duckdns.org',
),
'dbtype' => 'mysql',
'version' => '23.0.0.10',
'overwrite.cli.url' => 'https://nextcloud.MY_DOMAIN.duckdns.org',
'overwritehost' => 'nextcloud.MY_DOMAIN.duckdns.org',
'overwriteprotocol' => 'https',
'dbname' => 'nextcloud',
'dbhost' => 'nextclouddb',
'dbport' => '',
'dbtableprefix' => 'oc_',
'mysql.utf8mb4' => true,
'dbuser' => 'oc_nextcloud-adm',
'dbpassword' => 'XXXXXXXXXXXXXXXXX',
'installed' => true,
'default_phone_region' => 'COUNTRY_CODE',
'trusted_proxies' =>
array (
0 => '192.168.0.101:443',
1 => 'nextcloud.MY_DOMAIN.duckdns.org',
),
'mail_smtpmode' => 'smtp',
'mail_smtpsecure' => 'tls',
'mail_sendmailmode' => 'smtp',
'mail_smtphost' => 'smtp.gmail.com',
'mail_smtpport' => '587',
'mail_smtpauth' => 1,
'mail_smtpauthtype' => 'LOGIN',
'mail_smtpname' => 'XXXXXXXXXXXXXX',
'mail_smtppassword' => 'XXXXXXXXXXXXXX',
'mail_from_address' => 'XXXXXXXXXXXXXX',
'mail_domain' => 'gmail.com',
);As I said, it works. The only little inconvenience is that internally I'm receiving a certificate error.
When you're going to "myexternalip:443".. is this secured or are you just forwarding ports?
Sorry that was just me being inprecise to depict the port situation. I'm always using the subdomain, both internally and externally.
As I said, it works. The only little inconvenience is that internally I'm receiving a certificate error.
Now I see... I've never set up a cert internally. It always seemed pointless to me since it is only accessed internally (none of my services have internal certs, but all of them have external certs through swag).
As I said, it works. The only little inconvenience is that internally I'm receiving a certificate error.
Ok, it's weird, but a little annoyance nothing more. I'm glad it works.
If you put my_external_name my_internal_ip into you hosts file, you will have the same name fpr nextcloud and hence a valid cert.
No need to weak the nextcloud install at all.
(If you have a local DNS forwarder, you can also put the external name with interal ip into the overides and be happy)
If you put my_external_name my_internal_ip into you hosts file, you will have the same name fpr nextcloud and hence a valid cert.
No need to weak the nextcloud install at all.
That's what I did (the syntax is my_internal_ip my_external_name on Windows, but I guess that's what you mean). The cert is not valid, anyway (when called from the local PC).
If you have a local DNS forwarder, you can also put the external name with interal ip into the overides and be happy)
What do you mean by "local DNS forwarder"? Is it something that my router does? There is no DNS server in my network, I rely on my ISP. The only thing (that I know of) I can adapt is the hosts file (per client).
What do you mean by "local DNS forwarder"? Is it something that my router does? There is no DNS server in my network, I rely on my ISP. The only thing (that I know of) I can adapt is the hosts file (per client).
There are two solutions.
- Modify the client's hosts file. This is what you have done. For it to work you must modify this file on each client.
- Create a DNS server. In this case, all clients will receive the IP configured for that domain.
That's what I did (the syntax is my_internal_ip my_external_name on Windows, but I guess that's what you mean). The cert is not valid, anyway (when called from the local PC).
Can not understand why that is not valid. What reason does the browser show (click the lock)
What do you mean by "local DNS forwarder"? Is it something that my router does? There is no DNS server in my network, I rely on my ISP. The only thing (that I know of) I can adapt is the hosts file (per client).
My gateway has an unbound dns 'server', but PiHole would be perfect for you
Can not understand why that is not valid. What reason does the browser show (click the lock)
The pop-up displays "The certificate is invalid" and then (when clicking "show certificate"):
"This certification authority root certificate is not trusted because it is not in the repository of trusted root certification authorities."
Arn#t you using letsencrypt certs for the internet access?
Arn#t you using letsencrypt certs for the internet access?
This was the right hint. Until now I was bypassing the proxy (=Swag/letsencrypt). Now I changed the Swag port to 443 and it works without cert error both internally and externally!
Thank you Zoki for staying persistent
Now I finally understand this:
You would see the service because it would enter through Swag on port 443.
I just didn't expect Swag to behave differently depending on the port it's running on.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
