Support

The .htaccess file cannot prevent a PHP script from opening a file for writing; that control resides entirely with the operating system, so the issue you are seeing is almost certainly caused by something on the server side. You will need to contact your host and ask them to check a few common server‑side restrictions that can produce the “could not open … for append” error.

First, verify that the directory that holds the backup file is owned by the same user under which the web server runs. Even if the permissions are set to 755 for the folder and 644 for the file, a mismatch in ownership will stop the PHP process from being able to append data. The host can confirm the UID/GID of the web‑server user and compare it with the ownership of the administrator/components/com_akeebabackup/backup folder.

Next, consider any Linux access‑control mechanisms that sit on top of the basic permissions. Systems that employ AppArmor or SELinux may have policies that restrict the web‑server process from writing to certain paths, regardless of the numeric permissions you see. If such a security module is active, the host will need to adjust the policy to allow write access to the backup directory.

After that, check whether the disk itself has enough free space. A full filesystem will cause the same error because there is nowhere for the new data to be written. The host can quickly run a df command to see if the partition that contains your site is out of space.

Even when the overall disk has room, an individual user quota might be in effect. Some shared‑hosting environments allocate a specific amount of space to each account, and once that quota is reached the system blocks further writes. Asking the host to review the quota for your account will reveal whether you have hit that limit.

Another factor is the limit on how many files a process can have open at one time. The operating system’s ulimit setting for the number of open file descriptors (ulimit -n) may be low, and if the backup routine tries to open additional files it will be denied. The host can raise this limit for the web‑server user if it is currently too restrictive.

Finally, there is a limit on the maximum size of a single file that a process may create, controlled by the file‑size ulimit (ulimit -f). If the database backup file is approaching that ceiling, the attempt to append more data will fail with the same message. The host can check the current file‑size limit and increase it if necessary. Please note that, by default, the target maximum size for a database (SQL) backup file created during the backup is 512 KIB. It might grow bigger than that if a single row in the database contains data which results in a single SQL query longer than this; this is extremely rare.

By having the host examine ownership, any active ACL or security policies, available disk space, account quotas, the open‑files limit, and the file‑size limit, you should be able to pinpoint why the backup can’t be written on this particular site while the others succeed. Once the relevant restriction is lifted, Akeeba Backup will be able to create the .sql dump, put it into the backup archive, and finish taking a backup.