First, try this:

https://elgg.org/discussion/view/3028891/suddenly-unable-to-login-to-elgg-account-nobody-is-able-to-login

https://elgg.org/discussion/view/3052941/cannot-login-fresh-install

wp-login.php is most likely from a Wordpress installation. So, have you also installed Wordpress on your server? If yes, what might you have recently changed in Wordpress? Maybe a .htaccess file of Wordpress (main domain as opposed to Elgg in subfolder or subdomain) redirects to the Wordpress login but then fails. Or are you using some plugin that combines Wordpress and Elgg accounts / authentification? Maybe that no longer works for some reason.

Thank you Nikolai and  iionly.

The problem is with one plugin that is under development recently.

I believe I'll fix it soon.

Thanks a lot. 

In my case the symlink is not broken. Before I click "Flush the caches" I see the content of views_simplecache there. When I flush the caches the content of views_simplecache is cleared and  the symlink folder (cache) is cleared as well. No folder is removed or created.

The problem is that after flushing, all the web design (css) disappears and the system does not rebuild it as usual.

Does the cached files (CSS etc.) gets recreated if you visit other pages of your site after you flushed the cache? It might be that the admin dashboard page is not correctly fully rebuild after you flush the cache (might be an Elgg 2.x issue already fixed in newer versions of Elgg).

The other reason might be what I already mentioned in my last post. The webserver does not run as the same user you are usually logged in on your server (I'm not taking here about the Elgg site user but the user account you use to administrate your webspace). The user account name of the webserver might be "www" or "apache" or something different depending on the webhoster, the OS used etc.. Now the webserver might be configured to follow symbolic links only if the links themselves are owned by the user account the webserver runs as (or the webserver might read files but not write anything at the target location of the link). That why I linked to the docs in the previous posting. There's the commands

cd /path/to/wwwroot/
chown -h wwwrun:www cache

posted there. The "chown -h" command would make the webserver the owner of the symbolic link. For the command to work you would have to be logged in as root or you probably can't change the owner. Before useing the command you need to find out the user name and group name the webserver runs under. You should be able to find this out if you make a "ls -l" on some newly created file in the data directory that has been created by the webserver (on your new server).

Yes, it was the ownership issue. Now it works fine.

Thank you iionly for your detailed response... and for your patience :)

BTW, the permissions of /private was 0751 (rwxr-x--x). It should be good enough - I think?

Use 0750  as the docs recommends:

chmod -R 750 /private

I disabled the caches -> Flush the caches -> enabled the caches.

Now it works fine. Why? I do not know :)

Thank you