Happens in the trunk as well.

This happens for me as well on current master.

Comment from the forum (not checked myself yet):

SOLUTION:
Use text entry box on the start menu to type akonadi
Select Akonadi Console
Select Kmail Folders, configure natively

The application was looking for current in /home/jim/.kde4/share/apps/kmail/mail/ but they only exist at the next level ie
/home/jim/.kde4/share/apps/kmail/mail/Web stuff.
Changed to point to a random sub-folder and now fully functional.

Happening with me as well. 
KDE 4.6.4
Kmail 4.6.0

The comment #3 doesn't help : I have configured in Akonadi console my previous maildir. Now, Akonadiconsole  sees the Mail tree but absolutely no email !

I confirm Frédéric's comment #5, happens on my system, too.
Going to attach output from stdout/stderr.

Created attachment 61282 [details]
Ouput on stdout/stderr when error occurrs.

Error occurred on a Gentoo Linux system with KMail 4.6.0 and KDE 4.6.3 and Qt 4.7.3.

Additional information: When the message box appeared, I used gdb to attach to the kmail process to get this backtrace:

#0  0xb76e7424 in __kernel_vsyscall ()
#1  0xb5eb6bac in poll () from /lib/libc.so.6
#2  0xb45bef90 in g_poll () from /usr/lib/libglib-2.0.so.0
#3  0xb45b2b16 in ?? () from /usr/lib/libglib-2.0.so.0
#4  0xb45b2dfd in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#5  0xb61f0ba6 in QEventDispatcherGlib::processEvents (this=0x9052ae8, flags=...) at kernel/qeventdispatcher_glib.cpp:422
#6  0xb6500a2c in QGuiEventDispatcherGlib::processEvents (this=0x9052ae8, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#7  0xb61bf5ff in QEventLoop::processEvents (this=0xbfbc6a80, flags=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece.
) at kernel/qeventloop.cpp:149
#8  0xb61bfa25 in QEventLoop::exec (this=0xbfbc6a80, flags=...) at kernel/qeventloop.cpp:201
#9  0xb69ca7dc in QDialog::exec (this=0x920c240) at dialogs/qdialog.cpp:552
#10 0xb743364c in KMessageBox::createKMessageBox (dialog=0x920c240, icon=..., text=..., strlist=..., ask=..., checkboxReturn=0x0, options=..., details=..., 
    notifyType=QMessageBox::Critical) at /var/tmp/portage/kde-base/kdelibs-4.6.3-r2/work/kdelibs-4.6.3/kdeui/dialogs/kmessagebox.cpp:337
#11 0xb7433f2b in KMessageBox::createKMessageBox (dialog=0x920c240, icon=QMessageBox::Critical, text=..., strlist=..., ask=..., checkboxReturn=0x0, options=..., details=...)
    at /var/tmp/portage/kde-base/kdelibs-4.6.3-r2/work/kdelibs-4.6.3/kdeui/dialogs/kmessagebox.cpp:152
#12 0xb7434dcd in KMessageBox::errorListWId (parent_id=0, text=..., strlist=..., caption=..., options=...)
    at /var/tmp/portage/kde-base/kdelibs-4.6.3-r2/work/kdelibs-4.6.3/kdeui/dialogs/kmessagebox.cpp:847
#13 0xb7434f68 in KMessageBox::error (parent=0x0, text=..., caption=..., options=...)
    at /var/tmp/portage/kde-base/kdelibs-4.6.3-r2/work/kdelibs-4.6.3/kdeui/dialogs/kmessagebox.cpp:814
#14 0xb509bdce in MailCommon::Kernel::emergencyExit (this=0x90f7b40, reason=...) at /var/tmp/portage/kde-base/kmail-4.6.0-r1/work/kmail-4.6.0/mailcommon/mailkernel.cpp:193
#15 0xb509bea7 in MailCommon::Kernel::createDefaultCollectionDone (this=0x90f7b40, job=0x92c5bf0)
    at /var/tmp/portage/kde-base/kmail-4.6.0-r1/work/kmail-4.6.0/mailcommon/mailkernel.cpp:158
#16 0xb509c30a in MailCommon::Kernel::qt_metacall (this=0x90f7b40, _c=QMetaObject::InvokeMetaMethod, _id=6, _a=0xbfbc7058)
    at /var/tmp/portage/kde-base/kmail-4.6.0-r1/work/kmail-4.6.0_build/mailcommon/mailkernel.moc:82
