curl_setopt_array error with SabreDAV and OwnCloud

[DanielRuf]

I am getting curl_setopt_array(): CURLOPT_FOLLOWLOCATION cannot be activated when an open_basedir is set at /3rdparty/Sabre/DAV/Client.php#465 after I have installed owncloud

Howe can I solve this? Does this break any functionality or feature when I get this error?

[ghost]

To solve this at the moment you have to unset the open_basedir php.ini config directive as stated in the message

[ghost]

Ref: #1916

[DanielRuf]

So another 3rd party library with the same issue. Should be solved. @evert @fruux

[evert]

Tracked here: https://github.com/fruux/sabre-dav/issues/330

[DanielRuf]

Oh and curl_setopt(): CURLOPT_FOLLOWLOCATION cannot be activated when an open_basedir is set at /lib/private/util.php#1040 @owncloud @DeepDiver1975

[VincentvgNn]

@PVince81
Please have a look at issue #8510 that I posted on May 8th 2014.
The same or almost same issue?

I just installed OC server 7.0.0. and I still need the repair method of adding the 6 lines to the .htaccess file as I mentioned on Wed Apr 16, 2014 2:09 pm at: http://forum.owncloud.org/viewtopic.php?f=26&t=20244

[DanielRuf]

I think no. open_basedir is a bit hard to handle sometimes. This issue here is tracked at the repository of SabreDAV and just ist about this issue in this 3rd party library.

[VincentvgNn]

@DanielRuf
At Sabre-DAV https://github.com/fruux/sabre-dav/issues/330 all issues on this subject have just been closed while #8510 and #9130 at owncloud/core are still open. That's OK as long as tests do not show that the problems have been solved. In #8510 I just asked for the next OC server version on which the test can be done using the updated Sabre-DAV section.

[DanielRuf]

@VincentvgNn the title of your issue seems to correlate with another problem and does not correlate directler with SabreDAV at all.

[VincentvgNn]

@DanielRuf
Exactly the same error message ... then I should have a different root cause for that.
Or ..... that error message doesn't correlate well enough with the problem at #8510.
I'll test the correlation between the error message and the problem at #8510 again and I'll stop the discussion here.
Thanks for your reaction.

[DanielRuf]

@VincentvgNn Is this the only error message in your log file? Do you log/display all warnings and errors in your log file?

403 just means that you have no sufficient rights (check the chmod and chown rights of the directories, you can set them recursively).

An update of ownCloud does not fix your wrong rights. How did you add this directory? Does this occur with all files/directories?

The error message from SabreDAV in your error log has nothing to do with deleting files or directories.
This does not affect the rights of files and directories.

The allow and deny directives in the .htaccess file just tell the user if he is allowed to access specific files and directories. This has nothing to do with the open_basedir error of SabreDAV.

These lines in your .htaccess file can also be dangerous because anonymous users can also access the files and directories now.
#8510 (comment)

Please take a look at the answer here: http://stackoverflow.com/questions/5081747/htaccess-order-allow-deny-deny-from-all-confused

http://php.net/manual/en/ini.core.php#ini.open-basedir

you can set open_basedir with ini_set() and unset it with php_admin_value open_basedir none

I see no connection between any cURL code and your 403 error (deleting files and directories)

[VincentvgNn]

@DanielRuf
Thanks a lot, you give me useful information.

On the server I log/display all warnings and errors when needed.
I documented the issue when I was using ownCloud version: 6.0.3. By then very often, every minute or so, the next error message appeared:

curl_setopt_array(): CURLOPT_FOLLOWLOCATION cannot be activated when an open_basedir is set at ....../sabre/dav/lib/Sabre/DAV/Client.php#465

Now at ownCloud version: 7.0.0 it's the same, except that #465 changed into #466.
I'm surprised about so many "curl_setopt_array error" messages.

So I find too many error messages on the server while none of them seems to correlate exactly with the "403 Forbidden" error. The 403 error is caused on the server, but is not logged there at all!
Thank you for your correct conclusion.

