Setting up nextcloud on an Ubuntu server

I am setting up nextcloud on an Ubuntu server.
I used this tutorial to get it running with Ubuntu 22.04 LTS.
Does anyone know if the newer 24.04 LTS version has changed any critical parts or would it still work without major changes?

You will have to start reading and do some trial and errors. But there is nothing that - on paper at least - is blocking NC on Ubuntu 24.04 LTS. There can be changes to some parts which is then outdated in the tutorial. So you will have to get your hands dirty.

1 Like

Two things I ran into when I tried to install Nextcloud on Ubuntu 24.04:


I don’t understand why people always recommend using external PHP sources. This is completely unsuitable for normal users. And some beginners don’t manage to get rid of the old foreign sources when they dist-upgrade.

I think these instructions are quite good. It also works for Ubuntu 24.04 LTS with a few adjustments to PHP 8.3. Find PHP 8.1 and use PHP 8.3 in the tutorial. However, you will then have to get rid of the PPA-PHP stuff. I think the installation instructions you mentioned don’t tell you how to do this.

Blunix recommends not to use the Ubuntu provided packages but instead to setup the “Sury PPA” (Personal Package Archive). Sury is a Debian developer that provides an apt repository for installing specific PHP versions.

This has the aforementioned advantage but unfortunately also some disadvantages. If possible, I would always use the standard PHP version from the release, e.g. Nextcloud 22.04 LTS (PHP 8.1) or Nextcloud 24.04 LTS (PHP 8.3) , if possible.

1 Like

I mentioned them because they are in the tutorial @goncharow linked to.

I guess you mean do-release-upgrade (on Ubuntu), or before changing the repos to a new releasse (on Debian) because there is no need to disable the PHP repos for normal dist-upgrades.

Yeah, these instructions are fine, and I agree that on Ubuntu 24.04 there’s no need for the Sury repos (at least for now) as it already ships with PHP 8.3 which is the latest and greatest. :slight_smile:

1 Like

Yes. E.g. from Ubuntu 22.04 LTS to Ubuntu 24.04 LTS.

Yes. And also it was not needed for the Ubuntu 22.04 LTS and the last Nextcloud releases.

Here you can find the Nextcloud releases and PHP versions. Ubuntu 22.04 LTS is shipped with PHP 8.1 and Ubuntu 24.04 LTS is shipped with PHP 8.3

Releases and PHP versions · nextcloud/server Wiki · GitHub

unless you explicitly want to use PHP 8.2 or 8.3 on Ubuntu 22.04 or PHP 8.3 on Debian 12 :wink:

1 Like

That’s right. But I think someone who simply follows an installation guide doesn’t need that. Only the person who wrote the installation instructions might think that it would be useful. :wink:

Nextcloud 28-30:
Ubuntu 22.04 LTS and Ubuntu 24.04 LTS

Nextcloud 26-27:
Ubuntu 22.04 LTS

Nextcloud 25:
Ubuntu 20.04 LTS and Ubuntu 22.04 LTS

Of course, you also have to use the right Nextcloud version at the right time.

Releases and PHP versions · nextcloud/server Wiki · GitHub

Nextcloud 29 requirements
Nextcloud 28 requirements
Nextcloud 27 requirements

Apparently the entries for Nextcloud 29 and Nextcloud 28 are incorrect, as Ubuntu 24.04 LTS is not listed there at all, although PHP 8.3 is listed as supported.

1 Like

Thank you for sharing. That’s pretty useful


I read the tutorial, some things are good but you can throw the PHP-FPM part in the trash:

With php it actually makes a difference in which order the packages are installed so that no unnecessary php SAPIs are installed. In the description the packages are neatly sorted alphabetically but that is wrong. You should always install php8.2-cli first (to stay with version 8.2 in my example), otherwise SAPIs like php8.2-phpdbg are installed, which are absolutely superfluous. Then php-fpm packages are installed there, not only for 8.2 but also for 8.1 and 8.3.

this appendix is ​​completely superfluous:

php-fpm- \
php8.1-fpm- \
php8.3-fpm- \

Apart from the fact that it is possible, I don’t understand the purpose of an fpm pool called “Nextcloud”, other than to give the tutorial a sheen of “omniscience”. In reality, it is extremely counterproductive as it makes maintenance and updates more difficult. The php-updater script can easily transfer this type of pool from one version to the next, but it is still completely unnecessary if Nextcloud is the only application using fpm.

This tutorial says’

When installing PHP-FPM, a default pool config file is always created below “/etc/php/8.2/fpm/pool.d/www.conf”. This file can be removed

but many people don’t do that and then sockets are created that bind all the resources defined in this pool file but they are NEVER accessed.

This applies even if this pool is deleted as suggested above, but the pools for the unnecessarily installed php versions 8.1 and 8.3 remain active and place unnecessary strain on the server.

Meanwhile 24.04 is fully supported.

Surý is the maintainer of the Debian/Ubuntu packages for php, so “Debian PHP Maintainers” and Ondřej Surý are identical in that sense. So Ondřej Surý is not just some admin who built a few packages for some obscure period of time (as is unfortunately so often the case with ppa repositories) but rather THE source for php packages on Debian and Ubuntu Server. Surý, with due respect, is not an “external php source” and the Surý-Repo packages are much better suited for use in a server environment.

I judge this not only as an opinion, but from my deep knowledge of the packages and the structure of the internal dependencies from decades of working with Ondřey’s work

Much and good luck,


That’s true, of course. Just as Debian programs for Ubuntu and Ubuntu for Debian. I meant external package source mainly in the context that you extend the actual Ubuntu package sources and that beginners in particular do not understand what they are doing.