#17 0xb61c8093 in QMetaObject::metacall (object=0x90f7b40, cl=QMetaObject::InvokeMetaMethod, idx=6, argv=0xbfbc7058) at kernel/qmetaobject.cpp:237
#18 0xb61db460 in QMetaObject::activate (sender=0x92c5bf0, m=0xb72d1528, local_signal_index=3, argv=0xfffffdfc) at kernel/qobject.cpp:3278
#19 0xb718ce94 in KJob::result (this=0x92c5bf0, _t1=0x92c5bf0) at /var/tmp/portage/kde-base/kdelibs-4.6.3-r2/work/kdelibs-4.6.3_build/kdecore/kjob.moc:194
#20 0xb718d274 in KJob::emitResult (this=0x92c5bf0) at /var/tmp/portage/kde-base/kdelibs-4.6.3-r2/work/kdelibs-4.6.3/kdecore/jobs/kjob.cpp:312
#21 0xb5502292 in Akonadi::TransactionSequence::slotResult (this=0x92c5bf0, job=0x96bb4b8)
    at /var/tmp/portage/kde-base/kdepimlibs-4.6.3/work/kdepimlibs-4.6.3/akonadi/transactionsequence.cpp:132
#22 0xb54ed4bc in Akonadi::SpecialCollectionsRequestJob::slotResult (this=0x92c5bf0, job=0x96bb4b8)
    at /var/tmp/portage/kde-base/kdepimlibs-4.6.3/work/kdepimlibs-4.6.3/akonadi/specialcollectionsrequestjob.cpp:366
#23 0xb5501d7c in Akonadi::TransactionSequence::qt_metacall (this=0x92c5bf0, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbfbc7308)
    at /var/tmp/portage/kde-base/kdepimlibs-4.6.3/work/kdepimlibs-4.6.3_build/akonadi/transactionsequence.moc:76
#24 0xb54ed769 in Akonadi::SpecialCollectionsRequestJob::qt_metacall (this=0x92c5bf0, _c=QMetaObject::InvokeMetaMethod, _id=35, _a=0xbfbc7308)
    at /var/tmp/portage/kde-base/kdepimlibs-4.6.3/work/kdepimlibs-4.6.3_build/akonadi/specialcollectionsrequestjob.moc:73
#25 0xb5363d73 in Akonadi::SpecialMailCollectionsRequestJob::qt_metacall (this=0x92c5bf0, _c=QMetaObject::InvokeMetaMethod, _id=35, _a=0xbfbc7308)
    at /var/tmp/portage/kde-base/kdepimlibs-4.6.3/work/kdepimlibs-4.6.3_build/akonadi/kmime/specialmailcollectionsrequestjob.moc:64
#26 0xb61c8093 in QMetaObject::metacall (object=0x92c5bf0, cl=QMetaObject::InvokeMetaMethod, idx=35, argv=0xbfbc7308) at kernel/qmetaobject.cpp:237
#27 0xb61db460 in QMetaObject::activate (sender=0x96bb4b8, m=0xb72d1528, local_signal_index=3, argv=0xfffffdfc) at kernel/qobject.cpp:3278
#28 0xb718ce94 in KJob::result (this=0x96bb4b8, _t1=0x96bb4b8) at /var/tmp/portage/kde-base/kdelibs-4.6.3-r2/work/kdelibs-4.6.3_build/kdecore/kjob.moc:194
#29 0xb718d274 in KJob::emitResult (this=0x96bb4b8) at /var/tmp/portage/kde-base/kdelibs-4.6.3-r2/work/kdelibs-4.6.3/kdecore/jobs/kjob.cpp:312
#30 0xb54e8fdf in Akonadi::DefaultResourceJobPrivate::collectionFetchResult (this=0x95b7d90, job=0x94d1ed0)
    at /var/tmp/portage/kde-base/kdepimlibs-4.6.3/work/kdepimlibs-4.6.3/akonadi/specialcollectionshelperjobs.cpp:407
