I know this is technically not a WSN Links problem, though it just occured while setting up a new install on a server that I'm not used to.
I had some permission issues, htaccess couldn't be created, etc. so I was stupid enough to change the permission of the /html folder - in which all files for the website have to be stored - to 777. From that moment on I had no access to anything on the website. Obviously I changed the permission back to 755, then every other combination and finally back to 755, nothing (and I am able to change permissions through FTP and confixx, so it's not an ownership problem, I guess).
I'm completely locked out of the website, and I've been searching for the past hour, I can't find any help on this, especially not on the host website. They don't seem to offer any support when it comes to the server stuff, because that's not their main field of work (don't ask, it's not my host!)
I'm sure there's a very simple solution for this, but with all the hosts I used I never had a problem like this before
My guess is that you recursively changed everything below it to 777, so you'll need to recursively change it to 755.
With suPHP -- the recommended configuration for WSN -- 777 permissions on any file prevent it from being viewed. The ideal permissions are what it defaults to automatically (the advantage of suPHP being that you never need to chmod anything), 644 for files and 755 for directories. 755 for files should be ok if it saves you time, but if 755 files don't seem to work try 644.
I had some permission issues, htaccess couldn't be created, etc.
Maybe there's something else going on then. To my knowledge, any server that forbids 777 permissions would never have a permissions issue with anything until after you chmod something to change the defaults (unless maybe you're uploading from a unix computer with an FTP client that preserves localhost 777 permissions). It could even be some sort of botched php install that has the restrictions of suPHP without the benefits and would be unusable, I can't say from here.
nope, all folders are 755, all files 644. I guess I gotta go and call customer service first thing Monday morning so they can fix it. I tried everything, checked if the user is still owner of the folders and files (which he is), nothing. This is one weird server ...
0/5
1
2
3
4
5
Sorry, you don't have permission to post posts. Log in, or register if you haven't yet.
Comments on Access denied at 755
Forum Regular
Usergroup: Customer
Joined: May 11, 2003
Total Topics: 64
Total Comments: 199
I know this is technically not a WSN Links problem, though it just occured while setting up a new install on a server that I'm not used to.
I had some permission issues, htaccess couldn't be created, etc. so I was stupid enough to change the permission of the /html folder - in which all files for the website have to be stored - to 777. From that moment on I had no access to anything on the website. Obviously I changed the permission back to 755, then every other combination and finally back to 755, nothing (and I am able to change permissions through FTP and confixx, so it's not an ownership problem, I guess).
I'm completely locked out of the website, and I've been searching for the past hour, I can't find any help on this, especially not on the host website. They don't seem to offer any support when it comes to the server stuff, because that's not their main field of work (don't ask, it's not my host!)
I'm sure there's a very simple solution for this, but with all the hosts I used I never had a problem like this before
Any help with this is really appreciated. Thanks!
developer
Usergroup: Administrator
Joined: Dec 20, 2001
Location: Diamond Springs, California
Total Topics: 61
Total Comments: 7867
My guess is that you recursively changed everything below it to 777, so you'll need to recursively change it to 755.
With suPHP -- the recommended configuration for WSN -- 777 permissions on any file prevent it from being viewed. The ideal permissions are what it defaults to automatically (the advantage of suPHP being that you never need to chmod anything), 644 for files and 755 for directories. 755 for files should be ok if it saves you time, but if 755 files don't seem to work try 644.
I had some permission issues, htaccess couldn't be created, etc.
Maybe there's something else going on then. To my knowledge, any server that forbids 777 permissions would never have a permissions issue with anything until after you chmod something to change the defaults (unless maybe you're uploading from a unix computer with an FTP client that preserves localhost 777 permissions). It could even be some sort of botched php install that has the restrictions of suPHP without the benefits and would be unusable, I can't say from here.
Forum Regular
Usergroup: Customer
Joined: May 11, 2003
Total Topics: 64
Total Comments: 199
nope, all folders are 755, all files 644. I guess I gotta go and call customer service first thing Monday morning so they can fix it. I tried everything, checked if the user is still owner of the folders and files (which he is), nothing. This is one weird server ...