File permissions on Acquia Cloud and other Acquia offerings require careful handling when you are changing code or other files on your website. For security reasons, write permissions are disabled in both the live website and in the website repository. This prevents malicious individuals from attacking not only your website, but also your website's repository.
Your website has three major areas: the docroot (where the website is actually served from), the repository (where a duplicate of your codebase and PHP files are stored), and the distributed file system. The docroot is not a writable area. Any folder with an active settings.php file (often found in sites/default/files) will add a symlink to the distributed file system. With the symlink in place, files placed in distributed file system appear as though they are located within the file directories where Drupal expects them to be without requiring write access to the code repository files in the docroot.
Anatomy of your website
This figure shows the directory structure of a generic website, from repository to docroot, and where the symlink lies within that docroot.
Understanding how this works is important because without the right permissions, your website may fail to work in ways that are either simple or completely confusing. This can be a problem when you expect things to stay the way that you set them in version control. Git, for example, does not store any permissions (aside from the executable bit). Read and write, sticky, or Access Control List (ACL) bits are lost when you commit changes. For more information, see What does git do to files that are a symbolic link?
If you're experiencing a problem with permissions, you might see an error like the following:
file system: The selected file /mnt/tmp/mystg/filemyfile could not be uploaded, because the destination sites/default/files/js/myjsfile.js could not be found, or because its permissions do not allow the file to be written.
In multisite installations, things can be a bit trickier. Because these websites all can share the same codebase, they also can share the same symlinks.
The best practice is to symlink only the directory that needs write access. As an example, to create the correct links for a module that needs its own cache directory, you would use commands like this:
git clone yoursitename@yourserver.hosting.acquia.com:yoursitename.gitSee the instructions to checkout your code.
cd yoursitename/docroot/sites/all/modules/examplemodulerm -rf cacheln -s ../../../default/files/cache cachegit add cachegit commit -m "creating symlink for examplemodule cache"git push origin master
Once this is completed, you will need to access the server and create the new cache directory in your files directory. If not, when the code is deployed, the symlink will point at a non-existent target. Once you've created the directory, use either SCP (Secure Copy) or SFTP (Secure File Transfer Protocol) to transfer any files you had temporarily stored and need to replace.
Known problem modules
With the Acquia Cloud setup, several modules are known to have problems because they require the ability to write to their own module folder. You will need to link modules to the files area.
- CKFinder
- TCPDF
- Contact Importer (due to its reliance on Open Inviter )
- HTML Purifier
- WURFL
- SimpleSAMLPHP Authentication
This is by no means a complete list, and you may also need to link additional modules to the files area.