FAQ: Server Issues that can affect how your Jamroom runs
- What are the correct permissions to use for the files and directories in my Jamroom?
- Jamroom is only allowing me to upload a Maximum of 2MB? How can I fix this?
- How do I tell if the PHP on my server is running as a "CGI" or as an "Apache Module"?
- The MySQL Username and/or Password has changed - how do I update Jamroom?
- I am getting a "500 Internal Server Error" when trying to view my Artist Pages - what's wrong?
- I am seeing a "MySQL Error 1030: Got Error 28 From dbhandler" error in my Jamroom - what is causing this?
- I am seeing a "MySQL Error 1040: Too Many Connections" error in my Jamroom - what is causing this?
- I want to change my Jamroom directory and/or domain - how do I do it?
- Jamroom does not seem to be sending out E-Mail - what would cause this?
- I am seeing a "dbQuery() db error 1153: Got a packet bigger than max_allowed_packet" error in my Jamroom - what is causing this?
What are the correct permissions to use for the files and directories in my Jamroom?
The answer to this question depends on how PHP is being run on your server. PHP can work in 2 different "modes" on a server (see the "How do I tell if the PHP on my server is running as a "CGI" or as an "Apache Module"?
" FAQ entry below to determine the way PHP is running on your server), and the permissions needed are different between the 2:
CGI - When PHP is run as a CGI, it means that on every execution of a PHP script in your account, the web server "becomes" your account for the duration of the script, inheriting your accounts permission levels. The server also checks to make sure that none of your files and folders are readable, writable or executable by anyone else but your account. This is the most secure method of running PHP. Usually on a CGI PHP install, the Directory permissions must be set to 755, and the file permissions must be set to 644.
- Apache Module - When PHP is running as an Apache Module, the PHP interpreter has been "embedded" into the Apache process - this allows the web server process to run the PHP script without have to load PHP "externally", offering better performance than the CGI mode, but not being as secure. The problem is that the Web server runs as a different user than your account (usually the web server runs as "nobody" or "apache"), and therefore, any files or folders that need to be modifiable by the web user will have to have their permissions set accordingly so the web user can read and write to the directories and files. In this mode, for the web user to be able to write into a directory it did NOT create, the permissions need to be set to 777 for directories, and for the web user to be able to write or change the contents of a file, the permissions on the file need to be set to 666.
- By default, Jamroom will create directories and files as needed in the jamroom/members and jamroom/media directories - therefore, it is recommended that even on an Apache Module PHP install, the directory permissions be set to 755 and the file permissions be set to 644. This will ONLY work however, if you do NOT change any of the files or folders within the jamroom/members and jamroom/media directories. If you copy or move files inside that directory, then YOUR account will then own the files, and therefore will need to be permissioned to 777 (for directories) and 666 (for files) in order for the web user to write to them.
- Understanding UNIX file permissions can be tricky, especially if your exposure to Linux and UNIX like operating systems is limited. It is HIGHLY recommended to spend some time (maybe 20 minutes) to understand how permissions affect your server (not just Jamroom), as it can really save you a lot of time if something goes wrong with your permissions.
Jamroom Only allows a Maximum Upload Size of 2 Megabytes - how do I change this?
When you are on the “Create Song” or "Create Video" form screens in Jamroom, Jamroom will show you the "Maximum Combined Upload Size":
This value is the Maximum amount of data that can be uploaded via the Jamroom form.
Unfortunately, by default, most PHP settings are set for 2 megabytes (2M). You can contact your system administrator and have them change 2 settings in the master php.ini file (it requires root access):
Have them both changed to “32M” for 32 megabytes and you should be able to upload much larger media files.
Note: Changing these settings will have zero impact on other areas of your system - it is an easy and safe change to make, although you will likely encounter resistance from your web host to change them. If your System Administrator is not comfortable making the change, you can try to do it yourself:
- create a file called “.htaccess” in your jamroom directory (i.e. jamroom/.htaccess) and put the following 2 lines in it (If you already have a .htaccess file in your Jamroom directory, just add these lines at the top of the file):
php_value post_max_size 32M
php_value upload_max_filesize 32M
and try refreshing your Jamroom “Create Song” or “Modify Song” screen and see if it has allowed a larger upload.
If you get an “Internal Server Error” message, or it fails to change the Maximum Combined Upload size, you can try the next option, although this option will typically only work for servers that are running with PHP in “CGI” mode:
- create a file called “php.ini” and place it in your web root directory (i.e. /home/yourname/public_html/php.ini) and place the following 2 lines inside:
post_max_size = 32M
upload_max_filesize = 32M
If you still have no luck getting it to work, you will have to contact your System Administrator and have them modify the master php.ini config file to allow larger uploads, or direct you to the method for changing the necessary values. Jamroom does not control these settings.
||Tip: Some hosting providers do not allow their users to make these changes to PHP - if you have followed these instructions, and are still seeing your Max Upload Size set to 2mb, then you will want to contact your Hosting Provider and have them assist you.
How do I tell if the PHP on my server is running as a "CGI" or as an "Apache Module"?
There currently are 2 common “modes” of running PHP
on a server - as a standalone CGI
program, or as an Apache module. It’s important to understand the mode your server is operating in.
If you log in to your Jamroom as the Master Admin, and go to the Jamroom Tools menu, then click on the "Server Check" link, you will see a button that says "Detailed PHP Information" - you want to click on that button , and you will see the output of the PHP "phpinfo" function. Near the very top of this output you will see a table row called "Server Version" - this will tell you the mode you are running in. If it says "Apache" then your PHP is running as an compiled Apache module, otherwise if it says "CGI" or "suexec" then PHP is running in CGI mode:
The MySQL Username and/or Password has changed - how do I update Jamroom?
Within the Jamroom distribution (and directory) you will find a file called “settings.zip”.
- Unzip this file and it contains 2 files - a “README” file and a “settings.php” file.
- Upload the settings.php file to your web server, and place it in your Jamroom directory.
- Load the settings.php file in your browser - i.e:
- Enter the new MySQL database information in to the form, and save it. That's it!
MAKE SURE YOU DELETE the settings.php file after you have finished since it is a security vulnerability leaving it in place!
I am getting a "500 Internal Server Error" when trying to view my Artist Pages - what's wrong?
The typical cause of this error is that your Webserver is running PHP
” mode, and Jamroom needs to have the user permission set correctly for this mode. You’ll want to edit the jamroom/config/settings.cfg.php file and change the following:
$config['directory_mode'] = 0777;
$config['file_mode'] = 0666;
$config['directory_mode'] = 0755;
$config['file_mode'] = 0644;
After making this change you will want to Regenerate your Artist / Member Pages from the Admin Menu → Tools Menu.
If this does not fix the problem, you’ll likely need to get assistance from your web hosting provider, as the error can be caused by many different server-related issues. You can often consult your Web server error log for further information to the cause of the problem.
I am seeing a "MySQL Error 1030: Got Error 28 From dbhandler" error in my Jamroom - what is causing this?
This error indicates that you have run out of disk space, and MySQL is unable to update or write data to your Jamroom database. You will need to remove some data from your server hard drive to clear up space, or contact the System Administrator of your server for help.
Check out the Error Handling in MySQL section of the MySQL website for details on all of the error codes that may come from your MySQL server.
I am seeing a "MySQL Error 1040: Too Many Connections" error in my Jamroom - what is causing this?
You will receive this error from your MySQL server when it has run out of “connections” that can be made to it. This usually happens because the server you are on has become overloaded, or an application is not properly closing the available MySQL Connections. The solution to this issue is to raise the "Max Connections" setting in the MySQL my.cnf file. This change will need to be made by your web hosting provider, as Jamroom cannot control the number of allowed MySQL connections. The appropriate place to make the change is to modify (or add) the following line in the [mysqld] section of MySQL's my.cnf file:
# * Basic Settings
max_connections = 250
For more details, please see the Too many connections
reference at MySQL.com.
I want to change my Jamroom directory and/or domain - how do I do it?
Change the directory your Jamroom runs in on your server, or changing the domain that your Jamroom runs under is a pretty simple process. Simply follow these steps:
- Log in to your Jamroom Server using FTP, and move the files to the location desired.
- Modify the jamroom/config/settings.cfg.php and make sure the jamroom_path and jamroom_url are correct for your server/domain, and save the file.
- Log into your Jamroom as the Master Admin
- Click on the "Jamroom Tools" menu option and select the "Reset Jamroom Caches" option. Leave the options at default on the Reset Caches page, and press the "Reset Caches" button.
- Click on the "Jamroom Tools" menu option and select the "Profile Regenerator" option. Make sure the "Fast Rebuild" option is NOT checked, and submit. This will rebuild all of your profile pages with the proper new path and domain.
- If you are using the Jamroom Progress Meter, you also need to edit the cgi-bin/uu_default_config.pm file and make sure the URL and Path are correct. You can test if it is correct from the Jamroom Tools -> Server Check section.
That's it - your Jamroom will now be running within the new directory and/or domain name.
Jamroom does not seem to be sending out E-Mail - what would cause this?
This is perhaps one of the most common questions and issues that Jamroom site owners run into, and unfortunately it has many different causes, with the problem rarely linked to Jamroom. If you are not receiving Jamroom E-Mails (i.e. signup validation, new artist signups, etc.), then you'll want to follow these steps to help solve the issue:
- First, make sure it isn't something as simple as your e-mail being caught in a Spam filter - disable all Spam filtering (if you can), and try to use a non-free email address. Both Hotmail and Yahoo mail are notorious for not delivering legitimate email that they "think" is spam.
- Next, make sure that SMTP is configured correctly for your server. Jamroom utilizes the PHP mail function, which in turn relies on the underlying SMTP (email) server that runs on your web server. Start by visiting Into DNS and run the "DNS report" on your domain name. You should not see any errors in the "mail" section of the report. Note that many domains still do not utilize the "SPF" record section, so it is fairly normal to fail on this section, however certain free e-mail providers (namely Hotmail and Yahoo) will reject email from a domain that does not have a properly configured SPF record. You will need to have your hosting provider configure an SPF record for your domain.
- Next, we want to make sure that PHP is configured properly to "talk" to the underlying SMTP server. We can do this with a simple test. Create a small file called "emailme.php" which contains the following lines:
mail('firstname.lastname@example.org','test subject','test message');
echo "email sent!";
And save it in your Jamroom directory. Make sure and replace "email@example.com" with your actual email address - preferably an address you know works correctly, and is not a Hotmail or Yahoo email address (if you haven't created an SPF record). Next, run the small script from your web browser:
If you do not receive the email message, then the problem is that PHP is not configured correctly to "talk" to your SMTP server, and you will need to have your hosting provider verify the PHP configuration. You can consult the PHP manual
- Finally, make sure that the e-mail address you have chosen for the following Jamroom Config items is a proper e-mail address:
- Jamroom Config → Email Settings → Return E-Mail Address
- Jamroom Config → Signup Settings → Admin E-Mail Address
- Admin Profile → Email Address
Since Jamroom will use these email addresses as the "From" address when sending e-mail. If these e-mails are not valid e-mail addresses, most receiving systems will reject the e-mail messages.
I am seeing a "dbQuery() db error 1153: Got a packet bigger than max_allowed_packet" error in my Jamroom - what is causing this?
This error indicates that the packet size attempted to be used by Jamroom exceeded the max_allowed_packet setting for your MySQL Database. To resolve this, you will need to contact your hosting provider and ask them to increase this setting to something larger than 1 MB (the default setting for MySQL).
If you run your own server, you will need to edit your /etc/my.cnf (or wherever your mysql config file is, i.e. /etc/mysql/my.cnf) and change the max_allowed_packet setting, and restart your MySQL server. The changes will not take effect until your MySQL server has been restarted.