I've found several places where this issue has been posted around the web, however the solutions given are not working for me.
I've set my storage directory permissions to 777, double checked that my user and group are set (vagrant:vagrant), cleared cache and I still get this error.
I'm running Laravel 8 on Homestead/Vagrant/VirtualBox with PHP 8.
I have other projects using this same setup, the only difference is they're running PHP 7.4, and they work great. I cannot figure out how PHP 8 could be causing this, but it's the only difference I can see.
Related
I'm having a problem with setting up a local Sugar instance on localhost in a vagrant VM. I created a local host instance from a backup file, which worked well the first time I tried it. But, after restarting vagrant about two weeks later, I get an empty grey screen and an error in the PHP log:
PHP Fatal error: Uncaught Error: Class 'Ramsey\\Uuid\\Uuid' not found in /vagrant/src/Cache/Middleware/MultiTenant/KeyStorage/Configuration.php:44
I deleted this instance and created another one from a different backup file. Again, it worked well initially. But after restarting vagrant today, I got the same error. This time, I looked into this error in more detail and managed to fix it by changing the use statement in Cache/Middleware/MultiTenant/KeyStorage/Configuration.php to "use Rhumsaa\Uuid\Uuid" (https://github.com/ramsey/uuid/issues/217). But now I'm getting a new error:
Uncaught Error: Class 'LoggerManager' not found in /vagrant/include/entryPoint.php:121\nStack trace:\n#0 /vagrant/index.php(17): require_once()\n#1 {main}\n thrown in /vagrant/include/entryPoint.php on line 121
This leads to 3 issues that confuse me at this point:
1) Why is this error thrown when a LoggerManager class does exist in include/SugarLogger/LoggerManager.php?
2) It seems that there is a more fundamental problem with this instance that prevents it from finding existing classes. I was thinking it might be a permissions issue and ran the commands to set the required permissions (using vagrant:vagrant instead of apache:apache), but it had no effect on the error. What else can I try to troubleshoot this?
3) Why did this instance work well initially and started throwing errors after restarting vagrant?
Thank you for any help!
I haven't been able to figure out what the problem was, but it went away after I set up a new local instance using a backup of a newer Sugar version.
I am keep getting this error message when I run "meteor" on cmd on windows.
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Unexpected mongo exit code 100. Restarting.
Can't start Mongo server.
MongoDB had an unspecified uncaught expection.
This can be caused by MongoDB being unable to write to a local database.
Check that you have permissions to write to .meteor/local. mongoDB does not support filesystems like NFS that do not allow file locking.
This happens right after I downloaded meteor and created my first project. I already tried resetting the project. I saw people recommend removing the lock file in db folder. However, when I check .meteor/local/db, its empty.
Try to reset Meteor.
-Meteor reset
-Meteor
Update Meteor.
-meteor update --release 1.4.0.1
Your username could be the problem.
In my case, it works fine when I moved the project's folder to other user's folder.
Check that you have permissions to write to .meteor/local. mongoDB does not support filesystems like NFS that do not allow file locking.
This is probably your problem.
If you use GitHub for your project, I'd strongly recommend you clone your project from GitHub into your Documents directory, and try running meteor again from there.
Don't copy your existing folder to Documents, because you'll just copy the existing busted permissions. If you're not familiar with the Windows folder permissions model, you're going to have a bad time dealing with this problem.
I have a CodeIgniter setup that has been running fine for the past 2 months and recently I keep getting:
CodeIgniter error- unable to connect to database using the provided settings
I've recently added a new domain that has a landing page for the database login (zPanel), but I don't see how that could have caused a problem--maybe the page keeps getting directory attacked or something, but I'm not sure.
Is there a way to check if this is the problem through logs? I'm at dead ends with this problem, as when I restart the server (DigitalOcean) it works fine again.
Really not sure. If anyone else has had a similar problem, I'd love to hear your solution.
Thanks.
I think your mysql is going down so Codeigniter can't connect to your database settings.
Please login to SSH and check processes by "TOP" comment. See what is using resources ram or cpu.
And check your mysql conf settings, be sure that everything written if its empty it will cause alot of problems.
Some example :
http://www.maxwhale.com/how-to-optimize-mysql-for-1gb-memory-vps/
I have a Laravel 3 project, running on a plesk 11.5 CentOS 4(dedicated). It used to be on an IIS server, but i had to migrate it to plesk, since the company i'm working for is dumping the IIS server. Everything seemed to be running smoothly, until i logged out from my application, at first i got a WSOD (white screen of death), then i enabled php error reporting, and this is the error that was displayed:
Fatal error: Cannot override final method Laravel\Database\Eloquent\Model::sync()
This is a very strange error, since i have no method called Sync in any of my classes, and needless to say that there was no such error while the project was running on IIS.
I tried several different combinations of session/cache drivers, the only one that seems to be working is the APC driver.
When i have the APC driver enabled for cache and session, the above Fatal error is not displayed and everything works correctly. The PROBLEM is that i have given the Session Lifetime a value of 60(minutes) but it is completely ignored, meaning that the user is logged out after 2 or 3 minutes.
I've been to the Laravel IRC channel with this issue, some people kindly suggested to tweak the APC memory and ttl (time to leave) settings, but with no luck unfortunately :(.
Here are some APC settings from my server configuration:
apc.gc_ttl 3600
apc.shm_size 1024M
apc.shm_strings_buffer 32M
I desperately need help if anyone has any to offer! This is for a live running project and i need to find a solution asap.
I had the exact same issue and couldn't find a solution. I was going round in circles trying to figure out what on earth was going wrong.
I finally came across this post:
Fatal error: Cannot override final method
You need to make sure that the apc.include_once_override setting is set to 0. In your apc.ini file set like so:
apc.include_once_override=0
This error seems to be caused by caching of included classes.
I solved the problem after looking around the plesk panel.
The problem was that i had "Run PHP as FastCGI application" selected.
I switched to "Run PHP as CGI application" and everything works perfectly.
I'm not sure what the exact source of the problem was, only that FastCGI triggered the error.
EDIT - HUGE ERROR ON MY PART
I found another site that had the issue that I knew was not on the same server. Then I realized that the original site with the issue was also on a different server and had not been moved over completely yet. The server in question was actually a Plesk Parallels' server and the issue was caused by a patch applied to the server over the weekend due to a security update. This server did have the file path and I just had to chmod it to 777 instead of 77x for it to work. I apologize for the confusion and thank everyone for trying to help. +'s for all. :)
Original Post
I have a website on a shared hosting server (also mine) that since yesterday started giving me this error:
Warning: session_start() [function.session-start]: open(/var/lib/php/session/sess_678cf69f0f17b87c52136ee0280d23cc, O_RDWR) failed: Permission denied (13) in /var/www/vhosts/domain.net/httpdocs/index.php on line 1
I've checked /usr/lib/php.ini and /usr/local/lib/php.ini to see where it is set and both say it is set to the /tmp directory, which is where it should be set and always has been. The /var/lib/php/session directory never even existed. I did create it and give it 777 permissions but that did not help. Though the bigger issue here is why did it change to begin with. There is no .htaccess file for this site and I cannot find this being set anywhere on the site itself either.
This is the ONLY site on this server with this issue, telling me its something local to the website. I just cannot figure out what. So my question is this: what should I look for to check the session save path settings for an individual site on a shared hosting environment to find out why it suddenly changed for this one client?
FYI, I am running a WHM server.
Thanks
session_save_path(realpath(dirname($_SERVER['DOCUMENT_ROOT']) . '/../tmp'));
You need to add the above code before starting the session.
You don't appear to have write permission to the /var directory on your server. This is a bit weird, but you can work around it. Before the call to session_start() put in a call to session_save_path() and give it the name of a directory writable by the server. More details here
I found another site that had the issue that I knew was not on the same server. Then I realized that the original site with the issue was also on a different server and had not been moved over completely yet. The server in question was actually a Plesk Parallels' server and the issue was caused by a patch applied to the server over the weekend due to a security update. This server did have the file path and I just had to chmod it to 777 instead of 77x for it to work. I apologize for the confusion and thank everyone for trying to help. +'s for all. :)