I have a website hosted by FatCow.
I am trying to install the Securimage PHP CAPTCHA on my site by mimicking their quickstart guide, but it failed to work off the bat, so I ran their PHP Test Script on my site to determine the problem.
It threw this error:
The following error occurred when attempting to call session_start():
session_start() [function.session-start]: open(/temp/sess_5e72461407b4ac6283d9897cc49dc4e3, O_RDWR) failed: No such file or directory (2)
Now, I had an issue before surrounding sessions, so I made a temp folder through my FTP client on my domain's home ('/') folder, and set its file permissions to 777. Then I had proceeded to put a php.ini file also in my domain's home folder with the following declarations:
session.save_path = "/temp"
session.cookie_path = "/temp"
What is the issue? Why can't it create these sessions?
If the system doesn't contain a temp/tmp directory, this appears to be a hosting configuration issue, so you'd have to take that up with your provider.
Your solution to create your own temp directory may work, but your path wouldn't be correct. "/" is only the root as perceived by your FTP session because FTP sessions are typically chroot'd. Your home's root directory as perceived by the web server is going to be your home directory, which may be something like /home/my-domain. You can use the PHP getcwd() function to find out exactly what it is.
Related
Before I upgraded my PHP, I used to be able to access all my files from cross domains. I have a file structure like so:
/home
/home/domain1/public_html/index.php
/home/domain1/public_html/include-me.php
/home/domain2/public_html/index.php
/home/domain3/public_html/index.php
This is just a crude example. But the index.php files in domain2 and domain3 used to be able to read the file /home/domain1/public_html/include-me.php, but they can't now - I just get:
failed to open stream: Permission denied
Is there a setting in PHP.ini that i'm missing - so I can access cross domain files again?
there is no crossdomain in action, it seems a problem with permission in filesystem.
are all files available for www user?
It seems like a problem with your doc root settings, Or can be a issue with file permissions on your server.
What was your version and whats the upgraded version?
I wrote a little site with Symfony2 and I want to host it on my WebSpace. I only have FTP access, so I can not access any console/terminal!
Problem is: Symfony cannot create the cache directory properly! There might be a permission problem still?!
These are y steps so far:
Uploading my whole project with empty Cache directory (since I can't clean it due to no console)
Changing permissions of cache and logs directories using my ftp client
unmasking console, app.php and app_dev.php like explained here
Adding my IP to the whitelist in the files: config.php and app_dev.php
Checking the config.php to see if my configuration meets symfony's requirements (they do! no major problems!)
Checking PHP settings: PHP 5.3.3-7, SQLite3 and PDO-Driver there!
Opening app_dev.php/_configurator/step/0 concludes into a RuntimeException:
RuntimeException: Unable to create the cache directory (/var/www/userx/html/MySiteSymfony/app/cache/dev/twig/83/4c).
Opening app.php results in a 500 server error and no log file is being created
Someone an idea how to get symfony working?
Go into the app/ folder click "get info" on the cache folder and set the right permissions (make sure to click "Apply to enclosed folders/files").
Finally changed my provider. Seems like its OS was just deprecated.
i'm working on this joomla site and im not able to upload any extension. if i use normal upload method i get JFolder::create: Could not create directory
Unable to create destination
if i use upload from directory i get Copy failed
JInstaller: :Install: Failed to copy file
i have tried so many solutions found in joomla support forum but none worked for me.
in desperation i even changed tmp ermissions into 777 and now directory permissions (i know its bad) list shows that tmp is writable but show the warning The PHP temporary directory is not writeable by the Joomla! instance, which may cause issues when attempting to upload extensions to Joomla!. If you are having issues uploading extensions, check the '/tmp' and set it to be writeable and see if this fixes the issue. in extensions manager-> warnings
i was wondering whether open_basedir in defect. In my php info file i have
/srv/www/vhosts/domain/httpdocs/:/tmp/ - no value . how can i know open_basedir is in defect? and how can i solve this extensions matter?
The problem may be because upload_tmp_dir isn't set in php.
Look in SITE > SYSTEM INFORMATION > PHP INFORMATION and check if upload_tmp_dir has been set. If not, you need to edit php.ini
On our servers (which use open base dir), the setting is:
upload_tmp_dir=/tmp
This value could be different for you, depending on your server configuration.
Set permission to 777
use full path for logs and tmp e.g.:
/var/www/vhosts/mydomain/httpdocs/tmp
In the Joomla Backend, go to:
Site >> System Information >> Directory Permissions
and see if the "tmp" folder says "Writable"
I had the same problem with one of my shared hosts. The issue was that even though I had set literally everything to 777 (purely for testing purposes), I didn't have file ownership. If this is the case for you too, then you will have to talk to your hosting provider.
I'm building a webpage which has a page allowing users to log in, called login.php. This page is located in the same root directory as my index.html page. When I open up index.html and go to click on the login link, I get this error message:
Fatal error: Unknown: Failed opening required '/websites/testsite.com/www/login.php' (include_path='.:/usr/share/pear') in Unknown on line 0
I have no idea why this isn't working because my index page (and every other page that I have made thus far) links to that same login.php page, which exists in the same directory. Any advise?
If it helps, I'm running Arch Linux with Apache HTTPD 2.2 and PHP 5.3.8. Thank you!
EDIT:
I forgot to mention some extra information. Since I'm working on this website with another person, we each have "local" copies of this website in our user directories. (I say local, but it's really our user directories on the same server which is hosting the public version of this website). Apache is set up to allow user directories (http://thisismytestwebsite.com/~myusername), which is how we view our "local" copies. When I go to click on the login link, the page loads up fine. Everything that we have is backed up using Git, and everything that we have is synchronized properly (we just checked).
Check if the file you're trying to open exists, and that the path is an absolute path.
It's fairly easy to generate a relative path from one file to another:
dirname(__FILE__) . "/../include.php";
Will include the file 'include.php' from one folder up from where the current file is.
__FILE__ is a magic PHP constant, use it!
Probably the apache process is blocked from reading the index.php file due to file system permissions.
Try to adjust permissions (chmod) and ownership (chown) of the file according to your working index.html
I'm trying to install berta (v 0.6.3b) and I get this error:
Warning: session_start() [function.session-start]:
open(/var/php_sessions/sess_a0d6b8422181739d10066fb60cebfe5d, O_RDWR)
failed: No such file or directory (2) in
/hermes/bosweb/web010/b100/ipg.ellieniemeyercom/engine/_classes/class.bertasecurity.php
on line 75 The error seems to happen on line 75 of class.bertasecurity.php (view source code)
What is wrong and how can I fix it?
Make sure that session directory is writable or you can set a path yourself with:
session_save_path
This comment is also useful if you are using above function.
I think the folder containing the session data cannot be accessed by the PHP process.
If you have not touched your php.ini, the default session.save_handler should be files (which means that session data will be stored in a folder on your file system). The value of session.save_path contains that folder, you should check that it exists and its permissions for your php process.
If you're changing the path that is being used for sessions.
You also might consider, fixing this problem by changing session.save_path variable in your php.ini file.
Then you'll be fixing in your configuration file and not only in your script.
Sessions are saved on the harddisk of your server. Most likely your session save path does not exist. Try setting it to a directory that does exist or that you have read/write rights to.
We encountered this problem when migrating a website from a cPanel server to a different host.
The session.save_path was configured in php.ini and .user.ini inside our public_html/ folder, and was presumably overwriting a default path the host would have wanted to use.
We decided the files were not needed at all, just a hangover from the old server, and deleted/renamed them out of the way, and this fixed the problem.