Hello,
I Installed nextCloud with SNAP and all is really running fine. Great software.
But when I try to made some minor changes on apache, php or nextcloud config ⌠I don´t finde the files.
So please has someone the answer for:
Thank you!
Hello! Always glad to see people wanting to tinker with Nextcloud, but youâll probably need to switch from the snap to a more traditional install if you want to dig into it. If youâre looking at running non-Nextcloud things along-side an unmodified Nextcloud, then adding a âreverse proxyâ to your setup might be your thing.
Why?
Snaps are designed to have a limited interface for configuration (here is Nextcloudâs). Powerful (and easily misconfigured) conf files are set up in a way that works best for the most users , and are a read-only part of the snap image.
Edit: See the responses from @kyrofa and @PritishSehzpaul below. The snap is designed so that the Nextcloud config file can be edited, after all. You can also modify the snap itself (to change Apache options, for example), but running a VM or a manually configured container is probably better for this purpose.
What can I do without complicating things?
For most uses, youâll be able to do what you need using the above snap interface (for example, configuring trusted names and SSL). If youâre looking at adding custom HTML pages (not Nextcloud apps?), you might need a bit more configurable of a solution. Two options below.
I might want to play around with Nextcloudâs more advanced options. How?
If youâre on the fence about switching to classic install, have a look at the article âSnap or VM?â in the that same wiki. If youâre sure you want to switch, you can check out the install script in the VM repo, or manually install on the server of your choice (docs).
I really just want to be able to run another webapp or serve static files on the same server. What do I need?
Youâll need to set up another web server process (Apache, nginx, etc) outside the snap. It can be on the host server, inside a VM, or anywhere else that can reach your Nextcloud snap and be reached by your end users. You can modify php parameters and everything else you need for your other app(s) separately, then have that web server act as a reverse proxy to forward Nextcloud requests through to your Nextcloud snap.
There are lots of tutorials about reverse proxy setup, but hereâs a quick one from DigitalOcean: Use Apache as Reverse Proxy using mod_proxy. Note: You can substitute apt where they use aptitude- it does the same thing for those commands, and is installed by default on recent Ubuntu.
If your reverse proxy is running on the same host/IP address as your Nextcloud snap, youâll probably have to change Nextcloudâs port numbers to avoid a conflict. Hereâs the documentation on how to do that in the snap.
You can find example configuration files for your reverse proxy web server in this post by @KarlF12, or in my post below.
Answers to those specific questions
Theyâre all read-only, but hereâs where things live:
/snap/nextcoud/current/conf/httpd.conf.snapd's tooling:sudo snap restart nextcloud.apache
/snap/nextcloud/current/config/php/php.ini/snap/nextcloud/current/htdocs/config/config.php/snap/nextcloud/current/htdocs/Sorry for reviving an old thread. Just wanted to mention that this config is read-only, yes, but itâs only there to be installed by the snap in a read/write place, which is in /var/snap/nextcloud/current/nextcloud/config/config.php. That config is editable (Nextcloud with a read-only config is indeed quite limited).
More information is available in the Configuration section of the README.
previewgenerator need
Important : To enable pre-generation of previews you must add php /var/www/nextcloud/occ preview:pre-generate to a system cron job that runs at times of your choosing.
how to active it under snap please?
I know this is probably late and I havenât tried it yet but this could be useful.
The above article states how to open the snap in a writable mode.
Alas things are no so simple. I just installed Ubuntu 20.04 Server with the Nextcloud option.
On the up side, it worked smoothly and Nextcloud is running fine and dandy.
On the downside, itâs fine and dandy but not complete. Various things are just plain broke and all the searching on-line finds solutions for a non snap installation. Aaargh. I even checked with apt and there is no non snap install offered in the Ubuntu 20 apt repos at all! So itâs not even a trivial option.
Given snap is a âthingâ I guess itâs worth upskilling a little. Still itâs frustrating that even snap info on-line is wildly inconsistent and contradictory.
The tips here are a case in point. I love the summary @mactrent wrote, and yet nothing under /snap/nextcloud/current is writable on my system. Moreover the mechanism of the write protection is mysterious as all heck as âls -lâ suggests fine and also with sudo or even logged in a root, no can write.
Which leaves the question, how to tweak Apache settings for example. I for installed as above, and then I tested and I can access it via http://192.168.0.14 (where the servers sit on my LAN), I can access it via http://nextcloud.lan (where thatâs a LAN resolved name) and I can access it via http://nextcloud.mydomain.tld (which is the global name that resolves to my server).
All good.
I am BTW replacing an existing NextCloudPi install with this one and so the context is stable and long defined and the Nexcloud server sits behind a reverse proxy on an OpenWRT router.
So then I enable SSL:
sudo nextcloud.enable-https lets-encrypt
Now it works fine with https://192.168.0.14 and it works fine with https://nextcloud.lan but https://nextcloud.mydomain.tld produces a 301 redirect to ⌠wait for it ⌠https://nextcloud.mydomain.tld âŚ
How, why? Nothing in the logs. A load of unrelated errors in the logs (related to spreed and ResourceLocator) leaving one with a sour taste regarding the integrity of snap installed Nextcloud ⌠egads, but we digress (and can solve those later), because there is NOTHING in logs about this redirect.
So: sudo snap set nextcloud mode=debug and still nothing in the logs reported by: sudo nextcloud.occ log:.
So: sudo nextcloud.occ config:system:set loglevel --value=0 and still nothing reported when I reload https://nextcloud.mydomain.tld.
Apache is redirecting back to itself is my gut feel. But it is night impossible to diagnose.
So I find this:
in which I see clues but man itâs not lucid, not can I see an Apache access and debug log that shows how itâs evaluating rules ⌠nor can I find a way to configure it.
Itâs danged annoying and Iâm on edge of tossing it all, and going back to NexcloudPi which while sluggish and crashing a fair bit is configurable and has diagnostics.
The big question is why would Nextcloud redirect to itself in an endless loop when the request comes in via a reverse proxy. Itâs not the gateway router (reverse proxy) thatâs doing the redirect, it is OpenWRT fully configurable and diagnosable and itâs easy to test empirically, by shutting down Nextcloud (the 301 endless loop changes to 503 Service Unavailable. In short the Reverse porxy is trying to forward the request and getting no response.
What Iâd give to be able to configure Apache to produce solid diagnostics here.
@Bernd_Wechner
Just in to be sure, have you followed PritishSehzpaulâs link to make the snap writable? Iâd be interested to hear back if that didnât do the trick.
A couple of easy mistakes that might cause this:
Thereâs some additional documentation specifically for using the snap behind a reverse proxy. It includes an nginx example you can work off of to make your apache reverse proxy config. You can also refer to mine below, if that helps.
Iâm using LXC containers rather than Snaps in my setup, but it should still be helpful for reference. Iâve anonymized domains and IPs (nextcloud.mydomain.tld, nextcloud.lan, nextcloud_direct_ip, reverse_proxy_ip). If following the snap reverse proxy docs linked above, I guess all the IPs would be localhost (127.0.0.1), and youâd just change port numbers.
$CONFIG = array (
'trusted_domains' => array (
0 => 'nextcloud.mydomain.tld',
1 => 'nextcloud.lan'
),
'trusted_proxies' => array (
0 => 'reverse_proxy_ip',
),
'overwrite.cli.url' => 'https://nextcloud.mydomain.tld/',
'overwriteprotocol' => 'https',
'overwritewebroot' => '/',
'htaccess.RewriteBase' => '/',
[...]
)
<VirtualHost *:80>
ServerName nextcloud.mydomain.tld
ServerAdmin webmaster@mydomain.tld
# Might be different in snap
DocumentRoot /var/www/nextcloud
RemoteIPHeader X-Forwarded-For
RemoteIPInternalProxy reverse_proxy_ip
<Directory /var/www/nextcloud/>
Require all granted
Options FollowSymlinks MultiViews
AllowOverride All
<IfModule mod_dav.c>
Dav off
</IfModule>
# Might be unnecessary in the snap
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
RewriteRule ^\.well-known/webfinger /public.php?service=webfinger [QSA,L]
RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
</IfModule>
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<VirtualHost *:443>
ServerName nextcloud.mydomain.tld
ProxyPreserveHost On
SSLProxyEngine on
SSLProxyVerify none
SSLProxyCheckPeerCN off
SSLProxyCheckPeerName off
SSLProxyCheckPeerExpire off
# Leave this part out until you're sure TLS is working properly
#<IfModule mod_headers.c>
# Header always set Strict-Transport-Security "max-age=15768000; preload"
#</IfModule>
ProxyPass / http://nextcloud_direct_ip/
ProxyPassReverse / http://nextcloud_direct_ip/
# TLS certs from letsencrypt/certbot, replace with your own paths
Include /etc/letsencrypt/options-ssl-apache.conf
SSLCertificateFile /etc/letsencrypt/live/nextcloud.mydomain.tld/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/nextcloud.mydomain.tld/privkey.pem
</VirtualHost>
Thanks for the thoughts! Did some more reading, tried a few things based on your examples. But still frustrated.
No Iâve not tried making the snap writeable yet. The instructions seem unclear as to how to do this while parking the current snap or making the current snap temporarily writeable. Itâs not clear to me for example, could I back up:
/var/snap/nextcloud/current/nextcloud/config/config.php
then install writeable snap and just use that backup config,phpo to configure it identically again. Said another way is the entire config for the snap stored in that one file?
Puzzling to me is that whenever I restart the snap that file is respected but totally reformatted and comments removed. Some weird stuff happening under the hood that I wish I understood.
I did stop the snap and use:
sudo nc -vlnp 80
to watch incoming request while I reloaded the WAN URL and surprisingly got something. Srprising because I load https://mynexcloud.mydomain.tld, an https URL in Google Chrome. I expect that to arrive on port 443 only.
So I tried a repeat with:
sudo nc -vlnp 443
and that also sees a request but most of it garbled binary alas. Have yet to work out if I can coax netcat to show me the SSL decrypted request (more reading). On port 80 I see this though:
Listening on 0.0.0.0 80
Connection received on 192.168.0.1 38460
GET / HTTP/1.0
Host: mynextcloud.mydomain.tld
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.125 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: cross-site
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,eo;q=0.8,de;q=0.7
Cookie: oc_sessionPassphrase=E02VsLm8tsyY8MmByWnwEfa9PCojutVgmnHZa5twStfup5GWIMg7vaEXtYCs3uBWGgAGupSTWysN3Ij3VY3gprzxSH7vrIva2oi8INtgzlSbQ5hCQM3eL6h8T3G5%2FIX7; __Host-nc_sameSiteCookielax=true; oc3xiwqouz8h=tf85gngrijg5mh3hb6pqo93ig1
X-Forwarded-For: 192.168.0.11
X-Host: mynextcloud.mydomain.tld
X-Forwarded-Host: mynextcloud.mydomain.tld
X-Forwarded-Proto: https
Connection: close
Where:
192.168.0.11 is the IP of my desktop on the LAN that Iâm working on and do the request from. Interesting that it comes through as itâs a WAN request
192.168.0.1 is the reverse proxy.
https://mynextcloud.mydomain.tld is the URL I am fetching and which is redirceting back to that exact same address with a 301.
I donât have overwritecondaddr set in config.php.
I am curious in your example is reverse_proxy_ip the LAN IP or the WAN IP of the reverse proxy? I have set it to the LAN IP, the WAN IP is trickier as itâs variable and I use DDNS.
So tried socat to listen to the SSL traffic but it is broken and doesnât work failing with:
2020/08/19 11:10:45 socat[288019] E SSL_CTX_use_certificate_file(): error:02001002:system library:fopen:No such file or directory
so fetched the latest ncat from the nap website which supports SSL (Ubuntu 20.04 native ncat doesnât) but it doesnât detect anything which bizarre, running:
sudo ncat --listen --ssl --ssl-cert ~/combined.pem --ssl-key ~/combined.pem
and reloading the WAN https: URL shows no output at all. I have the key and cert in one .pem file.
My guess is that the snap includes a validator, which parses the config settings and writes the file again to apply any changes it might (or might not) make.
Mine is also set to the reverse proxyâs LAN IP, which would be 192.168.0.1 in your case.
Your reverse proxy is listening on port 443, so thatâs where the initial HTTPS connection requests (Request A) go. The proxy forwards each request to the Nextcloud snap via the URL we gave in the ProxyPass directive: http://192.168.0.14/ (Request B).
My containerâs Apache expects connections on port 80, and answers directly.
The snapâs Apache configaration might just respond to all requests on port 80 (HTTP) with a redirect to port 443 (HTTPS). The client obediently opens a new request to port 443, which the reverse proxy forwards again to port 80, and weâve got a loop.
Instead, youâll need to change the ProxyPass URL to Nextcloudâs HTTPS port (443 by default): https://192.168.0.14/. The snap doesnât have a valid SSL certificate, but thatâs why we have the SSLProxyCheck options off in the reverse proxyâs config.
Edit: I misread the nc log, and thought Nextcloud was on the same box. Also, diagrams.net is the best.
What do you mean by this directive? Not familiar to me.
Itâs a line you put in your reverse proxyâs configuration (usually followed by a ProxyPassReverse line with the same options). It tells Apache what path it should listen on as a proxy, and then what URL it should forward matching requests to.
You can see where I use these directives in my reverse proxy Apache configuration above. Official Apache docs here.
@mactrent wrote a great summary, and explicitly stated that /snap/nextcloud/current is read-only. Itâs read only because itâs a squashfs image (think a macOS disk image, if youâve ever used those), which is why it looks like you SHOULD be able to write to it, but the image doesnât support that.
Quite simply: you canât. By design.
Note that unpacking the squashfs image will indeed make it writable and it can be helpful to develop and debug, but itâs very much not a supported production way to run the snap.
Thatâs just Nextcloud. It happens regardless of how you have it installed (snap, traditional, whatever). The config file is a PHP file that it loads and then rewrites.
Sounds like your reverse proxy isnât setup properly. Youâre listening on 443, but forwarding to port 80, where the snap says âHey, I have HTTPS enabled, letâs redirect there insteadâ which causes a loop. Your reverse proxy should be proxying port 80 to port 80, and 443 to 443, assuming you want the snap handling your HTTPS certs. The only time when proxying port 443 to port 80 makes sense is if you use your reverse proxy as the SSL terminator (i.e. have it handle your HTTPS certs) and donât enable HTTPS on the snap at all.
Thanks again for all the learning opportities here. Itâs been a voyage indeed. I have abandoned snap and opted to go with basic install, install lighttpd, postgresql, PHP then the standard latest Nextcloud. Works a charm and aside from being time consuming and involving a pile of steps (which the snap saves us) The minute there was a hiccup I did and could log whatever I need in lighttpd logs, PHP logs and fix it quickly and move on and the snap doesnât make any of that possible thanks to read only configs. Further up side is I could use the web server and database that all my other servers run and that I have some modicum of familiarity and skills with and the toolsets all at hand.
I have on this journey learned a lot about snap, about squashfs (and I can see how the current image is just such):
$ mount | grep nextcloud
/var/lib/snapd/snaps/nextcloud_22653.snap on /snap/nextcloud/22653 type squashfs (ro,nodev,relatime,x-gdu.hide)
I emerge with minor gripe against the kernel, wishing for a mounted RO FS that iut would drop teh r bit on file permissions so that ls -l and any other query can see clearly that the file is âeffectivelyâ read only, with the FS propertyrtrumping the file property. Not least because of the nice (yet insidious) way in which filesystems can be mounted to integrate transparently with the root filesystem.
If I had a counsel to the Nextcloud snap maintenance team it would be to make Apache, MySQL and PHP configs configurable, which is easy enough with a union mount methinks or some other implementation, for fine tuning.
Re: reverse proxy, I am still not 100% sure what was going on, but for the record I use lighttpd across the board and the reverse proxy config is simple:
# The Nextcloud cloud server
$HTTP["host"] == "nextcloud.mydomain.tld" {
proxy.server = ( "" => ( ( "host" => "192.168.0.14" ) ) )
$SERVER["socket"] == ":443" {
ssl.engine = "enable"
ssl.ca-file = "/etc/letsencrypt/live/nextcloud.mydomain.tld/chain.pem"
ssl.pemfile = "/etc/letsencrypt/live/nextcloud.mydomain.tld/combined.pem"
ssl.honor-cipher-order = "enable"
ssl.use-sslv2 = "disable"
ssl.use-sslv3 = "disable"
}
}
which is a request to pass everything through, so I expect a 443 incoming to go to 443 on the LAN server and 80 to 80. Of course my expectation and what lighttpd does are not guaranteed to align.
There is a config I insert to redirect 80 to 443:
$HTTP["scheme"] == "http" {
url.redirect = ("" => "https://${url.authority}${url.path}${qsa}")
}
And interestingly if I do that on the reverse proxy (above) all is well. But if I do it on the LAN server I get a redirect loop but I see no easy explanation for that and it would take some research into lightpd functioning. But thatâs all possible on a system where you can play with the configs. It does suggest that https arrived at reverse proxy is forward to http at LAN server which redirects to https with FQDN, which reaches reverse proxy which forwards it again as http.
Which is not what Iâd infer from the lighttpd config. But then yes, I donât expect lighttpd support from Nextcloud (who provide Apache solutions). Thatâs something I an pursue on the lighttpd forums if needed. Empirically it seem clear whatâs happening and the main thing is with a writable install it was possible to diagnose with details server side logging enabled.
Bernd, i dont know if u discovered this already but the nature of the snap is that it cant be made write enable, all snap packages are read-only once mounted, i strugle with that a long time ago, the only solution to write into the config of a snap package is to download the snap package itself, uncompress it, modify the things u want to modify then compress it again and then mount it, u can find some info in here https://github.com/nextcloud/nextcloud-snap/wiki/Installing-the-snap-in-writable-mode.
I decided to go for a normal installation because of that, i needed to integrate nextcloud users to a zimbra mail server i had back then and i needed to edit some configs in the nextcloud snap, so it was better for me to just use a normal installation, cause if u decide to go for the snap thingy and uncompress it, then everytime u needed to do an upgrade u would of had to follow the same procedure and edit whatever files u edited previusly all over again, of course u could script it, but it was more of a pain in the ars and not worth it, its just better to use a normal install for custom modifications like the ones u and i needed to have hehe.
A clarification for future readers: this does not apply to Nextcloudâs configuration (a read-only Nextcloud config would make it pretty useless). It applies to dependencies like PHP, or the web server, which are intended to be implementation details in the snap.
Yes that is true, i forgot to add that as well, it was pretty late when i wrote that replay hahaha 