solved Reinstalled back up and get error - CRI: Unable to copy skins/jrProJam/index.tpl

I reinstalled backup of my sql database with a new password and the sql backup database installed great. Next installed the backup of my jamroom directory files and the template i'm currently using is projam 5. updated the database info in the config.php file. I deleted the data/cache/jrCore files and the data/cache/jrProJam files as well. Tried to access my website and i get this error below
CRI: Unable to copy skins/jrProJam/index.tpl to template cache directory: data/cache/jrCore please help.

Please Note: I have also tried by copying the index.tpl file to the data cache core directory my self and then it gave me another error saying the same thing but for the header.tpl file instead, so i copied that and added that as well to the data /cache/ core file and then it gave me a blank page. Also, i event tried by reinstalling all directory backup files again and leaving all cache files as is and it also gave me a blank page trying that as well. Please Help Iam just trying to get my site up and running.
updated by @syrus: 03/07/14 03:11:35AM

try deleting everything in the:
/data/cache

directory except maybe the index.html file. so your cache directory looks like this
/data/cache/
/data/cache/index.html

Then run the integrity check. If you cant get to it because the admin panel wont show.

rename
/repair.php.html

to
/repair.php

and call it YOUR-SITE.com/repair.php

That will let you run the integrity check.

I deleted all the folders in the data/cache folder and left the index.html and it still gives me the same error. Im not able to log in to the site at all so i use the repair.php to run the Jamroom Database Repair check and the error is still there afterwards. This is what the repair said below, everything is okay with the repair database.

Jamroom 5 Database Repair
repair tables beginning
REPAIR TABLE jr_jraction_item - OK
REPAIR TABLE jr_jraction_item_key - OK
REPAIR TABLE jr_jrblog_item - OK
REPAIR TABLE jr_jrblog_item_key - OK
TRUNCATE TABLE jr_jrcore_cache - OK
REPAIR TABLE jr_jrcore_cache - OK
REPAIR TABLE jr_jrcore_count_ip - OK
REPAIR TABLE jr_jrcore_form - OK
TRUNCATE TABLE jr_jrcore_form_session - OK
REPAIR TABLE jr_jrcore_form_session - OK
REPAIR TABLE jr_jrcore_log - OK
REPAIR TABLE jr_jrcore_log_debug - OK
REPAIR TABLE jr_jrcore_menu - OK
REPAIR TABLE jr_jrcore_modal - OK
REPAIR TABLE jr_jrcore_module - OK
REPAIR TABLE jr_jrcore_pending - OK
REPAIR TABLE jr_jrcore_pending_reason - OK
REPAIR TABLE jr_jrcore_play_key - OK
REPAIR TABLE jr_jrcore_queue - OK
REPAIR TABLE jr_jrcore_setting - OK
REPAIR TABLE jr_jrcore_skin - OK
REPAIR TABLE jr_jrcore_temp - OK
REPAIR TABLE jr_jrcore_template - OK
REPAIR TABLE jr_jrfollower_item - OK
REPAIR TABLE jr_jrfollower_item_key - OK
REPAIR TABLE jr_jrmarket_channel - OK
REPAIR TABLE jr_jrmarket_install - OK
REPAIR TABLE jr_jrmarket_system - OK
REPAIR TABLE jr_jrpage_item - OK
REPAIR TABLE jr_jrpage_item_key - OK
REPAIR TABLE jr_jrprofile_item - OK
REPAIR TABLE jr_jrprofile_item_key - OK
REPAIR TABLE jr_jrprofile_profile_link - OK
REPAIR TABLE jr_jrprofile_quota - OK
REPAIR TABLE jr_jrprofile_quota_setting - OK
REPAIR TABLE jr_jrprofile_quota_value - OK
REPAIR TABLE jr_jrsearch_item - OK
REPAIR TABLE jr_jrsearch_item_key - OK
REPAIR TABLE jr_jruser_cookie - OK
REPAIR TABLE jr_jruser_forgot - OK
REPAIR TABLE jr_jruser_item - OK
REPAIR TABLE jr_jruser_item_key - OK
REPAIR TABLE jr_jruser_language - OK
TRUNCATE TABLE jr_jruser_session - OK
REPAIR TABLE jr_jruser_session - OK
Database Repair complete - DELETE THIS SCRIPT!

You do have the jrProJam skin uploaded right?

Try going into phpmyadmin and in the settings table changing the skin back to the default jrElastic skin.

Yes im using the jrProJam. Can you please give me a little more details on how to change the skin back to elastic skin default from the phpmyadmin settings. I understand how to get to the settings in the phpmyadmin, just need to know a little more details on what to do next once im in the settings?

Take a look at this video:

"Change the Active Jamroom Skin via PhpMyAdmin"
Change the Active Jamroom Skin via PhpMyAdmin

Ok i manage to change the skin back elastic from the phpmyadmin, the exact same way as showed in the youtube video and i get the same error but with the elastic template instead. It says - CRI: Unable to copy skins/jrElastic/index.tpl to template cache directory: data/cache/jrCore.

