Could not create document: server error or not responding (cPanel, v2.0.1)

[BespokeBusinessSoftware]

Describe the problem/question

Description:
After upgrading to PrivateBin v2.0.1 on a cPanel account, the GUI loads, but attempting to create a paste results in:
"Could not create document: server error or not responding"

This occurs despite the folder being writable and PHP running.

Did you use the FAQ section?

• Yes, I have read the FAQ and I found no solution/answer there.

What you did?

Updated PrivateBin to v2.0.1 and then attempted to create a paste

What happens

Error: "Could not create document: server error or not responding"

What should happen

Paste should be created

Additional information

Environment:

• PrivateBin v2.0.1
• PHP: ea-php81
• Hosting: cPanel (WHM-managed)
• data folder: /home/example/safe.example.com.au/data/
• Folder ownership: example (cPanel account owner)
• Folder permissions: 700
• salt.php permissions: 640

Steps already tested:

1. Folder permissions & ownership:

• cfg folder: 755
• data folder: 700, owned by cPanel user
• salt.php: 640, owned by cPanel user
• Attempted creating a test file in data using PHP — worked successfully, confirming PHP can write.

2. PHP version & extensions:

• PHP 8.1 (ea-php81) confirmed in cPanel

3. conf.php configuration:

• [model_options] dir set to absolute path: dir = "/home/example/safe.example.com.au/data/"
• Only [model] section for Filesystem active; all DB/S3 examples commented out.

4. .htaccess

• Confirmed .htaccess in data exists and is standard — it does not block PHP writing.

5. open_basedir

• phpinfo() shows open_basedir = no value — PHP has access to all directories, so no restrictions.

What has been ruled out:

• Permissions / ownership issues
• PHP writing restrictions (open_basedir)
• Missing or unreadable salt.php
• .htaccess blocking PHP

Server address

https://safe.bbsoftware.com.au/

Server OS

cPanel CloudLinux 9

Webserver

No response

PrivateBin version

2.0.1

Browser and version

No response

Local operating system and version

No response

Issue reproducibility

No, I cannot reproduce it on https://privatebin.net.

[BespokeBusinessSoftware]

I'm sure I've done something silly!

[elrido]

Check the server logs, specifically the php error logs (if that is configured to a separate file). That will tell you the exception or error message that prevents the server to write. The error given in the client is deliberately vague, as not to leak server internals.

[BespokeBusinessSoftware]

Hi @elrido thanks for replying. I dont believe I have access to the php error logs. So instead went back to v2.0.0 and it works without issue. So must be related to something in the 2.0.1 version....

[elrido]

If it is only with 2.0.1, then I would bet on it being due to #1678 and a missing PHP opcache module. Regardless of us making this optional again, I would recommend to ask your hoster to consider enabling it, as it will save them a lot of compute resources and speed up all your PHP applications significantly.

[BespokeBusinessSoftware]

Thanks @elrido yes that was the issue. OpCache was installed and after upgrading to 2.0.1 it worked without issue.
Thanks for you help :)

[RyanAccuWebCloud]

For the PrivateBin v2.0.1 issue on cPanel, here’s a quicker rundown:

• PHP Settings: Check max_execution_time, memory_limit, and post_max_size in cPanel to ensure they’re high enough.

• Error Logs: Enable PHP error logging and review the logs for more detailed error information.

• Disk Space: Verify there's enough free disk space in /home/example.

• Permissions: Temporarily set the data folder to 755 and files to 644 to rule out permission issues.

• Config Files: Ensure cfg paths and salt.php permissions are correct. Clear any config caches.

• CloudLinux Limits: Check if CloudLinux LVE limits are causing issues under WHM.

• External Services: Ensure any external dependencies (like databases) are correctly configured.

Consider testing the setup on an AccuWeb Cloud VPS for more control if needed.

[Roxanna2310]

I have had this issue recently. I am running a Docker Compose file however.

[elrido]

If you are using either one of the projects images the opcache module always was installed, so it will be a different reason. A likely candidate is the permissions and ownership of your data volume, if you are using the filesystem backend:

Note that the volume mounted must be owned by UID 65534 / GID 82. If you run the container in a docker instance with "userns-remap" you need to add your subuid/subgid range to these numbers.

In any case, the docker logs of the container will tell you what is going on in the form of logged exceptions and PHP errors.