SNAP Installation change php, apache and nextcloud configs


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:

  1. Where is the apache conf and how restart apache?
  2. Where is the php.conf and how restart php service?
  3. Where is the nextcloud conf and how restart nextcloud?
  4. Where is the www root folder to add some other html/php files?

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.

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:

  1. /snap/nextcoud/current/conf/httpd.conf.
    You can restart the Apache server using snapd's tooling:
    sudo snap restart nextcloud.apache
  2. /snap/nextcloud/current/config/php/php.ini
    There isn’t a php daemon as such in this configuration - looks like it is run per-request, so you wouldn’t even need to restart Apache to apply any changes. Just reload/refresh the page.
  3. /snap/nextcloud/current/htdocs/config/config.php
    Nextcloud doesn’t have a daemon at all, it’s all just php. See above.
  4. /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.

1 Like

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 (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 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.

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:

  • If you have not set the ‘trusted_proxies’ directive to match your reverse proxy IP, or if your reverse proxy does not send the ‘X-Forwarded-For’ header with the client’s IP. In these cases, Nextcloud can’t always tell it’s behind a reverse proxy - it will think it’s being accessed directly via its IP address all the time, so it will redirect you to nextcloud.mydomain.tld even if that’s where you’re already going.
  • If you have set the ‘overwritecondaddr’ config directive, that could be the culprit. It’s included in the example in the reverse proxy docs you linked, but it’s optional. If you’re not sure what it does, you probably don’t need it.

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 (, and you’d just change port numbers.

Nextcloud's config.php
$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' => '/',
Nextcloud container's Apache cfg
<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

           # 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]


        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
Reverse proxy container's Apache cfg
<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"

        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


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:


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 80
Connection received on 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-Host: mynextcloud.mydomain.tld
X-Forwarded-Host: mynextcloud.mydomain.tld
X-Forwarded-Proto: https
Connection: close

Where: 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 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 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: (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): 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, 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" => "" ) ) )

      $SERVER["socket"] == ":443" {
         ssl.engine              = "enable"             = "/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.

1 Like

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

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.

1 Like

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 :slight_smile: