Please help us help you and fill where relevant:
LimeSurvey version: 7.0.0+260526
Own server or LimeSurvey Cloud: own server
Survey theme/template: general backend
==================
Hej,
I updated my self-hosted server to Ubuntu 22.04 about a week ago and with it limesurvey from 5.3.32+220817 to 7.0.0+260526. Ever since, limesurvey intermittently interrupts ist service. Safari 26.5 on MacOS 26.5.1 instead gives a message claiming that I was not connected to the internet, which is not the case, e.g. with video calls still running in parallel. MS Edge tells me the server was down which again is not true as an index.html independent of limesurvey on the same server remains accessible even though limesurvey is not.
In the update process, I had to reconfigure file and folder privileges and followed the instruction given here . At one point ever since the update, I received an error message telling me that PHP did not have necessary privileges to create a new directory related to that new survey using mkdir. Sadly I failed to keep the message.

apache error logs generate a host of messages in this style:[access_compat:error] [pid …] [client …] AH01797: client denied by server configuration: /var/www//limesurvey/application/core/plugins/ReactEditor/images/new_editor_image_small.png, referer: [site name removed]/limesurvey/index.php/surveyAdministration/listsurveys
other files affected are: /limesurvey/application/extensions/admin/grid/ColumnFilterWidget/assets/columns_filter.js, ient 172.29.224.147:57884] AH01797: client denied by server configuration: /var/www/deviat-project/limesurvey/application/extensions/admin/SearchBoxWidget/assets/filters.js, limesurvey/application/core/plugins/ReactEditor/images/new_editor_image_small.png

mysql logs show no errors; I don't see any PHP specific logs.

Maybe most troublesome: The admin login seems to stay open even after the breakdown of the connection. That is, after some time when I reload the page or re-enter …/limesurvey/admin in the browser, I am lead to the admin page without the need for an additional login.

Can anyone figure out what is happening or help me solve this?

I updated my self-hosted server to Ubuntu 22.04 about a week ago and with it limesurvey from 5.3.32+220817 to 7.0.0+260526.

How did you update from 5.3.32 to 7.0.0?

To be honest, I personally think it is never a good idea to jump from various versions back to the newest one.

Also, 7.0.0. is pretty new, I usually wait a couple of iterations before I move to the newest version for production.

Just have a look at the versions and the dates. There are basically 4 years between these two versions and one full version was skipped. I am sure that such a scenario was never tested.

I personally like to start clean with every major update, which generally avoids any such things. But I understand that this is not a viable approach for some, especially if there are many users and continuous surveys.

In any way, it is highly recomendable to setup a test enviroment with a copy of the original installation to test the update/upgrade without harming the production environment. yes, that is some additional work, but surely good practice to avoid any bad suprises. Updates within major versions are generally quite safe in my experience. With upgrades between major releases e.g. 5.x to 6.x, or 6.x to 7.x I would taken more precautions. And you went from 5.x to 7.x skipping 6.x in between.

Did you make sure that your PHP version is working with LS 7.x?

Yeah, I guess this wasn’t the smartest approach to the update. Of course, everything is saved and could be restored if needed. 

you mention to check whether PHP is working with LS. What checks exactly are you referring to? Just the documentation or are there any specific error messages I could look for on my server?

I am referring to checking, if the recommended PHP versions for LS 7.x is matching with the PHP version you are running on your server.

Yes, my server is running PHP 8.4.22

So I'm trying to roll back the upgrade and go stepwise. I don't see any releases prior to 6.17 available via limesurvey. Is there a repository of prior releases somewhere? I found a github link in the forum as well as a link to archived releases on limesurvey.org, both of which don't seem to be working anymore.
edit: I uninstalled LS 7, reinstalled the old database and did an upgrade to LS 6.17. For now, it seems to be running.

I think rolling back will be an issue, at least if you do not have a database backup. From what I have read, there have been some changes to the database structure, which might prevent you from just rolling back the same installation.