If i just start all over again from scratch, since i have no members, can you please tell me how may i prevent this from happening to me again, once my site is open and i have a lot of members and i may have to restore my database from a backup? Is there any reason for this error and how i can prevent this from happening again if i start my site over from scratch? I notice that someone else encounter this same error as well in this article here
http://www.jamroom.net/the-jamroom-network/forum/installation-and-configuration/5799/successful-jr5-install-but-error-immediately-after
updated by @syrus: 02/02/14 10:54:49PM

I cant answer that question because I don't have enough information. The reason in the post that you link to is that the web server was unable to write to that directory.

Is that the same issue on your server? If so the way to fix it is to change the permissions on the server to give apache write access to that folder.

Check your server settings in your ACP it should tell you if this is an issue or not.

I manage to get it back up now thanks so much for your support and help. I would like to mention that my server default file settings is 755 instead of 777 so i had to change data/cache, data/config, data/log/ and data/media to 777 in order for the script to work. This is what i had to do when i first installed it as well. Before i had to do back up, everything was working great. The reason I had to do the backup was because i made some changes in the style section of the jamroom projam5 template by changing some colors of the links. Once i changed some colors of the links, the blog button tab, youtube button tab link, soundcloud button tab, in the user profile got smaller, including the buttons on the news module tab,blog module tab and the button on the todays artist tab as well. So i reset the colors back to the original colors and the buttons remained the same and the colors would not revert back, only some of them. I performed skin cache, module cache, browser cache everything and use all the other tools in the admin area and nothing worked. I did have a problem deleting files before, but that has been fixed. I no longer have that problem now.

That's great news. well done.

I experienced something similar here:
https://www.jamroom.net/the-jamroom-network/forum/installation-and-configuration/5799/successful-jr5-install-but-error-immediately-after

Thanks for the reference post @iLoveHouseMusic, here is what i found out yesterday and maybe it can help you or others that may have this issue in the future, your server may be setup like mines. I got the cache copy error because the files data/cache,data/logs,data/media and data/config were set to 755 instead of 777
now, here is what made the difference, Michael explained in the above message, you must also delete all the following folders in /data/cache and leave the index.html. The reason this helped the issue, instead of just deleting the cache from cache/jrCore and data/cache/my skin, is because all the cache folders were set to 755 in the cache folder as well. So by deleting all the cache folders inside the cache folder is what actually fix the issue.

@michael
I receive this error soon as I did the update for the core modules in the admin module update area. Below is the error i received when i did a system check.
"diff binary is not executable by web user /usr/bin/diff"

Can you please tell me how can i find this folder "diff binary" to make executable?

I have full root access on my vps and php.ini access as well. Thanks @michael for the help once again i appreciate your support.

I understand now, that all the issues i'm having is from my vps server being setup with 755 instead of 777 and the 755 is not allowing anything to execute, this is where all the issues are coming from, its the permissions for different folders that's not being set, due to the settings of permissions how my server is configured. You were absolutely right, its a permissions issue. Also, I could not delete some jamroom files or change the permissions on ftp or with the regular file manager in cpanel, but i was able to delete them with the legacy file manger in cpanel. Which is weird as well.

This errors means the the binary located here:

/usr/bin/diff

cannot be executed by the account that is running on your web server (i.e. the apache account).

Most likely you have the open_basedir restriction enabled in your php.ini file:

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

You will need to disable open_basedir and restart your web server.

Hope this helps!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

Thanks @brian, I contacted my web host support and told them the issue you mentioned and they did exactly that and it worked. The system checks is now all green. Thanks a lot you guys. I really appreciate your help and support 100%.

No problem - glad to see it's working

Thanks!


--
Brian Johnson
Founder and Lead Developer - Jamroom
https://www.jamroom.net

I have one question and an update referring to the problem i posted above with the permissions issue and not being able to delete the cache files on my server. As I faced the same problem today and yesterday again,again, and again I finally notice what cause the file permissions to change of the folders that wouldnt allow me to delete them or change permissions. The problem is basically my server/me owns all permissions to all the files I have uploaded via ftp, which allows me to delete or change permissions of all the jamroom files I uploaded via ftp, but when jamroom creates new files such as update module files, cache files and update of themes/template files. These files are then uploaded/added by jamroom system and not by me via ftp. So the problem starts, when the newly created files are uploaded by jamroom and not ftp by me, so then they are added to my directory with 99, "meaning nobody owns them" and with the permissions of 755, which wont allow anyone to delete them or change permissions to any of these files, cause they was not uploaded by me via ftp. If you guys have any resolution to this? I will be so happy for the help honest.

Brian has a much better knowledge of server stuff than me, but whenever i encounter an issue on my server where I cant delete something via FTP i go in via SSH and do:


you would use whatever permissions you need. 777 is ok for me because my site is totally offline. use whatever your sites permissions are supposed to be.

The correct solution will probably be to set the webserver and the FTP user into the same group, but I don't know the steps to do that, so you might need to ask your hosting company or someone specalized in server setup.

Ok thanks, I really appreciate your support and help.