How to Fix Permissions Problems in Centova Cast (Permission Denied Errors and fixperms)

Updated: 8 October 2026 · Applies to: Centova Cast v3 (current release 3.3.4); shell checks tested on Debian 13, chown also on AlmaLinux 9 and 10, Ubuntu 24.04 and 26.04

To fix permissions problems in Centova Cast, log in to the server as root and run Centova's own repair tool: /usr/local/centovacast/sbin/fixperms. According to Centova, it resets the ownership and permissions of all Centova Cast files after they were damaged by an administrator or another application. Do not "fix" errors with chmod -R 777: Centova warns that making files world-writable badly damages Centova Cast and causes more permission problems.

Hosted stream and reseller customers: fixperms needs root access on the server, which only the server owner has. Open a support ticket with the exact error message and your stream username, and the fix is done on the server side.

Signs of a permissions problem

Centova lists these symptoms in its documentation:

• "Permission denied" or "Access denied" when uploading music by FTP (see errors while uploading by FTP).
• Empty server or autoDJ log files for a stream.
• A stream or its autoDJ fails to start.
• Errors about cronjob.lck when you run /usr/local/centovacast/bin/ccmanage cronjob all --debug.

According to Centova, the damage usually comes from a system administrator or another application changing files under /usr/local/centovacast, for example music copied or a backup restored as root.

How Centova Cast expects its files to be owned

• Centova Cast uses two system users: centovacast runs the web interface and related daemons, and ccuser runs the control daemon. All client data is owned by ccuser.
• Client data lives in /usr/local/centovacast/var/vhosts/USERNAME/, and each stream's music in var/spool/media/ inside it.
• Every media file must be readable by ccuser. It does not have to be owned or writable by it, but unreadable files cause errors.

Fix the permissions (root)

1. Stop all streams in the admin area (Accounts › Manage, tick the accounts, Stop) or with /usr/local/centovacast/bin/ccmanage batch --method=stop --username=all. Details: start and stop all streams.
2. Stop Centova Cast: /usr/local/centovacast/centovacast stop (or systemctl stop centovacast.service).
3. Make sure no stream or autoDJ processes are still running, and kill any that are. Centova's procedure uses this command (killall is in the psmisc package). The "no process found" lines only mean that program was not running:

   # killall -9 sc_serv sc_trans icecast icecast2 ices ices2
   sc_trans: no process found
   icecast2: no process found
   ices: no process found
   ices2: no process found

   Centova's list does not include Liquidsoap, the autoDJ that current installations use, so check for that too. pgrep shows anything left:

   # pgrep -l -x "sc_serv|sc_trans|icecast|icecast2|ices|ices2|liquidsoap"
   3839 liquidsoap
   # pkill -9 -x liquidsoap

4. Run the repair tool: /usr/local/centovacast/sbin/fixperms
5. Start Centova Cast: /usr/local/centovacast/centovacast start.
6. Start the streams again with Start in the account list or ccmanage batch --method=start --username=all, and check their logs.

This interrupts every stream on the server, so do it at a quiet time. According to Centova, streams that were killed while online are brought back within a few minutes by its process monitoring.

Find the files that cause the problem

These standard commands help you find files that do not match, before and after you run fixperms. Review what they list rather than changing everything by hand: fixperms sets the correct values. The output below is from a test directory we set up with one file copied as root and one folder set to 777:

# files and folders under vhosts not owned by ccuser
find /usr/local/centovacast/var/vhosts ! -user ccuser -printf "%u:%g %m %p\n"
root:root 600 /usr/local/centovacast/var/vhosts/radio1/var/spool/media/copied-as-root.mp3

# files the ccuser account cannot read
runuser -u ccuser -- find /usr/local/centovacast/var/vhosts ! -readable
/usr/local/centovacast/var/vhosts/radio1/var/spool/media/copied-as-root.mp3

# world-writable files and folders (symbolic links skipped)
find /usr/local/centovacast ! -type l -perm -0002 -printf "%m %p\n"
777 /usr/local/centovacast/var/vhosts/radio2/var/spool/media

When you copy music into a media folder by hand, set the owner at the same time, for example chown -R ccuser:ccuser /usr/local/centovacast/var/vhosts/radio1/var/spool/media. Use a colon between user and group. Some older Centova examples use ccuser.ccuser: GNU coreutils 9 (AlmaLinux 10, Debian 13, Ubuntu 24.04) and the new chown in Ubuntu 26.04 still accept it but print chown: warning: '.' should be ':'. Centova switched its own scripts to the colon in version 3.2.16.

Things that cause new permission problems

• chmod 777 on Centova Cast folders.
• Running streaming software as root to test it. Centova's troubleshooting guide tells you to switch to the ccuser account first (su - ccuser -s /bin/bash), so new files are not created as root.
• Restoring or moving data without running fixperms afterwards. Centova's migration and recovery guides end with fixperms for this reason.

If the errors continue

• Read the logs: Centova Cast's own logs are in /usr/local/centovacast/var/log/ (for example cc-web.log and control/master.log) and each stream's logs in /usr/local/centovacast/var/vhosts/USERNAME/var/log/. See Centova Cast core files and paths.
• "Permission denied" while running the installer is a different problem: see Permission denied while installing Centova Cast.
• If the installation is damaged beyond repair, follow reinstall and recover Centova Cast.

On a Ucartz Centova Cast dedicated server you have full root access, and free basic support is included if you would rather open a ticket than run these steps yourself.

Official documentation: Fixing Problems, System Accounts, Disaster recovery.