Unable to upload images, updating database.....failed (Apache logs cannot be opened either)
-
Server
- FOG Version: 1.3.1
- OS: Ubuntu Server 16.10
Client
- Service Version:
- OS: Win 7 Pro x64
Description
I was able to upload one image to my Fog Server yesterday, I tried uploading a new image today and get 100% completed - then it fails with “Updating database…failed”. This is a single node environment. No settings have changed from yesterday as I am the only one who uses this. I also check the Apache logs and am unable to look at them today “Unable to open file for reading”. I was able to open these yesterday.
Any ideas?Thanks
-
Update 2:
After running the imaging process again, the database was updated with no errors and completed. I will try again tomorrow to see if I have the same issue. As of now, updating to 1.3.3 solved my issue.
-
I updated to Fog 1.3.3 and am now able to view Apache logs. I will try to push an image again.
Just for reference this was posted in the log several times:
[Wed Jan 18 09:46:16.519255 2017] [php7:warn] [pid 3848] [client 192.168.220.67:36224] PHP Warning: fopen(/var/log/apache2/error.log): failed to open stream: Permission denied in /var/www/html/fog/status/logtoview.php on line 60, referer: http://192.168.220.175/fog/management/index.php?node=about&sub=logviewer
-
Update 2:
After running the imaging process again, the database was updated with no errors and completed. I will try again tomorrow to see if I have the same issue. As of now, updating to 1.3.3 solved my issue.
-
The apache error logs issue is a known thing that I cannot really do anything, from the installer side, to fix.
This is due to log rotate changing the permissions on the apache log files every so often (whatever that timeframe/sizeframe maybe). The logrotate daemon is changing the permissions to settings that are unreadable from the GUI. (I think it’s setting the files to 644 when to read the files they should be 655 at a minimum (though 755 is probably a safer bet).)
-
@Tom-Elliott Is there a command to run which will temporary fix or restore the appropriate permission settings to these files if I run into this problem in the future?
-
@cadams You’d have to make the changes to the logrotate.d configuration in regards to apache. I don’t know what the file looks like, but if you can post the ‘default’ I can probably get you what you could change it to to fix it outright.
-
@Tom-Elliott I am receiving the same issue today. I’m not sure where to pull the ‘default’ you’re looking for. If you’d point me in that direction I’d be happy to post.