Upon further investigation, it seems it was a cache from a rewrite rule that I tried earlier which readInteresting--that error isn't present in my copy. But multi-download still doesn't work.
rewrite /apps* /index.php{uri}
@notlegacy { not path /index* not path /remote* not path /public* not path /cron* not path /core/ajax/update* not path /status* not path /ocs/v1* not path /ocs/v2* not path /ocs-provider/* not path /updater/* not path */richdocumentscode/proxy* } rewrite @notlegacy /index.php{uri}
Was working all weekend and just got back to this tonight. I've gone through the README, investigated the options (implementing pihole), looked at my cloudflare settings, tried adding the IP address into Caddyfile directly. I never implemented pihole and maybe that will resolve it all. But I can't get a DNS record directly to my public IP (in cloudflare DNS settings) to access nextcloud (I forwarded ports 80 and 443 to the internal IP). I'm not completely network savvy and might be able to chase this down. But I was wondering: I read that purchasing a cloudflare license may be an alternative to using a domain name. Is this an easier approach to the goal of getting a secure nextcloud implementation? I think my implementation of cloudflare is the problem here (maybe...). But I know I want it. Thanks again for your help.Editing the Caddyfile to include the IP may work, but it really isn't intended to be used this way, mainly because it'll give you SSL certificate errors. What you should be doing is (once again) described in the README:
And now for some reason when I addOk this block is working for me now. I set the index path differently.
Code:@notlegacy { not path /index* not path /remote* not path /public* not path /cron* not path /core/ajax/update* not path /status* not path /ocs/v1* not path /ocs/v2* not path /ocs-provider/* not path /updater/* not path */richdocumentscode/proxy* } rewrite @notlegacy /index.php{uri}
Uploading still not working though, but I think that might be a bug with the new style of webpage.
EDIT: Every time I think i have it, some wierd caching issue shows i dont. Hopefully this one works now, I tried with cached cleared and incog window. But I still can't get the login window to function. If I remove the index entry, the login works but not the download. If I add it like above, the download works but not the login window
path /apps*
(which it should be rewriting automatically) the login page loads, but some elements are still missing. I'm suspecting Caddy is doing something I don't know about.Not necessarily. A domain can be as cheap as 5 dollars. Then you can add it to Cloudflare for free and point it to your public IP.Was working all weekend and just got back to this tonight. I've gone through the README, investigated the options (implementing pihole), looked at my cloudflare settings, tried adding the IP address into Caddyfile directly. I never implemented pihole and maybe that will resolve it all. But I can't get a DNS record directly to my public IP (in cloudflare DNS settings) to access nextcloud (I forwarded ports 80 and 443 to the internal IP). I'm not completely network savvy and might be able to chase this down. But I was wondering: I read that purchasing a cloudflare license may be an alternative to using a domain name. Is this an easier approach to the goal of getting a secure nextcloud implementation? I think my implementation of cloudflare is the problem here (maybe...). But I know I want it. Thanks again for your help.
This fix actually does work for me now. I tired of messing with the Caddyfile. I just can't get both the login page and the download to function properly. The reason it didn't work before was because of a typo in the file that I have no idea how it got there. So...The "temporary fix" suggested by kunago in this thread works for me... https://github.com/nextcloud/server/issues/42617
If anyone else is interested to try it out, it's this file : /mnt/YOURPOOL/iocage/jails/nextcloud/root/usr/local/www/nextcloud/apps/files/ajax/download.php
And I placed the lines at the top like this : (restart does not seem to be necessary)
<?php
$vendorDir = dirname(__DIR__);
$baseDir = dirname(dirname($vendorDir));
include_once $baseDir . '/lib/base.php';
include_once $baseDir . '/lib/private/legacy/OC_Util.php';
/**
* @copyright Copyright (c) 2016, ownCloud, Inc.
*
Thanks for this! I inserted this code into download.php. Now I can access the login page by http://192.168.86.200/login. It is an unsecure connection. But the login screen just hangs (endless circle going around) using the default admin login setup by the original installation script. I still can't get my domain name to point to the login page (I did verify that cloudflare is pointing to the right public IP by changing ports 80/443 to go to the truenas internal IP address, where it successfully went to the truenas login screen). Does anyone have any ideas why the nextcloud login screen is hanging?This fix actually does work for me now. I tired of messing with the Caddyfile. I just can't get both the login page and the download to function properly. The reason it didn't work before was because of a typo in the file that I have no idea how it got there. So...
THIS WORKS as of now.
That was a reply to another discussion we were having. It's unrelated to you issue.Thanks for this! I inserted this code into download.php. Now I can access the login page by http://192.168.86.200/login. It is an unsecure connection. But the login screen just hangs (endless circle going around) using the default admin login setup by the original installation script. I still can't get my domain name to point to the login page (I did verify that cloudflare is pointing to the right public IP by changing ports 80/443 to go to the truenas internal IP address, where it successfully went to the truenas login screen). Does anyone have any ideas why the nextcloud login screen is hanging?
Secondly, is there any way to just deactivate DNS_PLUGIN or Caddyfile so I can troubleshoot it? I just want a nextcloud configuration that works right now, then implement the security.
@notlegacy { path *.php not path /index* not path /remote* not path /public* not path /cron* not path /core/ajax/update* not path /status* not path /ocs/v1* not path /ocs/v2* not path /ocs-provider/* not path /updater/* not path */richdocumentscode/proxy* } rewrite @notlegacy /index.php{uri}
path *.php
because according to the Nextcloud docs, the files need to end in .php
Ok, just so I have this right: At the very beginning of Caddyfile, inserting a line 1, I put ":80" (but with no quote marks). And in the config.php file, where currently "'trusted=domain' => " points to nothing, I need to put '192.168.86.200' to the right of the "=>".That was a reply to another discussion we were having. It's unrelated to you issue.
As for your issue, you can comment out # the tls block, and change the beginning of the Caddyfile to read :80
You will also need to edit /usr/local/www/nextcloud/config/config.php and set your "trusted_domain" to your IP address you will be using to connect.
Then you will be able to access via your IP
Can you share your config file and Caddyfile and remove your domain and sensitive values?Ok, just so I have this right: At the very beginning, on line 1, I put ":80" (but with no quote marks). And in the config.php file, where currently "'trusted=domain' => " points to nothing, I need to put '192.168.86.200' to the right of the "=>".
Do I have this right?
Can you give this a shot?
Thanks for your assistance! I've attached txt files of both documents. I'm not sure what changed, but I can't access the login screen anymore.Can you share your config file and Caddyfile and remove your domain and sensitive values?
<?php $CONFIG = array ( 'passwordsalt' => 'XXXX', 'secret' => 'XXXX', 'trusted_domains' => array ( 0 => 'localhost', 1 => 'www.XXXX.com', 2 => '192.168.86.200', ), 'datadirectory' => '/mnt/files', 'dbtype' => 'mysql', 'version' => '28.0.3.2', 'overwrite.cli.url' => 'http://192.168.86.200/', 'dbname' => 'nextcloud', 'dbhost' => 'localhost:/var/run/mysql/mysql.sock', 'dbport' => '', 'dbtableprefix' => 'oc_', 'mysql.utf8mb4' => true, 'dbuser' => 'nextcloud', 'dbpassword' => 'XXXX', 'installed' => true, 'instanceid' => 'XXXX', 'logtimezone' => 'America/Chicago', 'default_phone_region' => 'US', 'log_type' => 'file', 'logfile' => '/var/log/nextcloud/nextcloud.log', 'loglevel' => '2', 'logrotate_size' => '104847600', 'memcache.local' => '\\OC\\Memcache\\APCu', 'redis' => array ( 'host' => '/var/run/redis/redis.sock', 'port' => 0, ), 'memcache.distributed' => '\\OC\\Memcache\\Redis', 'memcache.locking' => '\\OC\\Memcache\\Redis', 'overwritehost' => '192.168.86.200', 'overwriteprotocol' => 'http', 'htaccess.RewriteBase' => '/', 'trusted_proxies' => array ( 1 => 'localhost', ), 'maintenance_window_start' => 5, );
{ # debug acme_ca https://acme-staging-v02.api.letsencrypt.org/directory email XXXX@gmail.com # default_sni www.XXXX.com } :80 { root * /usr/local/www/nextcloud file_server log { output file /var/log/www.XXXX.com.log } php_fastcgi 127.0.0.1:9000 { env front_controller_active true } # tls { # dns cloudflare XXXX # } header { # enable HSTS # Strict-Transport-Security max-age=31536000; } # client support (e.g. os x calendar / contacts) redir /.well-known/carddav /remote.php/dav 301 redir /.well-known/caldav /remote.php/dav 301 redir /.well-known/webfinger /index.php/.well-known/webfinger 301 redir /.well-known/nodeinfo /index.php/.well-known/nodeinfo 301 # .htaccess / data / config / ... shouldn't be accessible from outside @forbidden { path /.htaccess path /data/* path /config/* path /db_structure path /.xml path /README path /3rdparty/* path /lib/* path /templates/* path /occ path /console.php } respond @forbidden 404 }
The reason it redirect to your local IP is because you have the overwrite_host option set to that.Thanks so much @victort ! Here's where it stands now: I can log in locally (192.168.86.200/login). Edge & Firefox work fine. Chrome is touchy about it, it doesn't always work. But the good news is that I can log in locally.
When I type in my public IP in the browser address bar, it does go to a login screen. The admin login successfully logins, then the internal IP address is then shown in the address bar. I'm guessing this is what it's supposed to do?
So now, I'm trying to assess the issue of secure access. I would like this to be a true cloud server with full protection. I'm a little discouraged that I haven't successfully been able to get the security set up.
May I ask your (and anyone else's, really): Is there any possibility that I WON'T be able to get this installation running securely with some more troubleshooting? I.e. Maybe I should start from scratch. The reason I ask is that if there's a good possibility, I will just do that now. If there's a good chance that with some cloudflare, DNS plugin, and internal-DNS-hosting troubleshooting work I can get this to function correctly, I'll keep working it.
Many thanks again.![]()
Works for me to!
- Login page looks fine
- I'm able to log in
- When I check multiple files and click the "Download" button, a .zip file downloads which contains those files
- Uploading multiple files via drag-and-drop also seems to work.
Are you dragging and dropping a folder or files? And are you dragging them into a folder, or into the box on top that says "Drag and Drop Files Here to Upload"?Works for me to!
And surprisingly, the upload of multiple files works as well !!
Yepp, previously only the first of multiple files would upload. Now all files that I drop end up being uploaded.Are you dragging and dropping a folder or files?