But I haven't touched LS 7.x yet (lack of time at the moment), so I am probably not the best to respond to this.

tamelung wrote:

Please help us help you and fill where relevant:
LimeSurvey version: 7.0.0+260526
Own server or LimeSurvey Cloud: own server
Survey theme/template: general backend
==================
Hej,
I updated my self-hosted server to Ubuntu 22.04 about a week ago and with it limesurvey from 5.3.32+220817 to 7.0.0+260526. Ever since, limesurvey intermittently interrupts ist service. Safari 26.5 on MacOS 26.5.1 instead gives a message claiming that I was not connected to the internet, which is not the case, e.g. with video calls still running in parallel. MS Edge tells me the server was down which again is not true as an index.html independent of limesurvey on the same server remains accessible even though limesurvey is not.
In the update process, I had to reconfigure file and folder privileges and followed the instruction given here . At one point ever since the update, I received an error message telling me that PHP did not have necessary privileges to create a new directory related to that new survey using mkdir. Sadly I failed to keep the message.

apache error logs generate a host of messages in this style:[access_compat:error] [pid …] [client …] AH01797: client denied by server configuration: /var/www//limesurvey/application/core/plugins/ReactEditor/images/new_editor_image_small.png, referer: [site name removed]/limesurvey/index.php/surveyAdministration/listsurveys
other files affected are: /limesurvey/application/extensions/admin/grid/ColumnFilterWidget/assets/columns_filter.js, ient 172.29.224.147:57884] AH01797: client denied by server configuration: /var/www/deviat-project/limesurvey/application/extensions/admin/SearchBoxWidget/assets/filters.js, limesurvey/application/core/plugins/ReactEditor/images/new_editor_image_small.png

mysql logs show no errors; I don't see any PHP specific logs.

Maybe most troublesome: The admin login seems to stay open even after the breakdown of the connection. That is, after some time when I reload the page or re-enter …/limesurvey/admin in the browser, I am lead to the admin page without the need for an additional login.

Can anyone figure out what is happening or help me solve this?

I also had the same question about what could cause LimeSurvey to become intermittently unavailable while the rest of the server remains reachable. The fact that a separate index.html continues loading makes a general network or Ubuntu connectivity problem seem less likely, and the timing after the upgrade from 5.3.32 to 7.0.0 makes the LimeSurvey/PHP/Apache configuration worth investigating first. The AH01797: client denied by server configuration messages are also interesting, although I’m not sure they would by themselves explain the entire application becoming inaccessible. I’d especially want to verify the Apache access rules and .htaccess configuration against the requirements for the newer LimeSurvey version, rather than assuming the permissions from the previous installation still apply.

The PHP permission error around mkdir also seems like an important clue, since a failed write operation could potentially cause application errors that aren't immediately obvious from the browser. I would check the PHP-FPM/Apache user, ownership and permissions of LimeSurvey's writable directories, as well as the PHP error log and Apache error log around the exact time the service stops responding. The fact that the admin session appears to remain active is interesting too, but it may simply mean the existing session cookie is still valid rather than proving that LimeSurvey is actually functioning normally. I’d also be interested to hear whether anyone has performed this particular 5.x-to-7.x upgrade and can point out any changed PHP, Apache, filesystem-permission, or session requirements that could explain these symptoms.

