In 2016, the self-hosted community witnessed the public launch of Nextcloud, a vastly-improved fork of ownCloud. Having almost finished migrating data on my home server to Nextcloud and experimenting with some of the more optional features such as caching, pretty links, theming and more, I felt it would be a good time to document some of this in one simple-to-follow guide.
1. What is Nextcloud?
As mentioned above Nextcloud is a fork of ownCloud that has becoming the better and faster-developed alternative to the self-hosted cloud storage software of old. If you’re an ownCloud user and have ever been frustrated by the dual licenses, the paid vs free model and – as part of it – lack of some of the better features, Nextcloud have gone completely FOSS (Free and Open-Source Software) following the Red Hat model of charging for enterprise support rather than enterprise features.
Some of the previously enterprise-only features released as part of the standard FOSS Nextcloud installation include FileDrop, an alternative to Dropbox’s “File Requests”, LibreOffice online (Collabora), an alternative to Google Docs or Office Online, two-factor authentication, improved federation and more.
2. In this guide
After completing this guide we’ll have the following:
- A newly installed Nextcloud server
- PHP caching provided by ACPu and Redis for a notable speed increase when navigating even the largest thumbnail-heavy folders
- Pretty links that remove /index.php from the URL
- SSL-enabled with default self-signed certificates and all non-HTTPS traffic redirected
2.1. Installation URL
This guide assumes Nextcloud will be accessed via url.com/nextcloud. If Nextcloud should be accessed on the root of the domain, url.com, keep in mind the following:
- Any
vhostentries in Apache configs referring to the directory path/var/www/htmlshould be changed to/var/www/html/nextcloud - The Nextcloud
config.phpbase URL should be changed from'/nextcloud'to'/' - Lets Encrypt will work, however the
.well-knowndirectory will need to be moved out and back in to thenextclouddirectory before and after an upgrade respectively to avoid an integrity check error.
3. Environment
For this guide Nextcloud will be installed on a remote Ubuntu VM, however it can equally be installed on a local Ubuntu server, a Raspberry Pi or a Linux Container such as Docker or LXD.
3.1. Hardware
Nextcloud don’t provide a lot of detail for minimum recommended spec, only advising 512MB of RAM. As the server is a full VM and not simply a container, we’ll provide a bit of a buffer to avoid any possible contention.
- 1GHz CPU
- 1GB RAM
- 20GB HDD
20GB of disk will be enough for this guide, but naturally the amount chosen should reflect the amount of data to be stored. Furthermore, if redundancy isn’t offered as standard it’s always a good idea to mirror/RAID the storage area to avoid downtime as best as possible. Typically this is only a consideration required with dedicated servers, but there’s no harm in checking.
3.1.1. Plan backups
No matter what level of redundancy is set up, it’s not a replacement for a good backup strategy. Never assume data is safe in a remote datacentre as usually providers offer no liability or responsibility for lost data should a server fail.
3.1.2. Nextcloud is not a backup solution
Nextcloud is a not a replacement for typical backup solutions or processes but rather a tool for collaboration and sharing. Do not rely on it as the sole solution for protecting your data.
3.2. Software
- Ubuntu server (LTS preferred) with root (sudo) access
- Apache2
- PHP 7
- mySQL / MariaDB
- The latest version of Nextcloud (this guide has been tested as far back as v.9 however)
Besides the above-mentioned packages and their respective dependencies, we should aim to keep the amount of additional software installed to a minimum; the Ubuntu-minimal image is a good place to start here as it requires adding packages after installation rather than sifting through and removing those that aren’t required. From a security perspective this is advised in order to lower to attack surface should an exploit allow a 3rd party to gain shell access to the server – the fewer additional services an attacker can latch onto, the lower the chance of gaining root and doing any real damage. In this case, the VPS provider offers a relatively minimal install, meaning there’s no requirement to upload an Ubuntu-minimal ISO to install from.
Due to the advanced requirements in this guide, root/sudo access to the Ubuntu instance is mandatory.
4. Setting up the environment
For those with a functioning Ubuntu server and required components, please skip to step 4.1.
First we need to spin up a VM or container, examples of which are as follows:
Once the server is setup and we’re logged in, we can continue.
4.1. Update the server & install LAMP, APCu, Redis
As this is a brand new installation based on images that likely don’t update very often, it’s a good idea to upgrade the server before we begin:
sudo apt update && sudo apt upgrade
When the update has completed, it’ll provide a list of packages to be upgraded. Providing we’re happy with what we see, tap Enter.
With the server updated, if one doesn’t already exist, a non-root user should be created with sudo privileges and the root account should disabled, once complete we’ll now install the required components for Nextcloud:
sudo apt install lamp-server^
4.1.1. Meta packages
The use of ^ (caret) in the package name is important. It suggests that the installed package is a ‘meta-package’, meaning a number of programs that are usually installed together.
This command will install Apache, MySQL and PHP along with several PHP/Apache modules to ensure seamless collaboration between the packages. Once happy with the package selection to be installed, tap Enter.
MySQL will request a root user password. Ensure this is strong and keep the password safe; losing it can cause all manner of issues.
Once installed, we’ll now install APCu and Redis:
sudo apt install php-apcu redis-server php-redis
Confirm the packages to be installed match expectations and hit Enter.
Finally, we’ll install the minimal Nextcloud PHP modules required not to error during installation (more can be enabled later):
sudo apt install php-zip php-dompdf php-xml php-mbstring php-gd php-curl unzip
And enable a few apache modules to support our configuration:
sudo a2enmod rewrite headers env dir mime
Now we’ll restart Apache:
sudo service apache2 restart
Before moving on check via a browser that Apache is up and running
4.2. Enable SSL
With the server currently running over HTTP port 80, we can now additionally configure SSL to ensure the Nextcloud installation is secure.
4.2.1. Let’s Encrypt
Let’s Encrypt offers completely free SSL certificates for securing websites. The client is entirely command line based offering simple setup and automated renewal via cron.
First, choose a location (such as /home/user/), download the Let’s Encrypt client and set it as executable:
sudo wget https://dl.eff.org/certbot-auto && sudo chmod a+x certbot-auto
Next, run the client:
sudo ./certbot-auto --apache --agree-tos --rsa-key-size 4096 --email user@domain.org --redirect -d nc.domain.org
Where:
--apache uses the Apache plugin to fully setup and integrate with the existing Apache configuration
--agree-tos simply pre-agrees to the TOS, preventing it popping up during installation
--rsa-key-size defines the length (and therefore security) of the RSA key. Default is 2048.
--email is the email address to register against the certificate (used for reminders by Let’s Encrypt)
--redirect will create both the SSL virtualhost configuration file and add a redirect for HTTP traffic to HTTPs (80 to 443)
-d is the domain to secure
On first run the Let’s Encrypt certbot will install all required dependencies (following approval), however with the added flags above, will not require any further input to set everything up.
Navigating now to the domain allocated to the server will show an SSL-enabled website! If the browser complains the site is not fully protected at this point, it’s due to the default Apache landing page requesting content over HTTP and not an issue with the certificate.
That’s all there is to it. Let’s Encrypt handles everything from certificate generation to Apache configuration, meaning nothing needs to be done beyond what’s documented above. The manual process (below) is far more involved.
One step from the manual process which is recommended is to add the following snippet to the Let’s Encrypt-created vhost.conf file in the same way as is documented in 4.2.2 below:
<Directory /var/www/html/>
Options +FollowSymlinks
AllowOverride All
<IfModule mod_dav.c>
Dav off
</IfModule>
SetEnv HOME /var/www/html
SetEnv HTTP_HOME /var/www/html
</Directory>
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15768000; preload"
</IfModule>
The text above may be pasted under the ServerName line in the file located at:
/etc/apache2/sites-available/000-default-le-ssl.conf
As the certificate currently expires after 90 days by default, to automatically renew the certificate let’s create a cronjob:
sudo crontab -e
This will open the crontab file for the root user (as sudo was used) meaning sudo (and as such, password authentication) won’t need to be used when running the renew command. Add the following line to the crontab file:
0 0 * * 0 /home/jason/certbot-auto renew
Edit the area in bold, then Ctrl + X to quit followed by Y to save the file.
Skip 4.2.2 and continue to Installing Nextcloud.
4.2.2. Manual
We’ll begin by enabling the SSL module for Apache:
sudo a2enmod ssl
Apache sets up self-signed certificates as part of the installation, so for this guide we’ll use those. They can be replaced at any time with functioning 3rd party certificates by editing the vhost file we’ll create next. It’s highly recommended they’re switched sooner rather than later.
sudo vim /etc/apache2/sites-available/nextcloud.conf
Insert the following (all items in bold can be changed to suit the environment):
<IfModule mod_ssl.c>
<VirtualHost _default_:443>
ServerAdmin you@domain.org
ServerName nc.domain.org
DocumentRoot /var/www/html
<Directory /var/www/html/>
Options +FollowSymlinks
AllowOverride All
<IfModule mod_dav.c>
Dav off
</IfModule>
SetEnv HOME /var/www/html
SetEnv HTTP_HOME /var/www/html
</Directory>
<IfModule mod_headers.c>
Header always set Strict-Transport-Security "max-age=15768000; preload"
</IfModule>
SSLEngine on
SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
</VirtualHost>
</IfModule>
Save and quit, then enable the new configuration:
sudo a2ensite nextcloud.conf
Now restart Apache:
sudo service apache2 restart
SSL should now be enabled, allowing us to navigate to https://nc.bayton.org when we install Nextcloud later. Of course the page will show an error as the certificates are not trusted. Let’s Encrypt offer free SSL certificates and Mozilla offer a tool to help correctly set up SSL on the server. Check them out for more information.
Optionally, we can also force a redirect from non-SSL to SSL with the following:
sudo vim /etc/apache2/sites-available/nc-redir.conf
Insert the following (all items in bold can be changed to suit the environment):
<VirtualHost *:80>
ServerName nc.domain.org
ServerAdmin you@domain.org
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
</VirtualHost>
Save and quit, then enable the new configuration:
sudo a2ensite nc-redir.conf
Then disable the default configuration:
sudo a2dissite 000-default.conf
Then restart Apache:
sudo service apache2 restart
With that, all traffic will be forced to HTTPS.
5. Install Nextcloud
With the server environment ready (excluding some final NC-related configurations) we’ll move on to installing Nextcloud itself.
5.1. Download Nextcloud
Change to the webroot directory at /var/www/html with cd /var/www/html
Download Nextcloud via command line with sudo wget https://download.nextcloud.com/server/releases/latest.zip
NB: future and previous versions can be obtained from Nextcloud.
Unpack the compressed zip with sudo unzip latest.zip
As shown above with ls there’s now a nextcloud folder situated under /var/www/html/ but currently root owns it. We can change that:
sudo chown -R www-data:www-data /var/www/html/nextcloud
Now the Apache account, www-data, will have write-access to the Nextcloud installation directory.
5.2. Create the Nextcloud database
5.2.1. This is optional
By default, Nextcloud can create a database and database user when supplying the root user and password in the Nextcloud web-based installer. The following steps are intended for either someone who wants to create their own database or does not want to supply Nextcloud with the root account credentials.
Before switching to Chrome to run the web-based installer, we’ll first create a database.
We can open a session with mysql by running the command mysql -u root -p and providing the root password we entered earlier.
Now we’ll create a dedicated database and user for Nextcloud with the following commands:
CREATE DATABASE nextcloud; CREATE USER 'ncuser'@'localhost' IDENTIFIED BY 'ncpassword'; GRANT ALL PRIVILEGES ON nextcloud . * TO 'ncuser'@'localhost';
Then exit the mysql session with quit
5.3. Install Nextcloud
Open up a browser and navigate to ip-or-hostname/nextcloud. Hopefully by this point a DNS entry has propagated; we’ll navigate to nc.domain.org/nextcloud to continue installation.
Success! The Nextcloud installation screen is there and showing no errors. Installation from here is simple:
- Provide a username and secure password for the admin account.
- Select a location for the data directory.
- Provide the database user we configured earlier: ncuser
- Provide the database user password: ncpassword
- Provide the database name: nextcloud
- Confirm the database is on localhost (it is).
When selecting a location for the data directory, keeping it in the webroot is really only OK providing .htaccess rules work. If they do not, as is the case at this point due to the way Apache is setup by default, or fail at any point in the future, the data directory will be publicly visible. We don’t want that.
Ideally it’s best practice to situate the data directory outside of /var/www/ in a location inaccessible for guests browsing the website. Where it’s ultimately placed is at the discretion of the administrator, though ensure the user www-data can write to it in its final location with:
sudo chown -R www-data:www-data /path/to/data
Scroll down and click Finish Setup.
6. Configuration
As it stands currently, Nextcloud isn’t very happy.
Ignore the HTTP error, this will disappear when we access the site over HTTPS.
6.1. Enable .htaccess
The .htaccess file doesn’t work because we’ve put Nextcloud in the main /var/www/html webroot controlled by the apache.conf file. By default it is set to disallow .htaccess overrides and we’ll need to change that:
sudo vim /etc/apache2/apache2.conf
Then change
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride None
Require all granted
</Directory>
To
<Directory /var/www/>
Options Indexes FollowSymLinks
AllowOverride All
Require all granted
</Directory>
Save and quit, then restart Apache with:
sudo service apache2 restart
6.2. Enable caching
The difference in speed between a Nextcloud server without cache and one with is huge. Particularly as the file and folder counts increase and more multimedia files make their way onto the server, caching becomes increasingly important for maintaining speed and performance. ACPu will handle a lot of the caching initially, leaving Redis to manage file locking. As the server grows and ACPu demands more resources, we could configure Redis to take a more active role in distributed caching. Having installed both APCu and Redis earlier, we’ll now configure them.
First, open the Redis configuration file at /etc/redis/redis.conf
sudo vim /etc/redis/redis.conf
Now, find and change:
port 6379 to port 0
Then uncomment:
unixsocket /var/run/redis/redis.sock
unixsocketperm 700 changing permissions to 770 at the same time: unixsocketperm 770
Save and quit, then add the Apache user www-data to the redis group:
sudo usermod -a -G redis www-data
Finally, restart Apache with:
sudo service apache2 restart
And start Redis server with:
sudo service redis-server start
With Redis configured, we can add the caching configuration to the Nextcloud config file:
sudo vim /var/www/html/nextcloud/config/config.php
Add the following:
'memcache.local' => '\\OC\\Memcache\\Redis', 'memcache.locking' => '\\OC\\Memcache\\Redis', 'filelocking.enabled' => 'true', 'redis' => array ( 'host' => '/var/run/redis/redis.sock', 'port' => 0, 'timeout' => 0.0, ),
A reboot may be required before the configuration change takes effect, but before we do we’ll make sure Redis is enabled to start on boot with:
sudo systemctl enable redis-server
Caching is now configured.
With both of these now resolved, the admin interface is looking a lot healthier:
6.3. Pretty links
Much like theming, pretty links aren’t mandatory, but they add to the overall aesthetics of the server.
Most of the hard work was already done during the setup of the environment with the enabling of mod_env and mod_rewrite, however to complete the removal of index.php in every URL, re-open the Nexcloud config file:
sudo vim /var/www/html/nextcloud/config/config.php
Add 'htaccess.RewriteBase' => '/nextcloud', (where nextcloud is the URL location – domain.com/nextcloud – of the installation) below one of the existing configuration options, for example:
Finally, from /var/www/html/nextcloud, run:
sudo -u www-data php occ maintenance:update:htaccess
From:
To (don’t simply refresh the page, remove index.php from the URL and load the page again, otherwise it looks like it doesn’t work):
6.4. Max upload
Until we try to upload files this is easy to miss. By default PHP ships with a file-upload limitation reminiscent of file sizes in the early 2000’s – 2MB. As we’re installing a personal cloud that may hold on to files gigabytes in size, we can change the PHP configuration to allow far more flexibility.
Open the php.ini file (7.0 may need to be replaced with a newer version of PHP, like 7.2):
sudo vim /etc/php/7.0/apache2/php.ini
Locate and amend:
upload_max_filesize = 2048M post_max_size = 2058M
The max size can be tweaked to suit, however be sure to always give post_max_size a bit more than upload_max_filesize to prevent errors when uploading files that match the maximum allowed upload size.
Restart Apache:
sudo service apache2 restart
Log into the admin area of Nextcloud, navigate to additional settings and ensure the max upload setting there reflects the change made to the php.ini file (in this example, 2GB):
6.5. Nextcloud 12+ PHP Opcache
From Nextcloud 12, additional configuration is required in order to correctly setup PHP Opcache. The following error displays until this is completed:
Re-open the php.ini file:
sudo vim /etc/php/7.0/apache2/php.ini
At the bottom of the file, add the following, as displayed above:
; Nextcloud Opcache settings
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1Save the file and restart Apache:
sudo service apache2 restart
On refreshing the browser, the warning should no longer be there.
6.6. Server-side encryption (optional)
As we’re running our Nextcloud installation on a remote host, far outside the confines of our internal network, it’s a good opportunity to enable server-side encryption. This guarantees that should anyone gain access to the data hosted on the server, file contents won’t be readable.
6.6.1. Encryption can lead to data loss
Encryption is a complex topic and getting this wrong will lead to data loss. Generally, using Nextcloud server-side encryption is not needed or recommended and instead you should strongly consider client-side encryption, or other methods of enforcing OS filesystem encryption instead. Continue at your own risk.
First we’ll enable the default encryption app:
- Click the Files link and switch to Apps
- Click Not enabled from the side-menu
- Click Enable on the Default encryption module
Next we’ll log into the Nexcloud administration area and navigate to Server-side encryption. Click Enable server-side encryption:
After reading through the warnings, click Enable encryption. We now need to log out and back in:
After logging back in and returning to this area, it will be possible to create a global recovery key:
However, if a global recovery key is considered too all-powerful, individual users may also recover encrypted files with their password by setting the following option to Enabled in Personal located when clicking the username in the top-right of the screen:
All data will now be encrypted at rest, as well as protected in transit when using SSL.
7. Conclusion
So following this guide we now have a new server running Nextcloud on Ubuntu supporting both caching and pretty links.
While this is yet another long-winded guide, as usual there’s nothing here I would consider to be overly complex which, for a platform that empowers self-hosting data, is a big plus over other solutions.
Want to know more about Nextcloud? Visit nextcloud.com or their thriving support community at help.nextcloud.com. I’m @JasonBayton there if you’d like to start a discussion about this guide or Nextcloud in general!
I hope this guide has been helpful, as always I’m @jasonbayton on Twitter, @bayton.org on Facebook and will also respond to comments below if you have any questions. I’d also like to know if you successfully installed Nextcloud following this guide, leave a comment below!
Drump 
Cezary 
andoni sagardia 
Althaea 
Simon 
Shiroi Tenshi 
Adam 
Alex Ec 
Jake Mecham 
Michal Tomasek 
Scott Brown 
Ioannis Dimitrios Zontos 
BrechtL 
Alexander 
Julien Hardy 
fxs074 fxs074 
Nicolas 
Fabian 
paolo 
Ryan Insell 
I have used your guide for nextcloud numerous times and it is nothing short of perfect thank you. Working on a long script to do it for me next time if i get it working ill post it to my GitHub
Thanks very much @logmancuso!
You’re more than welcome to follow up with the script when you write it; if it’s useful Nextcloud also offer official VM images, a RaspberryPi image, snap and more
@jason First off, thank you for the awesome guide!
I am running Nextcloud locally and plan on only accessing it through a VPN but while away so I skipped the part of your guide for setting up SSL (I tried it one time but received an error, probably due to not having a domain configured). The only issue is I can’t get rid of “Accessing site insecurely via HTTP. You are strongly adviced to set up your server to require HTTPS instead” message.
I also noticed that after setting up the Max Upload per your instructions and visiting the section additional settings , it still shows the default 511 MB.
Any suggestions?
Hi @junior466,
That alert is there for a reason… if you’re not wanting to set up SSL (which internally accessed via VPN is understandable) then just ignore it; it doesn’t impact your setup in any meaningful way other than to remind you it’s not a secure connection.
For the upload, you need to change 511 to 2GB as per the image. If on refresh it changes back, it may not be updating your
.htaccessfile located in the nextcloud folder (which you can edit manually).Thank you for this excellent guide! I tried a few other step-by-step procedures for installing Nextcloud on Ubuntu and they all failed. Yours worked great, even with 18.04.
I am using your guide again to boot up a new ubuntu server and was able to get everything working except for apache. It may be because I am trying to have the root domain load as the nextcloud server (e.g. https://example.com).
I believe that letsencrypt won’t authorize root domain cert unless i use the --webroot tag instead of the --apache flag. i have a public dns cname record that I can access the server from without ssl cert, but if i try and access from root domain I get an error that says “This page isn’t working – ERR_TOO_MANY_REDIRECTS”.
it looks as though the nextcloud instance is working fine and i can see that all of the checks have passed in the admin panel, but still stuck on the apache redirect and ssl cert stuff.
I am wondering if you have any experience with this?
Hmm, I can’t say I’ve seen or experienced this, but there have been a lot of recent changes with LE which may be causing issues. I’ll try to replicate.
You’ll I guess need to fall back to the manual SSL method instead
Thank you for getting back to me. I am wondering if there is a way to completely start over with the installation? Nextcloud seems to be working totally fine, but I am wondering if you have any suggestions on how to uninstall apache and all of LE and start over from scratch just doing it manually?
I am having a little difficulty with the --webroot stuff, but basically just bought a throw away .io domain that I want it to only be used for a temporary nextcloud account for a software cohort that start next week.
thanks so much for any suggestion or guidance you can provide.
There’s really no need to start from scratch. I’ll get some commands and such together based on the manual SSL steps when I’m free later
Awesome. Thank you so much! I am using CloudFlare as my DNS/Nameserver and turned off all of their built in SSL stuff because I would rather have it done on the server. I can access the Nextcloud instance with the direct server DNS name, but does now work if I try to point it to my root domain. I get errors that there were “Too Many Redirects”. Would it be helpful to post my logs or my current Apache settings somehow?
Fantastic write-up! I have been trying to install Nextcloud for a
couple of years now by using various guides found online but none of
them came close to how well documented this guide is. Well done sir!
Altough it is pretty well documented and the resulting setup is as close
to “production-ready” as it could be, there are a few things that could
be improved in to make it a true step-by-step for dummies guide. If I
may comment on these shortcomings, then perhaps you could revisit the
guide to make changes or explain what needs to be configured here.
Disclaimer: I am by no means Linux savvy.
@ 2.1. Installation URL.
This
part is very unclear. It assumes you understand what is being set from
the get go and so i dismissed this part hoping the next steps will
inform me of what choices in need to make ad-hoc
@ 4.2.1. Let’s Encrypt.
This
part was very straight forward but could use a little bit of detail to
help those whose nextcloud server is behind a firewall. When Let’s Crypt
communicates back with the nextcloud server, it will attempt to do so
via http (port 80). If the nextcloud server is behind a NAT’ed firewall
then an http rule should be created. Also, once https has been enabled
in Apache and a certificate has been generated, a new firewall rule to
enable https (port 443) traffic should be created.
@ 4.2.1. Let’s Encrypt. - Continued
Below
the screenshot of putty, you mention the following: “One step from the
manual process which is recommended is to add the following snippet to
the Let’s Encrypt-created vhost.conf file in the same way as is
documented in 4.2.2 below” This part is confusing because I don’t know
whether this should be executed after executing ./certbot-auto or
whether it should be executed if you’re following the manual process.
Also, it is confusing which file needs to be modified. You mention the
Let’s Encrypt-created vhost.conf file in one place and then the
/etc/apache2/sites-available/000-default-le-ssl.conf file in another.
I
opted to modify the
/etc/apache2/sites-available/000-default-le-ssl.conf file by issuing
sudo vim /etc/apache2/sites-available/000-default-le-ssl.conf, added the
described snippet and when it came time to save the file, i got an
error that it was read-only. No matter what I tried, I wasn’t able to
modify the file.
In the end, i skipped this step. Let’s Encrypt
cert was issued and tested to work successfully. I still would have like
to to add the snippet mentioned, though.
As for the sudo crontab
-e part, once I executed the command all I got was 4 options to chose
from (no previous jobs have been created for su). There wasn’t any
documentation for what option to select so i skipped this. Just one more
remark regarding the cron job, doesn’t the ./certbot-auto command take
care of creating a certificate auto update job as well? If so, then the
argument to run crontab should be moved to the manual install section,
no?
@ 4.2.2. Manual
I skipped all of this, FYI.
@ 5.3. Install Nextcloud
You
mention the following: “When selecting a location for the data
directory, keeping it in the webroot is really only OK providing
.htaccess rules work. If they do not, as is the case at this point due
to the way Apache is setup by default, or fail at any point in the
future, the data directory will be publicly visible. We don’t want
that.”
This is another confusing entry in the guide. Only after
completing the complete installation guide did I notice that I need to
type in /nextcloud at the end or the URL in order to access Nextcloud.
This is probably because i left the location for the data directory set
to default during the Nextcloud installation on the website. So now I
currently have a Nextcloud installation that can only be accessed
through https:///nextcloud and the default webserver
page on https:/// displays the Apache welcome screen.
Is
there any way to change this behaviour now that the installation is all
don or do I need to start from scratch? Also, what and where is this
.htaccess file that is mentioned? Is it in the default Apache
directories or in the nextcloud directory found under
/var/www/html/nextcloud/? Really confusing
@ 6.3. Pretty links
I
am very uncertain as to where the line ‘htaccess.RewriteBase’ =>
‘/nextcloud’, should be added in the
/var/www/html/nextcloud/config/config.php file. I tried googling
examples for this type of line but didn’t get any useful hits. Could you
perhaps share a screenshot? Another thing that confuses me here is the
mention of “where nextcloud is the URL location – domain.com/nextcloud – of the installation”. Does this mean that the line should read ‘htaccess.RewriteBase’ => ‘<mydomain.com>/nextcloud’ ?? One more step that I skipped due to uncertainty.
I
really can’t explain enough how thankful I am to the research and
effort that you put into making this guide. Had it not been for this
guide I would certainly have given up again and waited for Nextcloud to
be more install friendly. As i mentioned in the start, the resulting
installation is as close to perfect as it can get and that is thanks to
you.
I hope you can share a few minutes of your time, at your earliest convenience, to help iron out the last few bits and bobs.
What an amazing guide thanks @Bayton. Been looking for this for weeks. … I have an issue and I hope you can point me into the right direction and in advance sorry if the resolution is obvious I am no expert.
I have successfully installed nextcloud but I am unable to download or upload any files. I get “Redis server went away” on top of the page when I try and brows to upload.
I also see loads of these errors in the log file:
"Error PHP Redis::connect(): connect() failed: No such file or directory at /var/www/html/nextcloud/lib/private/RedisFactory.php#84
here is my
/var/www/html/nextcloud/lib/private/RedisFactory.ph file looks like this from line #84:
$this->instance->connect($host, $port, $timeout);
if (isset($config[‘password’]) && $config[‘password’] !== ‘’) {
$this->instance->auth($config[‘password’]);
}
here is my var/www/html/nextcloud/config/config.php
?php
$CONFIG = array (
‘instanceid’ => ‘xxxxx’,
‘passwordsalt’ => ‘xxxxx/xxx/xx’,
‘secret’ => ‘xxxx+xxxxxx’,
‘trusted_domains’ =>
array (
0 => ‘192.168.254.32’,
),
‘datadirectory’ => ‘/var/www/html/nextcloud/data’,
‘overwrite.cli.url’ => ‘http://192.168.254.32/nextcloud’,
‘dbtype’ => ‘mysql’,
‘version’ => ‘13.0.2.1’,
‘dbname’ => ‘nextcloud’,
‘dbhost’ => ‘localhost’,
‘dbport’ => ‘’,
‘dbtableprefix’ => ‘oc_’,
‘mysql.utf8mb4’ => true,
‘dbuser’ => ‘xxxx’,
‘dbpassword’ => ‘xxxx’,
‘installed’ => true,
‘memcache.local’ => ‘\OC\Memcache\APCu’,
‘memcache.locking’ => ‘\OC\Memcache\Redis’,
‘filelocking.enabled’ => ‘true’,
‘redis’ =>
array (
‘host’ => ‘/var/run/redis/redis.sock’,
‘port’ => 0,
‘timeout’ => 0.0,
),
‘loglevel’ => 0,
);
OK, so if you have the additional LE apache config, you can disable it with
sudo a2dissite ssl-le-apache.conf(or whatever the name would be, you can validate withls -l /etc/apache2/sites-available)Or you can edit it, whichever you prefer…
On the SSL, the command I use for all of my domains is:
sudo /etc/certbot-auto certonly --rsa-key-size 4096 --webroot -w /var/www/ -d domain.comWhat this does is set the webroot as
/var/www(which creates a validation folder within, so has to be public facing), you’re asking only for the cert and no Apache integration, and when it’s complete it’ll output the certs to/etc/letsencrypt/live/domain-0001(where domain-0001 is whatever the domain is).You can then use the following as an example of the
VHOSTI use for my Apache config:After this you can enable the site, if I called this
nc.confit would besudo a2ensite nc.conf && sudo service apache2 restart(you can use reload instead of restart, whatever you want).Is that helpful?
Hmm, have you checked the permissions… validated the redis conf file?
I don’t understand. It clearly states where Nextcloud is being installed and what needs to change if you want it installed elsewhere. If you skip that then it’ll install to
/nextcloudas the guide is written.It’s after. If you’re following the guide top to bottom then you would do this after running the above certbot commands. I also suggest adding it to the certbot created file, so there’d be no file if you don’t first run the certbot commands!
vhost.confis an example name, then I state it explicitly while editing.100% definitely running
sudo? Because that should not be happening.Indeed, I’m not going to suggest which editor you should use for contab as it’s your choice. Given everything else is vim in the guide though you could have chosen that.
It does not.
This is because you didn’t read 2.1.
Yes, you can read 2.1 and make the relevant changes to the apache vhost.conf files, the Nextcloud config file and restart the Apache server
You’re not editing
.htaccessdirectly, so it’s not part of the guide. Normally.htaccesswill be located in the root of the install directory, so/var/www/html/nextcloud/in this case.Under any of the existing written lines, it doesn’t matter. I can indeed add a screenshot there to make it clearer though
No, I gave you the line to add based on the URL being domain.com/nextcloud. You’d only edit this if you used domain.com/cloud or just domain.com, where the line would read “/cloud” or “/” respectively.
Hope that helps!
Hi,
Is it possible to use Ubuntu 18.04 instead of 16.04 ?
Thank you !
Yes! Should be the same process.
Thanks for you article about nextcloud and let’s encrypt. But after installing let’s encrypt, I get this error “can’t access ‘/’ on this server”. What is the problem?
Thanks in advance
Can you get me the Apache logs please?
/var/log/apache2/error.logThere’s the problem. There’s a misconfiguration either on your Apache conf file, or one of your Apache vhost configurations.
What do you see if you
ls -l /etc/apache2/sites-enabled?One of those demo/sdrive configs is overriding your NC install. I don’t see a nextcloud.conf vhost there either so I really can’t say how you’ve set it up.
So it means I should have only one Vhost on my server or…?
No not at all, it means every vhost needs to be unique if it is to work with other vhosts on your server.
If two enabled vhosts both point to
/var/www/htmlthen they’ll clash. Whilst one pointing to/var/www/html/server1/and the other/var/www/html/server2/will work fine together.Yes That’s what I have done. They all have unique directory and unique subdomain names
One of them will be clashing with the one you’ve created for Nextcloud, otherwise Nextcloud would be running OK. Specifically, I imagine something for
/var/www/has the settingsFollowSymLinks and SymLinksIfOwnerMatchdisabled.So how will I enable them?
Look through your vhost conf files to see where the above has been set. If you don’t find these items, check your main apache.conf file
/etc/apache2/apache2.confand see what’s set there against/var/www/Ok a minute let me do that now
Then this is overridden either at the vhost level or with a
.htaccessfile.So please what should I do now?
Fixed by not allowing override in the
apache.conffile.