#31 0xb54eae3b in Akonadi::DefaultResourceJob::qt_metacall (this=0x96bb4b8, _c=QMetaObject::InvokeMetaMethod, _id=38, _a=0xbfbc75f8)
    at /var/tmp/portage/kde-base/kdepimlibs-4.6.3/work/kdepimlibs-4.6.3_build/akonadi/specialcollectionshelperjobs_p.moc:140
#32 0xb61c8093 in QMetaObject::metacall (object=0x96bb4b8, cl=QMetaObject::InvokeMetaMethod, idx=38, argv=0xbfbc75f8) at kernel/qmetaobject.cpp:237
#33 0xb61db460 in QMetaObject::activate (sender=0x94d1ed0, m=0xb72d1528, local_signal_index=3, argv=0xfffffdfc) at kernel/qobject.cpp:3278
#34 0xb718ce94 in KJob::result (this=0x94d1ed0, _t1=0x94d1ed0) at /var/tmp/portage/kde-base/kdelibs-4.6.3-r2/work/kdelibs-4.6.3_build/kdecore/kjob.moc:194
#35 0xb718d274 in KJob::emitResult (this=0x94d1ed0) at /var/tmp/portage/kde-base/kdelibs-4.6.3-r2/work/kdelibs-4.6.3/kdecore/jobs/kjob.cpp:312
#36 0xb54a8a72 in Akonadi::JobPrivate::delayedEmitResult (this=0x9503b00) at /var/tmp/portage/kde-base/kdepimlibs-4.6.3/work/kdepimlibs-4.6.3/akonadi/job.cpp:144
#37 0xb54a8e14 in Akonadi::Job::qt_metacall (this=0x94d1ed0, _c=QMetaObject::InvokeMetaMethod, _id=6, _a=0x94f8d40)
    at /var/tmp/portage/kde-base/kdepimlibs-4.6.3/work/kdepimlibs-4.6.3_build/akonadi/job.moc:91
#38 0xb5438365 in Akonadi::CollectionFetchJob::qt_metacall (this=0x94d1ed0, _c=QMetaObject::InvokeMetaMethod, _id=34, _a=0x94f8d40)
    at /var/tmp/portage/kde-base/kdepimlibs-4.6.3/work/kdepimlibs-4.6.3_build/akonadi/collectionfetchjob.moc:73
#39 0xb61c8093 in QMetaObject::metacall (object=0x94d1ed0, cl=QMetaObject::InvokeMetaMethod, idx=34, argv=0x94f8d40) at kernel/qmetaobject.cpp:237
#40 0xb61d2c7f in QMetaCallEvent::placeMetaCall (this=0x91fea28, object=0x94d1ed0) at kernel/qobject.cpp:535
#41 0xb61d3a2c in QObject::event (this=0x94d1ed0, e=0xfffffdfc) at kernel/qobject.cpp:1217
#42 0xb643b90f in QApplicationPrivate::notify_helper (this=0x905a0a8, receiver=0x94d1ed0, e=0x91fea28) at kernel/qapplication.cpp:4462
#43 0xb6443822 in QApplication::notify (this=0xbfbc7f8c, receiver=0x94d1ed0, e=0x91fea28) at kernel/qapplication.cpp:3862
#44 0xb74d7365 in KApplication::notify (this=0xbfbc7f8c, receiver=0x94d1ed0, event=0x91fea28)
    at /var/tmp/portage/kde-base/kdelibs-4.6.3-r2/work/kdelibs-4.6.3/kdeui/kernel/kapplication.cpp:311
