I just copied my magento site over to a local server running CentOS 5.4. The browser said it can't locate the location of the stylesheets. The stylesheets are within /skin/frontend/my_new_interface/design2/css. I tried to view in the browser and I can't view any of the files within the css directory. I verified a million times that I'm typing in the correct location. I can view files within /skin/frontend/my_new_interface/design2. Can't browse directories within browser however.
I typed in ls -l css
and get:
-rwxr-xr-x 1 apache apache
listed for all the files
I tried chmod -R 755 and the directories
I changed the apache conf Options Indexes
But still when I browse the directories I get Forbidden. However, in another fresh installation of magento in the same www dir, I am able to browse directories. As far as I can tell both installations have same ownership and permissions.
I also tried
find . -type f -exec chmod 644 {} \;
find . -type d -exec chmod 755 {} \;
which was recommended in the magento wiki
I've just run out of ideas.
You'll need to add Options +Indexes to your httpd.conf or in a .htaccess file in the css/ folder to view the folder contents through the browser. This is bad ju-ju though. Do you really need to switch this on, or can you keep doing it through the ssh session?
On the CSS file note, can you type pwd when in the CSS directory? That'll help us confirm you've got the correct location. Do you get "Forbidden" when you try to view the CSS file directory, or just when you try to view the directory contents?
The file permission were set up correctly. I figured out that the .htaccess had a rewrite rule set for the css directory that was causing the problem. I inherited this site and am still not aware of all the little modifications done throughout.
Related
I have looked at the various questions related to my question but haven't found any working answers
I have created a website,
All other directories are working perfectly.
But when I access this page: http://www.pakdostana.paks.pk/private-chat it says
403 access denied
All other pages are working,
My file permissions are 644 and I also try changing them to 755 and 777 but the error is same.
And I am using my own routing system.
Updated
I have an update when I directly access the folder with this URL: http://www.pakdostana.paks.pk/Chat/Private-Chat.php it works, but not with PHP routing system what can be error any guess!
Can anyone help me!
Best regards
It's not only the files permissions. You need permissions for the folder containing these files. The recommended permissions are 664 for files and 775 for folders.
As you don't specify which http server you are using nor the OS, I'm going to put an example Apache on linux.
cd /var/www/
sudo chgrp -R www-data html
find . -type f -exec chmod 664 {} \;
find . -type d -exec chmod 775 {} \;
What this does is:
Put you on the parent directory of default Apache's base path.
Change group ownership recursively for www-data and to html directory.
Find all files recursively and change permission to 664 (you may need to execute this with sudo).
Find all directories recursively and change permission to 775 (you may need tho execute this with sudo).
Hope this helps.
I want to tell everyone, every time I use Word Chat it says 403 access denied but when I removed this word it is working perfectly.
I don't know what was the error with this word
I'm trying to remove all .html files from the directory generated and from all subfolders there but it needs to leave all other files and directories alone.
I tried going through folder by folder and running rm *.html but this takes a long time as there are 20+ subfolders which also have subfolders. I tried looking the man pages for rm but nothing obvious jumped out. I'm sure there's a way to do this in one shot but I don't know how. Any ideas?
I think this may work:
cd generated
find . -type f -iname "*.html" -delete
Just wondering what the most common CHMOD setting used to hide a directory and it's contents inside a public_html folder of a Linux server. Basically just so the public can't access the files at all. Thanks.
On directories, to hide the contents, executable permission is what allows people to view the contents of the directory. So if you want the owner and group to be able to read it, then permission should look like this: drwxr-x--- (chmod 750 the_dir).
I have a large application in a production environment that I'm trying to move under version control. So, I created a new repo and imported the app, minus various directories and files that shouldn't be under version control. Now, I need to make the installed copy a checkout (but still retain the extra files). At this point, in a recent version of SVN, I'd simply do a checkout over top the existing directory using the --force option. But sadly, I have an ancient version of SVN, from before when the --force option was added (and can't yet upgrade... long story).
So, I checked out the app to another directory, and want to simply copy all of the .svn directories into the original directory, thus turning the original into a checkout whilst leaving alone the extra files. Now, maybe I'm just having a rough day and missing something that's in plain site, but I can't seem to be able to figure this out. Here are the approaches I've tried so far:
Use rsync: I can't seem to hit the right combination of include and exclude directives to recursively capture all the .svn directories but nothing else.
Use cp: I can't figure out a good way to have it hit all the .svn directories across and down through the whole app.
Use find with -exec cp: I'm running into trouble with the leading part of the pathnames of the found files messing up the destination paths. I can exclude it using -printf '%P', but that doesn't seem to go into the {} replacement for exec.
Use find with xargs to cp: I'm running into trouble with find sending over child directories before sending their parents. Unfortunately, find does not have a --breadth option.
Any thoughts out there?
Other info:
bash 3.0.0.14
rsync 2.6.3 p28
cp 5.2.1
svn 1.3.2
Use tar and find to capture the .svn dirs in a clean checkout, then untar into your app.
cd /tmp/
svn co XXX
cd XXX
find . -name .svn -print0 | tar cf /tmp/XXX.tar --null -T -
cd /to/your/app/
tar xf /tmp/XXX.tar
Edit: switched find/tar command to use NUL terminator for robustness in the face of filenames containing spaces. Original command was:
tar cf /tmp/XXX.tar $(find . -name .svn)
(5) Can't you just make a checkout to a different directory, then copy the extra files to that directory, verify that everything's fine before switching to running the app from the new directory?
I have been reading about Security of Design. I noticed a tip of lowest permission level. So I did the above code to my junk files. Unfortunately, the junk-folder seemed to contain some server files. A few sites become forbidden. The folder contained stuff such as "Mail", "dev" and "Public". The reason for junking them was that they are empty.
The files are located in a server of a CS-dept. There is no special CMS or anything like that. Before running 'chmod 644 some_files', I am promth to ask your opinion.
Why did the sites become forbidden? What are the lowest permission levels?
Lowest possible permission level is of course 000. But that wouldn't make much sense.
600 rw------- for private files
700 rwx------ for private directories
711 rwx--x--x for directories with public files, but without permission to list dir
644 rw-r--r-- for publicly readable files
755 rwxr-xr-x for publicly readable dirs
The web server usually runs as a different userid from "real" users. So you make it so that a "real" users files aren't readable by anybody else, and the web server can't read them. That's why 744 is a better permission set for files the web server needs to see.
Most likely the owner of the folders that are forbidden is another than the ones that are available. The user that runs the file or it's group must have read (and sometimes executable) permissions on the files/folder. Since you removed the read, write and executable privileges on the group and the world no one but the owner of the files will be able to run them.
TLDR:
Wrong owner of file/folder. chown to correct user.
Your problem: your user account does not have execute permissions for the rest of the world.
Solution:
You need to put the permissions 701 for your user folder. You can also set them to 711.
It is the folder which contains your public_html etc.
Then, check that your public_html has the permissions 755. Similarly, the contents should also be 755 in public_html.