There are several separate issues here that should be considered:First, regarding the update process: I would not recommend upgrading directly from a very old LimeSurvey version such as version 5 to the latest LimeSurvey 7 release—especially when the installation contains many surveys. This may cause the DB update to fail due to timeouts.
A safer approach is to update from version 5 to the latest compatible LimeSurvey 6 release first, verify the installation and surveys, and only then continue to LimeSurvey 7.Rolling back without also restoring the corresponding database backup will almost certainly cause errors. LimeSurvey 7 introduced extensive changes to the database structure, particularly the field-name refactoring described here: [url] www.limesurvey.org/manual/LimeSurvey_7_Fieldname_Refactor [/url]The web-server message stating that access was “denied by server configuration” might be related to requests made by the new React-based survey editor. We have already seen installations where security mechanisms such as a Web Application Firewall incorrectly classified some of these requests as malicious and blocked them. As a diagnostic test, I would temporarily disable the relevant security rule or tool—only in a controlled environment—and check whether the problem still occurs. The web-server and WAF logs should ideally show which specific rule blocked the request.For any remaining errors, please enable LimeSurvey’s debug mode in: Then reproduce the issue and post the complete error stack here. Please remove passwords, database credentials, tokens, paths containing sensitive information, and other confidential data before posting it publicly.Finally, it is not unusual that returning to the administration area does not require another login while the existing session is still valid. With a typical default PHP session lifetime of approximately 24 minutes, the browser can continue using the existing session cookie, so LimeSurvey does not need to display the login screen again. The actual timeout may differ depending on the PHP and LimeSurvey configuration.

Mazi wrote:

There are several separate issues here that should be considered:First, regarding the update process: I would not recommend upgrading directly from a very old LimeSurvey version such as version 5 to the latest LimeSurvey 7 release—especially when the installation contains many surveys. This may cause the DB update to fail due to timeouts.
A safer approach is to update from version 5 to the latest compatible LimeSurvey 6 release first, verify the installation and surveys, and only then continue to LimeSurvey 7.Rolling back without also restoring the corresponding database backup will almost certainly cause errors. LimeSurvey 7 introduced extensive changes to the database structure, particularly the field-name refactoring described here:  www.limesurvey.org/manual/LimeSurvey_7_Fieldname_Refactor The web-server message stating that access was “denied by server configuration” might be related to requests made by the new React-based survey editor. The same kind of careful version checking is useful when working with minecraft modifications such as the jenny mod . We have already seen installations where security mechanisms such as a Web Application Firewall incorrectly classified some of these requests as malicious and blocked them. As a diagnostic test, I would temporarily disable the relevant security rule or tool—only in a controlled environment—and check whether the problem still occurs. The web-server and WAF logs should ideally show which specific rule blocked the request.For any remaining errors, please enable LimeSurvey’s debug mode in:

Code:

/application/config/config.php

Then reproduce the issue and post the complete error stack here. Please remove passwords, database credentials, tokens, paths containing sensitive information, and other confidential data before posting it publicly.Finally, it is not unusual that returning to the administration area does not require another login while the existing session is still valid. With a typical default PHP session lifetime of approximately 24 minutes, the browser can continue using the existing session cookie, so LimeSurvey does not need to display the login screen again. The actual timeout may differ depending on the PHP and LimeSurvey configuration.

Thanks, this helps separate the symptoms and gives me a much clearer troubleshooting path. I’ll first review the upgrade path and make sure I’m not treating a direct 5.x-to-7.x upgrade as the ideal approach. I’ll also verify that any rollback is accompanied by the matching database backup, especially given the database structure changes introduced in LimeSurvey 7.

The WAF/security-rule point is also useful. I’ll check the Apache and WAF logs around the AH01797 messages to see whether requests from the newer survey editor are actually being blocked and which rule is responsible. If necessary, I’ll test the relevant security rule in a controlled environment rather than disabling security broadly on the production server.

For the remaining application errors, I’ll enable LimeSurvey debug mode and reproduce the issue so I can capture the complete error stack, while removing credentials, tokens, sensitive paths, and other private information before sharing anything. I’ll also keep the existing admin session behaviour in mind, since remaining logged in after returning to the administration area doesn't necessarily indicate that the application itself is still processing requests normally.

Rolling back the upgrade with stored backup copies and stepwise upgrading afterwards did the trick. Erverything is now properly running under some 6.X version (not sure of the actual version at the moment)

tamelung wrote:

Rolling back the upgrade with stored backup copies and stepwise upgrading afterwards did the trick. Erverything is now properly running under some 6.X version (not sure of the actual version at the moment)

Yes, that's what we recommend when updating from pretty old versions. Instead of going directly to the latest version, better update step by step.