@Vitale: I feel your pain! Permission errors can be really frustrating. You are impatient to get back to work, and in your haste, you reach for chmod -R 777 *, the biggest sledgehammer in your toolkit.
It probably feels like you have solved your problem, because the permission errors have gone away. Now you can get back to work!
But chmod -R 777 * is never the right thing to do, despite all the bad advice on the Internet urging you to do it.
If you make a habit of "solving" your permission issues this way, you may someday find that the PHP ZenCart instance you set up with sloppy permissions for your first business client has been hacked, and all of your client's customers have had their credit card info stolen.
This is a golden opportunity to learn how to do things the right way. For future reference, here's how you should react to this error message:
Warning: require(../vendor/library50-php-5/CS50/CS50.php): failed to open stream: Permission denied in /home/ubuntu/workspace/pset8/includes7;config.php on line 20;
The permission error is triggered by line 20 of config.php, which is trying to require(../vendor/library50-php-5/CS50/CS50.php):. Therefore, there is a problem with either the permissions on the CS50.php file, or one of the directories in the path to that file.
To resolve the issue, you can spend a long time tinkering around with individual permissions on files and directories, which probably sounds like a big waste of time.
Luckily, there is a better way. You can very rapidly use the Linux find utility to find all the files that need changing:
find ~/workspace/pset8 -type d
find ~/workspace/pset8 -name *.php
Try it yourself! That's exciting, isn't it? Note that the first command returns all the directories, and the second one returns all the PHP files. But then we need to "pipe" the output of that command to xargs, which will execute a command using that output as its input:
cd ~/workspace/pset8
find . -type d | xargs chmod 755
find . -name *.php | xargs chmod 644
Try that, and you will see how quick and easy it can be to resolve these permission issues in the future.
Unfortunately, once you have used chmod -R 777 *, it's not so easy to reverse the damage. Imagine that you have a magic wand that can make anything change color to a single color of your choosing. You use your magic wand to turn a rainbow all red! But you cannot use the same wand to make it change back to "rainbow" -- you can only make it all blue, or all yellow, or all green.
To set up correct permissions for a freshly-unzipped pset8, the following commands may help:
cd ~/workspace/pset8
find . -type d | xargs chmod 755
find . -name *.php | xargs chmod 640
find ./public -name *.css | xargs chmod 644
find ./public -name *.js | xargs chmod 644
chmod 644 ./public/index.html
chmod 644 ./public/fonts/*
Note: I have just tested these exact commands on my own pset8 directory and can confirm that the Mashup still loads in my browser.
To restore your permissions to sensible defaults after using chmod -R 777 *, the following commands may help:
cd ~/workspace/pset8
find . -type d | xargs chmod 755
find . -name *.php | xargs chmod 640
find . -name *.html | xargs chmod 644
find . -name *.css | xargs chmod 644
find . -name *.js | xargs chmod 644
chmod 644 ./public/fonts/*
Note: I have not tested these exact commands on my own pset8 directory, because I have not used chmod -R 777 * on it, but I believe that they will help to repair the damage without causing trouble with the Mashup website.
By the way, if this helps you to resolve your issue, please let me know by clicking on the green checkmark. Otherwise, this will forever haunt the forum as a zombie unanswered question.