I will rewrite the issue #8510 with a better title and remove the reference to the error as discussed here.

[DanielRuf]

@VincentvgNn

Because the 403 error does not produce a server error in all cases. But normally it should, but it might be that ownCloud does not log this.

Deleting files has nothing to do with SabreDAV and the developers of it are aware of this issue.
Do the files have the same owner like the php files of ownCloud? They should all have the PHP user as owner.

[VincentvgNn]

@DanielRuf
I have ownCloud running at a Dutch webhost. DirectAdmin control panel, an own (non-shared) IP,
ownCloud using https and encryption. The auto-installer Installatron works flawlessly.
The UID and GID for the "domains" folder are all the same user-id. The ".php" folder also has the same UID while the GID is apache.
The "ownCloud" folder path is within the "domains" folder. Permissions on folders 755 and on files 644.

FYI
I deleted 1 file using the Admin's webinterface at about T23:10:00, just to be sure that something changed on the server.
The message pairs (without correlation to the file deletion) that I regularly find are:

Debug   webdav  
Sabre\DAV\Exception\NotAuthenticated: No basic authentication headers were found    2014-07-30T23:10:42+00:00
Error   PHP 
curl_setopt_array(): CURLOPT_FOLLOWLOCATION cannot be activated when an open_basedir is set at /home/...../domains/....../public_html/owncloud/3rdparty/sabre/dav/lib/Sabre/DAV/Client.php#466  2014-07-30T23:10:42+00:00

The same 2 messages, without any user action, at:
2014-07-30T23:11:05+00:00
2014-07-30T23:12:16+00:00
2014-07-30T23:28:29+00:00
2014-07-30T23:31:23+00:00

So this should be gone when the solution by "evert" has been implemented.
I'll keep an eye on that.

[DanielRuf]

@VincentvgNn This is because the sync client and ownCloud automatically run every x minutes and when the system finds any changes (files / folder deleted ...).

This has really nothing to do with your file problem (403 error) which is solely a problem with the rights of the files and folders. Please recheck the files where the 403 error occurs if the files and all folders above it have the right owner and rights.

Did you add the folder manually or through the ownCloud admin panel?

@DeepDiver1975 @evert @icewind1991 and rest of the ownCloud developers, please can you explain @VincentvgNn the difference between his problem/issue and the issue with open_basedir in SabreDAV?

[VincentvgNn]

@DanielRuf
I understand the difference between both issues and I have closed issue #8510 because the title is quite misleading. I opened a new issue for the 403 error and the .htaccess patch that I need for getting a working system.

Here I mentioned the error messages because they are logged on the server, apparently without any triggering action from the 2 connected client computers. No folder/file changes and (randomly) still so many error messages, that's the only what I see via the admin's web-interface and where I liked to inform you about.
The 2 clients are refreshing each 30 seconds and that may incidentally correlate to the timing of the error messages. It may be a coincidence of server operations and (harmless) connection interrupts.
As far as I remember there were no such error messages when all clients are disconnected for some hours.

[DanielRuf]

That is already known and the people at fruux, the developers of SabreDAV have fixed it #9130 (comment)

Because this starts/runs automatically (cronjob) after visiting the website or something like this (which starts the interval). Nothing special about this. Still, this has nothing to do with any other issue. The script just runs SabreDAV for every x seconds automatically which is normal in many cases.

This htaccess code is not a real solution in my opinion and can make your server insecure. This is just a workaround, but we'll see.

[LukasReschke]

As far I understand this should be fixed with newer SabreDAV versions and so likely with ownCloud 8 / 8.1 as well.

[DanielRuf]

Ok.

But it would be better to work with SemVer and continue development of the major versions.
ownCloud 7.1+ and so on were never released and as I have understand each new major version is an upgrade which is not so easy to install? For me it seems like any minor version is a mjaor version.

Could be 1.8 instead of 8 ;-)
I think many people would welcome a LTS version.

[LukasReschke]

https://github.com/owncloud/core/wiki/Maintenance-and-Release-Schedule