#45 0xb61c0b25 in QCoreApplication::notifyInternal (this=0xbfbc7f8c, receiver=0x94d1ed0, event=0x91fea28) at kernel/qcoreapplication.cpp:731
#46 0xb61c20e0 in sendEvent (receiver=0x0, event_type=0, data=0x902b6e8) at kernel/qcoreapplication.h:215
#47 QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x902b6e8) at kernel/qcoreapplication.cpp:1372
#48 0xb61c238a in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1265
#49 0xb61f0fa3 in sendPostedEvents (s=0x9057100) at kernel/qcoreapplication.h:220
#50 postEventSourceDispatch (s=0x9057100) at kernel/qeventdispatcher_glib.cpp:277
#51 0xb45aeb60 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#52 0xb45b2c48 in ?? () from /usr/lib/libglib-2.0.so.0
#53 0xb45b2dfd in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#54 0xb61f0ba6 in QEventDispatcherGlib::processEvents (this=0x9052ae8, flags=...) at kernel/qeventdispatcher_glib.cpp:422
#55 0xb6500a2c in QGuiEventDispatcherGlib::processEvents (this=0x9052ae8, flags=...) at kernel/qguieventdispatcher_glib.cpp:204
#56 0xb61bf5ff in QEventLoop::processEvents (this=0xbfbc7ea4, flags=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece or DW_OP_bit_piece.
) at kernel/qeventloop.cpp:149
#57 0xb61bfa25 in QEventLoop::exec (this=0xbfbc7ea4, flags=...) at kernel/qeventloop.cpp:201
#58 0xb61c2432 in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1008
#59 0xb643a096 in QApplication::exec () at kernel/qapplication.cpp:3736
#60 0x0804a9ed in main (argc=1, argv=0xbfbc8084) at /var/tmp/portage/kde-base/kmail-4.6.0-r1/work/kmail-4.6.0/kmail/main.cpp:145

As this problem did not occur on a freshly-created user on the same system, I deduced that this problem was most likely due to an old configuration setting which is not (no longer) properly supported.
Removing Akonadi's settings (directories) inside ~/.config/ and ~/.local/share "fixed" seems to fix this problem.

Had same problem on Fedora 15 after upgrade to KDE 4.6.4.  kdepim version 4.5.96.

Workaround was to launch Akonadi Console, select "Local Folders" resource, select configure/configure natively.

Error appeared indicating current folder did not exist, select new path:
/home/<USER>/.kde/share/apps/kmail/mail/

Kontact/kmail now working again as normal.

Just to confirm that #10 Paul's solution works

I had my mail folder in an unusual dir (like /data/Mail) in my KMail 1.x configuration.

I haven't been able to select this folder as my default KMail 2.x folder.
In fact, currently, to solved this problem, I have created two mail resource folders : /home/<USER>/.kde/share/apps/kmail/mail/
 which is quite useless (except for Trash) and my old /data/Mail defined as another resource.

