Hello,
I have this warning with my vhost when i list files on my Amazon S3 test bucket.
I have safe mode off in this vhost so i think that warning is about open_basedir settings.
Any idea about this?
Thanks

warning: curl_setopt() [function.curl-setopt]: CURLOPT_FOLLOWLOCATION cannot be activated when in safe_mode or an open_basedir is set in /var/www/vhosts/drupalsandbackup.homelinux.net/httpdocs/preprod615/modules/backup_migrate/includes/S3.php on line 1195.

CommentFileSizeAuthor
ScreenHunter_01 Dec. 21 22.14.gif12.38 KByann_riviere

Comments

Mike Dodd’s picture

been looking into this today quite heavily, it seems to be influenced by the size of the file/files.

I am using this in addition to backup_migrate_files and everything works fine on small files.

I have checked my safe_mode and open_basedir settings in the php.ini file and the virtual hosts conf folder and set both to noe but the problem was still occurring

I am trying to backup 2gb of files to S3

Since then I have increased my max execution time etc but to no avail (it doesn't appear to be working and I think cron is hanging on this error.

I have since commented it out and re ran the script. Cron is still running (30 mins now) but no error. Not sure if it will work but seems to be doing something If this does work I will un-comment this line and hopefully it will run but just with an error, will let you know.

Mike Dodd’s picture

I can confirm with this line commented out everything works fine.

not sure if will still work with the line in though?

ronan’s picture

Status: Active » Postponed (maintainer needs more info)

I don't know either since I didn't write the S3 library myself. The directive seems to allow curl to follow redirects, but I've no idea if the S3 API ever issues redirects, so I don't know what the danger of removing it is. It is very strange that you're receiving safe_mode errors when safe_mode is turned off. Have you been able to find any info on other people having this issue with other uses of CURL via php?

munkyonline’s picture

Version: 6.x-2.2 » 6.x-2.4

I'm having the exact same problem with 2.2. Cron is reporting that error when the backup fails to Amazon S3. I also have safemode off and i'm not sure about open_basedir settings - I presume that's something in the module?

This message is also displayed when I visit the page for the list of the files. What's strange is the backup worked 4 times to S3 about 10 weeks ago.

I just upgraded to 2.4 and the issue is still there (there is nothing being backed up to S3). Since upgrading to 2.4 the error is no longer displayed as a cron error but when when visiting the list of files has changed slightly to:
curl_setopt() [<a href='function.curl-setopt'>function.curl-setopt</a>]: CURLOPT_FOLLOWLOCATION

I can backup locally on the server and download no problem, its only a small database of around 700k.

Did anyone find a fix for this?

munkyonline’s picture

Actually I was wrong, it appears the S3 backup is working fine now so the upgrade to 2.4 worked. Just getting the error when visiting the list page now.

KHofmeyer’s picture

I am getting the same error only on the list page but backup is working fine to s3.... Subscribing...

akalata’s picture

I was getting this error on my Mediatemple (gs) service. Disabling open_basedir through php.ini removed the error, though I'm not sure if that was necessarily a good thing to do.

deanw’s picture

Try using the older stable version of the s3.php file. (amazon site offers both a stable and a dev version of the download)

I was getting this same error. I was using the dev version of the s3.php file that needs to be copied to the backup_migrate/includes file. The s3.php file was included with backup and migrate for Drupal 6. After replacing the dev s3.php file with the s3.php file I pulled from the Drupal 6 version of the module the error went away.

ronan’s picture

Status: Postponed (maintainer needs more info) » Fixed

Thanks, I've made a note to use the stable version in the readme.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.