If you exchange the Nextcloud releases and also the Ubuntu releases correctly, you should be able to get by with PHP 7.4, PHP 8.1 and PHP 8.3 and thus with the standard PHP packages from Ubuntu 20.04 LTS, Ubuntu 22.04 LTS and Ubuntu 24.04 LTS without any problems. As far as I know, Nextcoud’s supported PHP versions are based on the Ubuntu versions.

Currently, the dist upgrade from Ubuntu 22.04 LTS to Ubuntu 24.04 LTS for Nextcloud 28, Nextcloud 29 and the new release Nextcloud 30 should work fine with the default sources. The Nextcloud releases support PHP 8.1 and PHP 8.3.

Of course, this step would be wrong if you are still with Nextcloud 27. Or vice versa if you wait too long with the dist-upgrade e.g. from Ubuntu 20.04 LTS to Ubuntu 22.04 LTS. Then you need a third-party source to be able to install the required PHP version.

It may seem that way, but there are still small differences in the internal dependencies, which makes the php packages from the Sury repo preferable.

They are the packages for professional server use, while the others are the “Ubuntu all glue - sticks everything, but everything only a little bit”

I don’t think so. Nextcloud’s PHP dependency follows → the PHP lifecycle ←

and Ubuntu is of course based on it too. :wink:


I don’t see any reason to install multiple PHP versions at all, unless you have other applications installed on the same server that absolutely need a specific (other) version.

Maybe he’s not good at regex and therefore doesn’t want to use the sed command to edit the original file, or maybe he didn’t want to copy another well-known tutorial 1:1 :wink:

However, if I were to do it with a separate file, I would call it wwww.conf and only put the custom settings in there, that way I could still use the default pool while only the custom settings would be read from the additional file.

My goal is always to keep everything as default and therefore as simple as possible, because in most cases, especially on a home server, there is usually no need to reinvent the wheel :wink:

Good to know. :slight_smile:

As I read on, I notice more and more unnecessary things:

Creating a RAM disk for php’s sole use is absolutely unnecessary. It brings no performance gain whatsoever, since /tmp is already in RAM by default, and the tmp directory is not exempt from the RAM size restriction.

Obviously the PHP part was created without the author having any deeper knowledge of the subject. It is pretended that php-cli does not exist. But php-cli is extremely important because it is used for all processes that are called from the command line. This includes cron jobs and occ-calls, for example.
Fortunately, Nextcloud is configured in such a way that the most important values ​​without which Nextcloud cannot work are already set internally, but if, for example, ‘memcache.local’ in config/config.php is set to ‘\OC\Memcache\APCu’, then that’s OK, because apc is activated by default in php, except for php-cli. To do this, you should explicitly enable apc in php.ini for php-cli with the value “apc.enable_cli=1” instead of specifying it in the command line every time you call it. This also makes switching to a different ‘memcache.local’ handler much easier. You don’t have to look through all the scripts to adapt the occ call!

However, if php values ​​for the php-redis module are only passed in the pool file:

php_value[session.save_handler] = redis
php_value[session.save_path] = "tcp://"

and are not visible to php-cli and other important redis values ​​are not set, then problems are inevitable.

So in short, my advice:

Use the tutorial as an example and learning aid, specially when it comes to the special case like here with Hetzner, but not as an installation guide that you have to follow in every respect. At the very least, → Nextcloud’s own manuals ← should have a higher priority.

Much and good luck,


Question: These settings are only necessary if I want to use Redis as PHP session handler? If I use Redis only for transactional file locking and/or memory cache within Nextcloud, I don’t need them, right?

Yes. Conversely, if redis is used as session handler, transactional file locking must be enabled:


1 Like

Thanks. :slight_smile:

One last question… :wink:

Would you consider using Redis as a session handler to be a good general recommendation for an average home server setup with reasonably fast SSD storage, or would you only enable it if there were performance issues, or maybe not at all?

O, that is a good one!

I have to honestly admit that I have no idea whether this brings any advantage and if so, how much. I just always assumed that if I was already using redis - and redis is really designed for speed - that it would bring some advantage. :wink:

It is much more important to define igbinary as the serializer (which is automatically the case if php-igbinary is installed on Ubuntu/Debian) to speedup php-redis. Compared to the normal php serializer or json serializer, this has up to 50% advantage in memory consumption and up to 30% of speed.
In the packages from Surry (including the ‘normal’ Ubuntu and Debian packages), igbinary support is compiled into the php modules redis and memcached. That is not the case with the php modules used in the nextcloud-vm (HanssonIT).
If you are using such a nextcloud-vm, run php-updater, that script will detect if the modules are built with igbinary support and can fix that.

To use igbinary as a serializer for apc, “apc.serializer=igbinary” must be explicitly commented out uncommented in the file “/etc/php/$php_version/mods-available/igbinary.ini”.

Much and good luck,


Thank you for the detailed answer. :slight_smile:

Interesting, I am not using the Hansson VM, and I am actually using the Sury repos, apcu as a memory cache, and Redis only for transactional file locking, so I guess I will comment out apc.serializer=igbinary and leave the session handler as is for now.

Maybe I’ll do some testing with Redis as local memory cache and session handler when I’ve read up a bit more on the subject.

Btw. I’m not experiencing any performance issues on my instance, so the question was more out of general interest. Thanks again :slight_smile:

Ouh, I just see, I wrote it wrong. It IS commented out by default but it must be UNCOMMENTED by removing the ‘;’ at the begining of the line.

Sory, that was just a Freudian slip