Recent Posts
21
Nginx / Re: Nginx uploads fail after every package update on CWP / AlmaLinux 8
« Last post by kandalf on May 19, 2026, 02:30:18 PM »Thanks for chiming in. Good to know I'm not the only one running the AppStream nginx under CWP.
Quick note on your point: even when you "accommodate permissions" on /var/lib/nginx, the fix doesn't stick across package updates. The RPM ships /var/lib/nginx and /var/lib/nginx/tmp with explicit %attr(0770, nginx, root) in the spec, and dnf reapplies those attributes on every upgrade automatically, without any postinstall scriptlet. That's why a one-shot chown isn't enough if you keep user=nobody in nginx.conf. The temp paths really do need to move out of /var/lib/nginx (or you switch user to nginx, which has its own implications for CWP integrations).
Still hoping someone from the CWP team can weigh in on whether the shipped default should set explicit *_temp_path or move to user=nginx.
Quick note on your point: even when you "accommodate permissions" on /var/lib/nginx, the fix doesn't stick across package updates. The RPM ships /var/lib/nginx and /var/lib/nginx/tmp with explicit %attr(0770, nginx, root) in the spec, and dnf reapplies those attributes on every upgrade automatically, without any postinstall scriptlet. That's why a one-shot chown isn't enough if you keep user=nobody in nginx.conf. The temp paths really do need to move out of /var/lib/nginx (or you switch user to nginx, which has its own implications for CWP integrations).
Still hoping someone from the CWP team can weigh in on whether the shipped default should set explicit *_temp_path or move to user=nginx.
22
Nginx / Re: Nginx uploads fail after every package update on CWP / AlmaLinux 8
« Last post by overseer on May 19, 2026, 01:55:03 PM »On one server, I've been with the default CWP Nginx 1.24 config, but with the Rift CVE, I switched over to the 1.31 AppStream version. So I haven't noticed the issue until now. But as a responsible sysadmin, with the switch to the AppStream-managed version I will accommodate permissions and/or the main conf as needed (thanks for the head's up!). No need to be bound by the CWP defaults if you aren't using their Nginx compiled from source.
23
Nginx / Nginx uploads fail after every package update on CWP / AlmaLinux 8
« Last post by kandalf on May 19, 2026, 10:41:38 AM »Setup: CWP on AlmaLinux 8.10, nginx 1.24.0 from appstream, default config with "user nobody;".
After every nginx package update, uploads larger than client_body_buffer_size start failing. The RPM resets /var/lib/nginx and /var/lib/nginx/tmp to "nginx:root 0770", so the nobody worker can't traverse into them to write client body temp files. SELinux is off, this is just DAC.
Confirm with:
rpm -q --queryformat "[%{FILEMODES:perms} %{FILEUSERNAME}:%{FILEGROUPNAME} %{FILENAMES}\n]" nginx | grep /var/lib/nginx
The usual chown fix works until the next update.
Permanent fix that survives updates: move the temp paths out of /var/lib/nginx into /var/cache/nginx (not owned by any RPM) and add them to nginx.conf:
client_body_temp_path /var/cache/nginx/client_body 1 2;
fastcgi_temp_path /var/cache/nginx/fastcgi 1 2;
uwsgi_temp_path /var/cache/nginx/uwsgi 1 2;
scgi_temp_path /var/cache/nginx/scgi 1 2;
Anyone else hitting this? Would it make sense for CWP to ship the default nginx.conf with these paths set, or switch the default user to "nginx" to match the RPM?
After every nginx package update, uploads larger than client_body_buffer_size start failing. The RPM resets /var/lib/nginx and /var/lib/nginx/tmp to "nginx:root 0770", so the nobody worker can't traverse into them to write client body temp files. SELinux is off, this is just DAC.
Confirm with:
rpm -q --queryformat "[%{FILEMODES:perms} %{FILEUSERNAME}:%{FILEGROUPNAME} %{FILENAMES}\n]" nginx | grep /var/lib/nginx
The usual chown fix works until the next update.
Permanent fix that survives updates: move the temp paths out of /var/lib/nginx into /var/cache/nginx (not owned by any RPM) and add them to nginx.conf:
client_body_temp_path /var/cache/nginx/client_body 1 2;
fastcgi_temp_path /var/cache/nginx/fastcgi 1 2;
uwsgi_temp_path /var/cache/nginx/uwsgi 1 2;
scgi_temp_path /var/cache/nginx/scgi 1 2;
Anyone else hitting this? Would it make sense for CWP to ship the default nginx.conf with these paths set, or switch the default user to "nginx" to match the RPM?
24
CentOS-WebPanel Bugs / Re: BUG* backup_manager2 not connecting to ftp server
« Last post by apartamenti on May 18, 2026, 06:35:57 PM »Hi!
The backups cannot be executed yet.
Did you test in yout servers?
Thanks!
The problem is still ongoing. CWP Support hasn't released any updates!
25
New Modules / Re: [MODULE] NEW GIT DEPLOY MODULE FOR CWP
« Last post by josemnunez on May 18, 2026, 04:31:01 PM »CWP already has a git module, ?module=git_manager, which you can find in the user plugin section.
26
Migration from other control panels / Re: Migration to...
« Last post by josemnunez on May 18, 2026, 04:24:24 PM »I'm very sorry to hear this here. We're working hard on many updates at once, and we plan to release the new PHP updates by the end of the week along with other reported changes and fixes.
27
CentOS-WebPanel Bugs / Re: BUG* backup_manager2 not connecting to ftp server
« Last post by adrianofnatal on May 18, 2026, 01:49:06 PM »Hi!
The backups cannot be executed yet.
Did you test in yout servers?
Thanks!
The backups cannot be executed yet.
Did you test in yout servers?
Thanks!
28
E-Mail / Issue with File Attachments in Roundcube Webmail
« Last post by kalybg on May 18, 2026, 09:37:42 AM »Hello,
For the past 2 days, I have been experiencing an issue with attaching files larger than 1 MB through Roundcube Webmail.
I have not made any configuration changes recently, except for updating CWP.
Previously, the attachment limit was always set to allow files up to 75 MB.
What is interesting is that when I log into the control panel as root and access Roundcube from there, everything works correctly and large files can be uploaded without any problem.
However, when a client accesses webmail directly through something like mail.mydomain.com, it is not possible to attach files larger than 1 MB.
I am using:
AlmaLinux release 8.10
Roundcube Webmail 1.5.13
If anyone has experienced a similar issue or knows how to fix it, I would appreciate your help.
Best regards,
For the past 2 days, I have been experiencing an issue with attaching files larger than 1 MB through Roundcube Webmail.
I have not made any configuration changes recently, except for updating CWP.
Previously, the attachment limit was always set to allow files up to 75 MB.
What is interesting is that when I log into the control panel as root and access Roundcube from there, everything works correctly and large files can be uploaded without any problem.
However, when a client accesses webmail directly through something like mail.mydomain.com, it is not possible to attach files larger than 1 MB.
I am using:
AlmaLinux release 8.10
Roundcube Webmail 1.5.13
If anyone has experienced a similar issue or knows how to fix it, I would appreciate your help.
Best regards,
29
Nginx / Re: New Nginx Vulnerability CVE-2026-42945
« Last post by overseer on May 17, 2026, 01:29:52 PM »Funny, my upgrade gracefully handled it as it should: An nginx.conf.rpmnew file was created during the update when an upstream Nginx configuration file has changed, but you have manually modified the active configuration file beyond the defaults. Instead of overwriting the customizations, the package manager saves the new default configuration as .rpmnew to prevent service downtime.
Check for /etc/nginx/nginx.conf.rpmnew
Check for /etc/nginx/nginx.conf.rpmnew
30
Nginx / Re: New Nginx Vulnerability CVE-2026-42945
« Last post by kadybee on May 17, 2026, 11:14:19 AM »Thank you @overseer for your work and post. Much appreciated.
Only thing I had to do was restore the original /etc/nginx/nginx.conf as there were a few errors with the mainline default.
Anyone else on this path, always a good idea to copy/save your conf directories.
Only thing I had to do was restore the original /etc/nginx/nginx.conf as there were a few errors with the mainline default.
Anyone else on this path, always a good idea to copy/save your conf directories.