This is also hapening using the latest and greatest:
Akonadiserver 1.6.50
KDE Development Platform: 4.7.40 (4.7.40 (KDE 4.8 >= 20110623)
KMail: 4.8 pre

Packages used: Project Neon's PPA
Note that i started with a clean profile, and after some time the same error started to happen

Just found a workaround for my manifestation of this, with the aid of Tobias Koenig:
As per comment #3, setting a path for Local Folders fixes the issue.

KMail debugs that the SpecialCollections could not be fetched.

In my Akonadi config my Local Folders agent had no path, hence no SpecialCollections. Upon creating an appropriate (empty) folder and configuring this, the error wentaway.

*** Bug 280091 has been marked as a duplicate of this bug. ***

I started Akonadi Console and I don't have any "Local Folders" nor "KMail Folders". 

I went to the "Agents" page, then choose "Configure native" on the "Local Folders" agent. It has no folder initially. I pointed it to a new empty folder and now KMail started without problems!

So, seems to me that the "Local Folders" agent should check it's configuration on startup and crete it's directory or a default one if it's missing.

It was reported for my by a Windows user that after he created a personal calender ical ressource on an external memory stick he ran into that Problem.

We really need to handle this error case (Akonadi has a ressource configured but cant access the data for whatever reason) far more gracefully then just shutting the GUI down.
I am setting this to Major severity and personally think this bug should even be critical because it makes Kontact completly unusable until the user finds some way to edit the configuration. The Error message does not offer enough information with regards to what is really broken. So most of the users will face the impossible situation that they just can't use their Groupware Suite anymore after the configuration got somhow out of sync with the actual data.

Starting with a working and correctly configured KMail, this problem can also be triggered via the Settings - Configure KMail - Accounts dialogue:

Select "Local Folders" and then click "Modify...", the "Select a MailDir folder" dialogue will be displayed.  The entry box is blank and the message at the bottom says "The selected path is empty".

_Even if this dialogue is closed by clicking "Cancel"_ , an error box is displayed:

 "KMail encountered a fatal error and will terminate now.
  The error was:
  Failed to fetch the resource collection.".

There is now no way to restart KMail to fix the problem, the only solution is to use akonadiconsole to reset the Local Folders path.

Raising the priority to Critical because this has happened to me again, and it does result in loss of data:

(1) even after correcting the folder path, all mail message flags (including "read") are cleared
(2) the destination folder is lost from all configured mail fiters
(3) custom folder properties (including, e.g. "Act on new mail in this folder") are lost

Comment #19 is absolutely spot-on. I had the exact same issue with Kmail. Please fix!

I had this problem - getting the "Failed to fetch the resource collection."
error message whenever KMail2 was started under Fedora-16/KDE.

I seem to have solved the problem, very simply but also more or less randomly,
by creating an empty folder ~/Maildir .
Aftet this I was able to open KMail without getting the error message.
I went to Settings=>Configure KMail=>Accounts
double-clicked on Local Folders
and entered /home/tim/Maildir where asked
"Select the folder containing the maildir information:"

I have no idea why this worked,
and would like to suggest that the error message should be changed
to something intelligible by ordinary mortals.

I'm afraid this workaround didn't work for me - I launched KMail, and I get a popup saying:
'KMail encountered a fatal error and will terminate now.
The error was:
Failed to fetch the resource collection.'
While this popup didn't stop me opening Settings -> KMail, I did stop me clicking anything inside the 'configure - KMail' window.

upgraded from KDE:Distro:Stable for openSUSE 11.3

kmail starts with the above error.
confusing enough I can browse the imap account on gmx until I hit the "ok" button in the warning dialogue.  kmailrc still has my folders but they don't show.

the work-around of #9 (manually re-add the directories) fails with an error message about a missing "/cur" subdirectory.

oh, I also had an error message at the first start to re-run kmail-migrator --interactive.  this fails though with "Migration of kmailrc has already run, not running it again".

Still valid for 4.7.3.

Kmail crashes if a local resource is available but lacks (a valid) a path.

@Susanne did you try the workaround in comment #14?

(In reply to comment #22)
> While this popup didn't stop me opening Settings -> KMail, I did stop me
> clicking anything inside the 'configure - KMail' window.

A note: You can change your resources' configuration via KDE's systemsettings > personal information. There is no need to do this from inside kmail2.

(In reply to comment #25)
> @Susanne did you try the workaround in comment #14?
I admittedly don't understand what exactly to do :/

Should I just remove all akonadi resources in the akonadi console and then add one after the other manually?

I had the same problem after upgrading to kubuntu oneiric (KMail2  4.7.2) from natty (KMail 4.4.10). Workaround proposed by Paul in comment 10 worked for me as well, but first I had to apt-get install akonadiconsole 
(In reply to comment #10)

Same problem (kmail crashes on startup) occurs in Suse 12.1 but only with existing users. So new users, kmail/kontact will start OK.
The "workaround" of adding a ~/Maildir directory has no effect.
Makes no difference if started as kmail or as kontact - still fails.

(In reply to comment #29)
> The "workaround" of adding a ~/Maildir directory has no effect.
> Makes no difference if started as kmail or as kontact - still fails.

Please read comment 10 properly. You have to change the path of the existing local folders resource.

OK - #10 workaround does work for me too. thanks

+1 for comment #10 working

I want to confirm the solution comment #10 is working for kmail2 4.7.3

kmail 4.7.3 from kubuntu oneiric with debian kde 4.7.4 from debian experimental

solution from comment #10 worked by configuring folder $HOME/.local/share/.local-mail.directory in akonadi control module.

This folder was created by the migration wizzard with correct folder structure but no mails in it. I had 3 disconnected imap accounts in kmail 4.4.11, the old cached mails still residing in $HOME/.kde/share/apps/kmail/dimap

Cheers and thanks for the good work

Comment from #10 seemed to work. KDE 4.8 now.

Comment from #10 seems to work. KDE 4.8.3. along with Kubuntu 12.04

It's 2012 and it's still not possible to launch mail application on 4.8.3 without reading bugzilla entries. Uh, well....

This bug is now fixed. Look at release KDE 4.9 and https://bugs.kde.org/show_bug.cgi?id=124111

I still get that in 4.10 (just upgraded in Debian experimental), though I did not even *have* any local folders previously…

How typical of KDE. Bug marked as fixed in KDE 4.9, yet still exists in KDE 4.10. Has the Akonadi disaster taken enough human lifetimes in fixing its brokenness, or will you get longer to get rid of it?