I see that Dom's sessions are working now.

While this is not a problem with moodle software, sine many folks have suffered from session problems (including myself, person1, person2, person3, person4, person5, person6) I pulled the information I could find together.

1) Change the permissions of data/sessions to allow moodle to write to the folder. In the last resort use "777" which means that everyone can write to the folder, and should only be used if the data folder is above or in the same folder as "public_html" }
(the folder which is web accessible). If you have access to your server then this will probably mean using the command chmod on the data folder like this (the path is only an example)

chmod -R 0777 /home/username/data/

if not then you can use a ftp program
To do this use right click on the folder and one of the options will usually be "change permissions". Try 777 and see if the problem is
cured. (Later you can reduce the number and the level of permissiveness, by trial and error - 700 is recommended) This often works

2) If the permissions can be set to 777 (everyone can access and write and execute to the folder) then it should not matter, but (see suexec below) sometimes it is not possible to set very loose permissions allowing anyone and his dog to write to the data/sessions folder.

In this case, it is importand that server knows that moodle is the owner of the data/sessions folder and that means that the username under which moodle is running, and the owner of the folders is one and the same. Normally moodle (which is a php) program runs under the username "apache". Apache is often the name of the web-server, and php runs as a web server program. If this is the case, then the owner ship of data/sessions should also be set to apache. With the command (again the path to the data folder is only an example)
chmod -R apache:apache /home/username/data
This can not usually be done via FTP so if using "777" is not working for you and you do not have access to your server, you are going to have to ask for the cooperation of your host. IF you are not operating your own server, ask your host the ownership of the folders and the username under which moodle is running and ask that they make them match.

3) If you have problems, sometimes it helps to create the folders yourself using ftp, rather than let fantastico (an automated moodle installer which may result in session data path problems  on some servers), for instance, create them for you. This can have the opposite effect, if say you are logged on as root to your server, and you create the folders as root, because then moodle as apache
will not be the owner of the folders. On a shared host however, using ftp to create data, data/sessions and data/cache is worth a try.

4) If your server is running "php suexec" then this will prevent the use of very permissive permissions (e.g. 777) and make it critical that the owner of those folders is the same as username underwhich moodle runs. Ask your host if they are using "php suexec." Sometimes, conversely, it has been necessary to recompile using suexec, but no one expained why.

5) Very occasionally there will be extra security software, such AppAmor which is bundled in SuSE Linux, and SELinux which is in Fedora Core, in operation on the system, which does not like it when php writes a lot of files to the disk. Find out if any  such security software is in operation by asking your host and change the configuraton of this security software. 

6) As mentioned in the installation instructions, when php is operating in "safe mode" it may not be able to write to the sessions folder. You can find out if it is operating in safe mode by looking at "php info" or asking your host. If it is then either ask them to turn off safe mode, or set up a data/sessions directory that works for you.

7) Check that the sessions save path is going to the write place in php info where there will be a setting session.save_path and apparently some people have found the solution in changing their php.ini file to set the session.save_path to the right place
particularly when using a windows server with an icorrectly configured php.ini

There are all sorts of other reasons why there should be problems with sessions, although most of these will result in a different error message:

1) Having the same cookie name when using more than one moodle at the same time. The solution is to rename the cookie for each of your moodle installations to something unique in the admin detailed sessions.

2) Having the wrong ULR for your site in moodle/config.php, particularly be aware that you should be consistent with the use of "www.domain.com" and "domain.com" if you are going to access yoursite without the www then do not put it in the URL setting.

3) If your apache serve is giving out incorrect or "expired cookies". This will require you to reconfigure your appache server.

4) If you really have run out of disk space, in session data directory. But since session data files are small, since moodle 1.3 stopped using the global session data folder this is unlikely.

5) If you have specified $CFG->dataroot, the path to the data folder incorrectly.
5.1) Avoid trailing spaces in the path!
5.2) Make sure you have the first slash in the path!
5.2) If the path is wrong you may not realise immediately, because, in this case the session data folder will sometimes default to the global (system-wide default) directory which is often /tmp. The system-wide default as well as your setting is shown in php info. See Penny Leach's post here.

If you can not get session information to save to the data/sessions folder, then try turning dbsessions on using the Admin detailed settings dbsessions. This will mean that session information is stored to the database not to a folder on the disk. If you can not log in as Admin to make this change then use php myadmin or a client side database administrator like navicat or mydbstudio to change the mdl_config->dbsessions to on. This is not recommended as a long term solution for small moodle installations, and changing the database directly always involves risk.

Tim

What lessons can be learned .......  Like Martin says this is great for the Moodle documentation.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

As a risk manager lets look at the facts as they are and can we as a community learn from them.

1)  Moodle is now very complex to both in stall and maintain and administer for anyone who has little or no IT experience in installing and  managing systems. In today's consumer environment - one "expects" to hit the install button - an icon appears and all is well and running sweetly.   1st misconception .......

2)  How many times have we seen "teachers" try and install Moodle on a "hosted system" (because in many cases it is a 1 or two button strep) to get Moodle running, and then seen a posting on Moodle.org seeking help.

3) Moodle is both simple and complex .... simple in real terms to a techie  who loves to get their hands dirty and demonstrate how good they are, and complex that when the wheels come off for many of us it is the "LAST STRAW".  2nd misconception - generally it is not a Moodle application fault - but something that someone has done wrong and there are 1,000's of combinations. Martin and the team have done a great job, and yet there are issues to resolve, but issues like this are not grated through poor programming - just inadequate planning, time, skills and knowledge.

4)  Many cheap hosting companies are GREAT at supporting your environment for your humble $5 - $20 per month ......  misconception # 3 .......   either use a Moodle Partner, install your own server and develop expertise  / employ experienced support engineers, or find a Moodle user close to you who has their own server and buy their expertise.

5)  If you program is placed up at the last minute and you have not tested it in the production environment at least (the very minimum) a week before, then purely and simply you are not a professional educator - pure and simple .....  Sure if you have had a system up and running for say 12 months and all runs smoothly and you have uploaded many times before on the night before your programs are due to run, you will generally get away with it ..... but sooner or later it will all crumble and bring you to your knees.

6)  Undertake PROFESSIONAL DEVELOPMENT ... Learn about how Moodle works, how to administer it, how to maintain it , lean about the operating system you deployed it on,  etc etc  ..  it takes TIME and lots of it  ....  Moodle IS NOT FREE ....... if nothing else you will invest large amounts of time, and if you don't have the spare time, don't get involved in it .  All Moodle allows you to do is deploy a feature rich CMS environment at a zero software cost and zero licence fee ...... zero maintenance cost ..... that is it ...... pure and simple ......  Everything else you HAVE TO PAY FOR ...... hardware, bandwidth, hosting etc  .... the list goes on .....  so in a small environment you may save approx $5,000 per year and in a  larger environment  .... over $250,000 per year in the big side of towns fees – in the scheme of your size the saving is small compared to the overall coat of your envioronment ......  misconception # 4   to run Moodle  is free or at the very least a petty cash application for a business / school / institution.

I am going to step out of the square and be radical.  Is it now a time to introduce "paid support" for Moodle and questions like this within Mooodle.org?  Nothing radical, but if one has a technical query and seek the help of the community, and the community puts time and effort into supporting the community, people are using the community to substitute engaging their own technical support personnel.  What I would suggest is a $5 or even a $10 support ticket for each support thread started on Moodle.org, maybe payed for via paypal with the funds going back into Moodle for further development, maybe in the further development of the Docs project - or whatever. I am not talking here about general education discussions etc, or moodle improvements, but technical queries where people like Dom are screaming for help. 

food for thought