From ArchWiki

Possible merge with owncloud

[[Moved from Talk:Nextcloud -- Rdeckard (talk) 13:41, 7 January 2017 (UTC)

I'm thinking many of the installation and configuration steps are identical between Nextcloud and Owncloud. We could possibly merge these two articles. There is some good info here that may be missing at Owncloud. I think unless there are drastic differences they should be combined. We could note any differences in the main article. -- Rdeckard (talk) 01:52, 5 January 2017 (UTC)

Good idea. Are you offering to take point? Graysky (talk) 01:58, 7 January 2017 (UTC)
Sure. It actually looks like many of the sections are identical (were copied). I'll work on it. -- Rdeckard (talk) 13:00, 7 January 2017 (UTC)
Wait, shouldn't we create a new page merging the content, then setup redirects from 'owncloud' and 'nextcloud' to that new page? To me, the unified page would would allow for either package to be installed from one read without having all the clicking between pages like I see you have started to do. Graysky (talk) 13:22, 7 January 2017 (UTC)
Right. That was temporary until I got everything merged piece-by-piece. It all now goes to ownCloud where both programs are treated. -- Rdeckard (talk) 13:36, 7 January 2017 (UTC)
OK, if you're finished, I might take a look at further refining the unified page, but I don't want to deal with potential content collisions if we are both editing simultaneously :) Graysky (talk) 13:42, 7 January 2017 (UTC)
Go for it! I'm done with it for the morning. Thanks! -- Rdeckard (talk) 13:44, 7 January 2017 (UTC)
I Realize I am a bit late on this, but the fact that Nextcloud forked from ownCloud, wouldn't it have been advantageous to keep them separate as we don't know how long the install processes will remain the same / similiar? --TheFlyingFool (talk) 13:57, 25 January 2017 (UTC)
We may have to revisit this again. But for now the setup and configuration are nearly the same. Personally I think the owncloud/nextcloud manuals do a great job with the details, so we should refer to them more often. If and when the installation process here diverges, we'll consider splitting again. -- Rdeckard (talk) 13:50, 31 January 2017 (UTC)

Switch to cron from AJAX

The ownCloud 9.1 Server Administration Manual on "Defining Background Jobs" states cron as the preferred method for executing regular tasks. It also states that AJAX is "...the default option. Unfortunately, however, it is also the least reliable." The downside being AJAX requires regular visits to the page to trigger the background job. --Koopa (talk) 21:37, 7 February 2017 (UTC)

Versions of nextcloud from 12 and up suggests that both cron and systemd can be used, and I see no point in even mentioning cron, since it's a whole software piece that's missing from arch by default, and adding it to this article contributes nothing. Systemd should be used by default with Arch to integrate well with other parts of the OS, and not to confuse users with multiple scheduling tools. NeoTheFox (talk) 10:53, 28 August 2017 (UTC)

Uploaded file size limitation

The article is missing raising file size limitation. Current max file size with the provided configs seems to be 512MB - 2GB depending on what you use to upload.

This seems to be set in /usr/share/webapps/nextcloud/.user.ini for the web side, /tmp needs to be as big as all concurrent file uploads, and possibly more.

Documentation is here:

Am planning to figure this out and add it to the article sometimes in the future, but if someone does it before me I won't be mad.

C0rn3j (talk) 10:51, 2 October 2017 (UTC)

Cron, file scan and preview timers

I have changed the AUR repository from `nextcloud-systemd-cron` to `nextcloud-systemd-timers`. I did this change, because I have also included timers for periodic file scans and preview generation. If there is interest, I can add some lines about these timers to the Nextcloud Wiki article.

—This unsigned comment is by Dschrempf (talk) 09:34, 28 November 2018‎. Please sign your posts with ~~~~!

I have changed [1]. It sure is helpful, if you add a little about what is included. --Indigo (talk) 18:40, 28 November 2018 (UTC)


I believe the INI file [2] included on this page has issues (at least it did for me). Those issues are resolved with a one-line addition to the bottom:

env = front_controller_active=true

The issue being that the Nginx configuration provided throughout this page includes the following block:

location = / {
    rewrite ^ /index.php;

But this causes conflicts with the PHP-side's own URL rewriting. Adding the front_controller_active environment variable clears this up.

Djmoch (talk) 03:56, 31 December 2018 (UTC)

Add disclaimer for possible disadvantages of setting up nextcloud on a rolling-release OS

Dear administrators,

I would like to propose adding a disclaimer to the wiki about the possible disadvantages of setting up nextcloud on a rolling-release OS like Arch linux. I have a nextcloud server that became dysfunctional after a recent update from php 7.3 to 7.4, since nextcloud doesn't upgrade as fast as a rolling release OS does. Trying to downgrade to php 7.3 was not possible either, due to several dependencies failing to allow that. Please don't get me wrong, I do believe that Arch linux's rolling-release feature is one of its strengths but when it is not matched with the same agility in the development of other software packages, it may become a problem, like in the case described above.

Thank you for your consideration.

Hakova Hakova (talk) 17:16, 21 December 2019 (UTC)

Update Collabora section to include HTTPS for Docker container

It appears the Docker image for the Collabora section uses in the nginx and Apache examples, but the default Docker image now ships listening with HTTPS, eg. or you get Bad Gateway errors from php-fpm.

—This unsigned comment is by Chetwisniewski (talk) 22:04, 29 March 2020‎. Please sign your posts with ~~~~!

the "Make sure that session.save_path is configured." bit could use explanation

I actually still do not know how to configure this.

—This unsigned comment is by Zuntik (talk) 16:01, 21 September 2020 (UTC). Please sign your posts with ~~~~!

I actually happen to have the same problem. I don't know how to configure this and miss some few more explanation. Setting up nextcloud still seems to be a very restricted thing to me.

Manouchk (talk) 15:51, 10 January 2021 (UTC)

Recommended Configuration for Application Servers

As 21.0.0 introduced the nextcloud user with no configuration alongside it, it is unclear to me how to handle this. For example: Say I have multiple PHP applications running. How should I configure my LEMP stack in regards to potentially having multiple instances of php-fpm. In a container world this would be trivially simple. Am I expected to create multiple php-fpm services with seperate configurations? If yes: Maybe there should be a way to start a php-fpm service with different configuration (like php-fpm@config-name.service) Scrumplex (talk) 21:52, 21 February 2021 (UTC)

Yes, the current section(s) explaining the various hosting options for nextcloud are still in dire need of clarification and fixes. We actually also require an entire dedicated page just to explain php-fpm properly.
That being said: Generally it is advisable to create one "pool" for each web application (i.e. one configuration file per application in /etc/php/php-fpm.d/), especially when they are run as separate users.
The php-fpm.service is run as root and creates these pools (which in turn are run as the specified user the application should run as).
I don't know, whether it is feasible or possible for templated services for php-fpm to be created per application, but at any rate, that is for upstream to implement and decide.
Davezerave (talk) 09:48, 22 February 2021 (UTC)
I added a php-fpm section and added more detail to the nginx section. I agree that we could use a dedicated php-fpm article to direct people to, but I think this article now has enough info for people work out how to use both with Nextcloud.
If the package is updated to include the example php-fpm config and the recommended nginx config files provided by Nextcloud like it provides for Apache, the article could simply direct users to them.
Williamvds (talk) 17:35, 23 February 2021 (UTC)

Removing the fluff from the configuration section

The only sections that are really necessary are the database setup and PHP setup sections. All the sections before them simply restate the default configurations of the package and are optional steps in configuration. I propose that Nextcloud#Data directory, Nextcloud#Writable apps directory, and Nextcloud#Log directory be merged into the main Nextcloud#Configuration section and be kept as brief as possible, mentioning primarily the appropriate key in config.php and any extra considerations like directory permissions. Anyone have any thoughts? Williamvds (talk) 18:01, 23 February 2021 (UTC)

Agreed. If you're new to Nextcloud, it is hard to setup if you're trying to follow the article step by step. We should strictly separate necessary and optional steps. Steffo has already simplyfied the article in his rewrite. Anarki (talk) 06:46, 6 May 2021 (UTC)

Nextcloud 21 rewrite

I started (but definitely not completed) a rewrite over at User:Steffo/Nextcloud, detailing the new process to install Nextcloud after the 21.0.0 update and checking whether the old instructions work or not.

As this is my first major edit to Arch Wiki, feedback would be appreciated! Should I change something? Should I write directly in this page?

Steffo (talk) 13:47, 28 February 2021 (UTC)

Having had trouble with Apache and the new user setup that the package now uses, I edited the page a little to add a warning about mpm_itk. As my apache server has too much stuff running off it for me to get all the different modules / requirements / incompatibilities to line up I've actually ended up using a second Apache process, running as nextcloud user and proxied to from the main one, which seems to make life a lot easier in the end. Maybe my note is not enough and more warning and explanation could be included regarding using Apache and the new package user? Personaly I think you can just go ahead and edit the page, I'm sure people will correct/revert anything they disagree with. Thanks for taking the time to work on this, the article certainly needs an overhaul with all the changes that have come in with v21. Regards Marcool04 (talk) 14:03, 28 February 2021 (UTC)
Steffo, very good tutorial. I'd just put configuration of php-fpm into a separate section as you did in the Prerequisites e.g. after php setup, since it's independent of the web server itself. Also I'd put the configuration items in the same order as Prequisites. If you like I'd do some rearrangements and completions in your article. Anarki (talk) 06:36, 6 May 2021 (UTC)
Thanks for your feedback and contributions! :) Steffo (talk) 23:28, 9 May 2021 (UTC)

occ with uWSGI

How can we run occ with uWSGI? Do we really need to mirror the ini of uWSGI in a php.ini configuration? Can't we run php through uWSGI?

—This unsigned comment is by FederAndInk (talk) 15:53, 5 March 2021‎. Please sign your posts with ~~~~!

Issues with MariaDB >= 10.6

@Flyingpig Thanks for further polishing this section. I'd like to discuss referencing FS#71549. IMHO this is a dead-end. As Davezerave mentioned there:

It seems there is not much we can do about it for now.

It's an upstream issue. So we should reference the upstream ticket.

(Actually the link is already present in the sentence "Upstream is aware of this problem...".)

Wolegis (talk) 10:45, 24 July 2021 (UTC)

I figured a little bit of more context wouldn't hurt, but if you want to remove the link to FS#71549, then go ahead. -- Flyingpig (talk) 12:18, 24 July 2021 (UTC)

Collabora section is outdated and should propably link to official documentation

The current vhost examples are outdated and don't work with the current version. I guess we should link to the external documentation (docker doc, nginx config) instead? Or do we want to keep stuff in the wiki even if it might be outdated?

hashworks (talk) 15:57, 11 December 2021 (UTC)

Feel free to flag it with Template:Out of date or another article status template to increase the visibility of the problem. — Lahwaacz (talk) 21:14, 15 December 2021 (UTC)

Out-of-date marker in Troubleshooting section

I took the liberty to rephrase the out-of-date marker in the Troubleshooting section. Please have a look at the subsections below this marker and in case you know a certain subsection still applies don't hesitate to update it and move it above the out-of-date marker. Any subsections still below the marker by 2022-09-30 will be deleted. Wolegis (talk) 13:54, 17 April 2022 (UTC)

±0: I'm not using this software so no opposition from me. I've changed it to Template:Remove and included in the first section concerned with a light re-word to be more in line with your intentions. --Erus Iluvatar (talk) 14:26, 17 April 2022 (UTC)

Log file spam (in Troubleshooting section)

I added this quick fix because the Nextcloud log file was spammed with PHP warnings after updating to PHP 8.1. This problem does not currently occur and should be completely resolved with version 24. But who knows what the future will bring? So I would not delete this information. —This unsigned comment is by Kama (talk) 2022-06-11T16:56:59. Please sign your posts with ~~~~!