Notice: Undefined variable: name in /srv/http/vhosts/ on line 248

Package Details: nextcloud 11.0.1-1

Git Clone URL: (read-only)
Package Base: nextcloud
Description: A safe home for all your data. Secure, under your control and developed in an open, transparent and trustworthy way
Upstream URL:
Licenses: AGPL
Submitter: greyltc
Maintainer: greyltc
Last Packager: greyltc
Votes: 85
Popularity: 19.979367
First Submitted: 2016-06-04 15:53
Last Updated: 2017-01-24 17:21

Dependencies (14)

Sources (4)

Latest Comments

1 2 3 4 5 6 Next › Last »

dvzrv commented on 2017-02-02 20:17

@greyltc: I don't think that your permissions script is needed.
All files owned by root should just be fine, as webapps should be run as http or even their own user.

As @gdamjan already pointed out, the "real" data directory should not be placed below /usr/share/webapps/nextcloud/ and for the apps we actually have packages in the AUR.
Just like with owncloud it's possible to define multiple folders for apps. The one in the package directory should not be writeable, if there are packages providing them.

The permissions introduced by your script do three things:
- they break the way apps are installed as packages (nextcloud and your package manager now fight over their versioning)
- populating /usr/share/webapps/nextcloud with files that don't belong to any package (which can get very very messy) through the app store, etc.
- not adding additional security by making the webserver group-own the folder and some subfolders

The script is too generic to apply properly to the way things are installed through a package manager. Either use the script, when doing a package-manager-less install or don't.
I'm asking myself at the moment, if it is needed at all. Are there any usability implications, when it's not used?

Also: I guess currently the preferred way of running nextcloud is with NEXTCLOUD_CONFIG_DIR (set for the application/web server.
This can be provided using UWSGI_SETENV (in the case of nginx + uwsgi) when redirecting to the application socket.
The place for configuration files would be in /etc/webapps/nextcloud, but when not using a symlink, nextcloud expects that folder to be at least group read/writable. It would be great to change that!
The nextcloud-news-updater also places its files in that directory btw.

Not putting any symlink anywhere is not very standards-compliant (in regard to other webapps). Configuration of a service installed system-wide should take place in /etc.
Also: A copy of the config.sample.php in /etc/webapps/nextcloud would be awesome!
A look at the current owncloud PKGBUILD might give some clues.

In any case: Thanks for packaging!

chrbayer commented on 2017-02-02 13:20

Thank you very much for packaging this!

I got it working without any problems, but I still have one question: ffmpeg is listed as an optional dependencies, but how is nextcloud connected to ffmpeg? I see no difference if it is installed or not and in nextcloud there is no configuration for it... Playing videos in avi container does not work weather it is installed or not...

Does someone know the benefit of ffmpeg?

Thanks in advance!

graysky commented on 2017-01-29 10:16

In other words, don't use an aur helper!

greyltc commented on 2017-01-25 12:09

onny, what aur helper do you see this issue with? yaourt? pacaur?

onny commented on 2017-01-25 11:48

I know why this happens! Your PKGBUILD doesn't wipe $srcdir, so old nextcloud source directories will remain there and all legacy files fill be packaged :(
So somehow you need to rm everything in srcdir before extracting the tarball!

onny commented on 2017-01-25 11:06

Somehow a lot of extra files appear on the integrity check after updating to nextcloud 11.0.1:
Problem is resolved with manually deleting all files ...

z3ntu commented on 2017-01-24 18:41

After the upgrade to 11.0.1 I get a 403 Forbidden when trying to access nextcloud. Apache log:
[Tue Jan 24 18:39:57.098957 2017] [autoindex:error] [pid 15660] [client <ipaddress>:51924] AH01276: Cannot serve directory /usr/share/webapps/nextcloud: No matching DirectoryIndex (none) found, and server-generated directory index forbidden by Options directive

EDIT: Apparently it fixed itself after some minutes of waiting... Seems to work fine again.

bjo commented on 2017-01-23 13:50

Please update, 11.0.1 is out.

graysky commented on 2017-01-07 13:44

@greyltc - Great job with this PKGBUILD, thank you for the effort.

cmorgenstern commented on 2017-01-05 19:24

For future reference, there are two options for verifying GPG keys with makepkg:

1) Configure gpg.conf to download the GPG key that is included in this PKGBUILD. See the Arch wiki article for information -->

2) Manually get and trust the key by executing, for example:
$ gpg --keyserver hkp:// --recv-key D75899B9A724937A

Once your local keyring has the key, you should be able to proceed without issue. For further information, check out Allan McRae's excellent blog post on the subject here -->