Continuing on with AWS self-hosting, I come across this issue while installing BT. "The /var/www/html/BT-server/files directory exists but is not writable. PHP needs write-access to this directory. For techies, that means chmod 0755. For others, contact your webserver's administrator " I granted the dir 775, and even 777 permissions - no dice. I also tried chown -R myuser:myuser /var/www/html/BT-server. I'm not sure what else to try. For unrelated reasons, I had to go with a RHEL server. Previously I had this same issue on Ubuntu, and managed to get past it - but I dont remember how, or if my work-around doesnt apply to RHEL. Not really a linux guy. What else can I do here?

You may end up needing to let those permissions 'cascade' into the directory, so that it changes not only the directory, but any files and subdirectories within. Some FTP Programs (like FileZilla) will allow you to do this. I can't remember who it was, but there is a BT'er using Self Hosted on AWS. If I can recall their handle, I'll reach out and see if they can comment on the situation. Cheers! -- Smug

I did apply the permissions recursively, though the directory is empty on install. I'm using this guide where possible: https://www.buzztouch.com/files/howtos/RDs_Updated_EC2_Self-hosting_Guide.pdf

duplicate post..

Research Department. That's who it was. Have you tried sending a private message? They may be able to provide some suggestions... https://www.buzztouch.com/ResearchDepartment Cheers! -- Smug

I haven't, however, his doc was on using AWS Ubuntu. I am using AWS RHEL. The permission differences between the two linux distros, at least as provided on AWS, is enough to stop me in my tracks - I'm not sure Research Dept will be able to offer anything specific to my situation. I really need a linux/php pro to look this over i think. Looking at the install_2.php code, my issue is here: $filePath = "../files"; if(is_dir($filePath)){ if(is_writable($filePath)){ [...] }else{ $bolPassed = false; $strMessage .= "<br>The " . $path . "<b>/files</b> directory exists but is not writable. PHP needs write-access to this directory. For techies, that means chmod 0755. For others, contact your webserver's administrator"; } I've tried: - chmod 777 on www, html, BT-server, and files directories. - chown apache, ec2-user, and root for the same directories. - verified php is NOT running in Safe mode. - uploaded files dir from my AWS ubuntu installation (which is working). - restarted apache a few times throughout.. Perhaps I'm missing some dependency in php? Here's a comparison of my working (ubuntu) phpinfo, and the not working (RHEL) phpinfo. Ubuntu http://ec2-54-148-69-115.us-west-2.compute.amazonaws.com/test.php RHEL http://ec2-54-186-226-185.us-west-2.compute.amazonaws.com/test.php Anything stand out?

That's a lot of info to compare. What I would suggest is saving them both as text files, and comparing them using 'diffmerge'. https://sourcegear.com/diffmerge/ This will allow you to see every single difference between the two files, highlighted for easy noticibility. Let us know if it gets you any further. If not, we can revisit. Cheers! -- Smug

I can see the differences easy enough.. most relate to the different versions of php, their related components, and linux - which is not a problem onto itself. The problem is, I still wouldn't know what (missing) is actually causing the write to folder issue.

And you're certain that these values are correct in your config.php file? define("APP_PHYSICAL_PATH", "YOUR_APP_PHYSICAL_PATH"); define("APP_DATA_DIRECTORY", "/files"); define("APP_THEME_PATH", "/files/theme"); App Physical Path is the biggie; everything else hinges off of that. Cheers! -- Smug PS, you won't usually edit data and theme; if your physical path is correct, they will also be correct by default.

Yep, the config is setup the same way as my working instance. define("APP_PHYSICAL_PATH", "/var/www/html/BT-server"); define("APP_DATA_DIRECTORY", "/files"); define("APP_THEME_PATH", "/files/theme"); This is where BT is installed.

You may need to talk to either Danny Kessels, or someone in tech support at the host. All things being equal, if the configuration is correct, then it 'should' work. There is just some detail somewhere that isn't quite right. Whether that is something you can attend to, or needs to be attended by the host, I couldn't say. Good Luck on that, and let us know how it goes. Fingers are crossed! Cheers! -- Smug

Figured it out. The culprit turned out to be a SElinux. To prevent SELinux from blocking the www/ directory the following command had to be issued. chcon -R --type=httpd_sys_rw_content_t www/