View Full Version : Domain won't work after moving to new user
Hello,
I wanted to move a domain to a different user with a different IP. The script
/usr/local/directadmin/scripts/move_domain.sh <domain> <olduser> <newuser>
worked so far.
The domain dir is in the new users home. But the domain is'nt accessable
I got a 403.
The apache error log says:
(13)Permission denied: /home/feilh/domains/feil-reisen.de/public_html/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable
There is no htaccess. if i create it and set the right permissions the error won't dissappear.
Also trying to protect some files via DA Fileexplorer won't work:
An error occurred while attempting to protect the directory
Details:
Unable to write the .htaccess file
Hope anybody has a hint for me!
Regards,
Alexander
Dravu
08-14-2008, 03:58 PM
Login via SSH and check for a .htaccess file. If you find one using that, then see who owns it and its permissions.
Login via SSH and check for a .htaccess file. If you find one using that, then see who owns it and its permissions.
As I wrote before: It has no effect wether to create the htaccess file.
I think it has to do with the directory protection.
It helped to backup the files, delete and recreate the domain with the right user, and then copying the files back. (And also recreate the protected directory via DA)
I had the same problem and fixed the issue when I changed the public_html folder to allow the apache user to read the folder i.e:
drwxr-x--- 8 myuser apache 4096 Jan 15 11:25 public_html
This corrected the problem that the script when creating the initial permissions on the public_html directory.
HTH,
Jon
floyd
01-15-2009, 04:28 AM
The correct permission are
drwxr-xr-x 4 user user 4096 Sep 30 08:43 public_html
apache should not be listed at all.
That'll work too, but when da has created a new user on my box it sets the permissions as I wrote i.e with the apache user.
Jon
floyd
01-15-2009, 04:44 AM
I manage over 70 DA servers with thousands of users and have never seen DA create a public_html with group apache. Something is wrong with your server.
Thanks, I'll speak to directadmin support.
Jon
HMTKSteve
01-20-2009, 11:26 AM
I had the same problem when I used scp to transfer files from my old (Plesk) server to my new (DA) server. I had to make the directories belong to the apache group for the site to work. With all permissions set to the user I was geting 403 errors.
Because some files needed to be writable by the web server I also changed them to belong to the apache group.
floyd
01-20-2009, 11:59 AM
If you changed all your files and folders to have group apache and group writable then that means apache can change all your files instead of just the ones that apache is supposed to change. Not a good idea.
A better way would have been to tar the files on the original server preserving permissions and then scp the tar file.
DA-Rff
03-13-2009, 08:36 AM
I had the same problem, got in with ftp and chmod 755 the public_html directory and then it worked on most sites. On one site it has moved the domain to the new user, but when I go to the domain with my browser I see the standard page for a new domain on DA, when I go to home/user/domains/domain/public_html I do see everything that should be there, and not the page that is shown, so what goes wrong here?
Any help much appreciated.
thanks
floyd
03-13-2009, 08:40 AM
When you look at the files how many index files do you see and what are there names? You should be able to figure out now.
DA-Rff
03-13-2009, 08:49 AM
through DA files I see index.php which is the basic page for my cms.
There is no other index page in there.
But through my browser I do not see this page, so somehow the domainmove has succeeded in moving the directories to the new location under the new user, but the domain does not point to the correct dir on the server, but to some other dir.
DA-Rff
03-13-2009, 08:51 AM
There must be something seriously wrong on my server because on a domain that I managed to get working after the move I now see no more pictures, except for a header and a footer pic, very strange
floyd
03-13-2009, 08:51 AM
At some point you are going to have to tell us what the domain is.
DA-Rff
03-13-2009, 08:54 AM
header and footer pics are png's anything else is not shown...
DA-Rff
03-13-2009, 08:55 AM
Pics is solved, went in with ftp and set the imagesdir to 755, now pics show again.
Why does this domain move script screw up all dir settings?!!
www.facingthechallenge.com shows only the standard da page
nobaloney
03-13-2009, 12:10 PM
www.facingthechallenge.com shows only the standard da page
May I presume this is just a statement of fact? Or did there used to be something there?
If the latter, then have you checked your site logs to see what directory is being accessed? And have you checked the content of that directory?
Jeff
DA-Rff
03-13-2009, 12:18 PM
there definitely was something, exact copy of www.facingthechallenge.nl both sites my business sites
BTW that site is a mess now as well, better ftp in now and see what dir I have to chmod 755 again
It is really weird....
floyd
03-13-2009, 01:04 PM
For facingthechallenge.com are you using a index.html or index.something else like index.php? If using something else then simply delete the default index.html page.
DirectAdmin Support
03-14-2009, 04:39 PM
Hello,
Note that the move_domain.sh is not smart enough to go through all script configs for user created php files and change any paths setup for the scripts.
For example, if you have something like a config.php file with the full path to the location of the script.. after running the move_domain.sh, you must update these configs as the move_domain.sh will not go into your own files and start changing things.
The actual move of the domain directory is just a "mv" command of /home/user/domains/domain.com. Everything below that won't have it's chmod touched. However, a recursive chown is run to set the correct new user.
I'm not sure if this is the case for your site, but something to consider for debugging.
John
Powered by vBulletin™ Version 4.0.4 Copyright © 2012 vBulletin Solutions, Inc. All rights reserved.