Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#38650 - [owncloud] config in /etc does not work

Attached to Project: Community Packages
Opened by Damian Nowak (Nowaker) - Friday, 24 January 2014, 19:11 GMT
Last edited by Sergej Pupykin (sergej) - Saturday, 25 January 2014, 19:08 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Sergej Pupykin (sergej)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No


I previously used owncloud from AUR which kept config in /usr. I know it sucks, and your solution is better but it does not work for me.

> Can't write into config directory!

Permissions look good:

root@apps /usr/share/webapps/owncloud # ls -la|grep config
lrwxrwxrwx 1 root root 28 Jan 24 19:45 config -> /etc/webapps/owncloud/config/

root@apps /etc/webapps/owncloud/config # ls -la
total 24
drwxr-xr-x 2 http http 4096 Jan 24 19:35 ./
drwxr-xr-x 3 root root 4096 Jan 23 10:17 ../
-rw-r--r-- 1 http http 639 Jan 24 19:35 config.php
-rw-r--r-- 1 http http 9514 Jan 22 12:24 config.sample.php

With `sudo -u http /usr/bin/zsh` I am able to edit config file and directory (e.g. create new files).

No, it's not open_basedir, it's OK.

Note, before installing community/owncloud, I removed aur/owncloud and rm -rf /usr/share/owncloud. It's a clean installation.

Using php-fpm, nginx, postgres.

I had to remove the package-provided symlink, and mkdir and chown config directory to get it working again.
This task depends upon

Closed by  Sergej Pupykin (sergej)
Saturday, 25 January 2014, 19:08 GMT
Reason for closing:  Not a bug
Comment by Sergej Pupykin (sergej) - Saturday, 25 January 2014, 18:17 GMT
I belive it is openbasedir or something php related. It works well for me.
Comment by Sergej Pupykin (sergej) - Saturday, 25 January 2014, 18:24 GMT
you also need to allow webserver resolve symlinks
FollowSymlinks option in apache
Comment by Damian Nowak (Nowaker) - Saturday, 25 January 2014, 18:26 GMT
It *was* open_basedir in the first place, but I set it accordingly - and then it stopped appearing in my /var/log/nginx/error.log. But the problem still persists. But let me just disable open_basedir totally and see once again. FollowSymlinks may be quite a good hint - I will check how it's done in nginx. (But I am not very optimistic about it - how "FollowSymlinks" option for webserver would affect PHP code that wants to open some files?)
Comment by Damian Nowak (Nowaker) - Saturday, 25 January 2014, 18:34 GMT
(I mean: before reporting this issue I already dealt with open_basedir. That's why I wrote "open_basedir is OK")
Comment by Damian Nowak (Nowaker) - Saturday, 25 January 2014, 19:02 GMT
Please close. That's really funny what happened. A previous version of nginx didn't need "error_log /var/log/nginx/error.log" directive. The error log was written anyway. This version has been replaced with a new one a month ago, but today I was still running on the previous version (no restart). I got open_basedir errors in the error.log so I changed the open_basedir directive in php.ini and restarted nginx and php-fpm. After that, open_basedir errors stopped appearing in error.log because, I believed, open_basedir problem was fixed with what I set in php.ini. But no, nginx just stopped logging any errors to /var/log/nginx/error.log! Sorry for taking your time. ;-)