I tried to move my G2 from host 1 to host 2 by copying the whole g2data folder of host 1 to the target g2data of host 2as instructed. Also, I dropped the MySQL database in the host 2 and imported the database from host 1 in. However, when I tried to run the G2, it asked me to run upgrading process, which follows 6 steps. After Authenticate step, the System Checks step warned that Storage Directory Permissions failed due to this error:
Quote:
Error: Some files and or directories in your storage directory are not writeable by the webserver user. Run chown -R webserverUser /home/lamba/public_html/hoanggiang/g2data/ OR run chmod -R 777 /home/lamba/public_html/hoanggiang/g2data/.
I found that though I can chmod 777 most folders under g2data folder, I could not change permission of all folders under folders namely "templates_c" and "cache". And it means no way to pass this step.
Quote:
[R] SITE CHMOD 777 /www/hoanggiang/g2data/cache/module
[R] 550 Could not change perms on /www/hoanggiang/g2data/cache/module: Bad file descriptor
[R] CWD /www/hoanggiang/g2data/cache/module
[R] 250 OK. Current directory is /www/hoanggiang/g2data/cache/module
[R] PWD
[R] 257 "/www/hoanggiang/g2data/cache/module" is your current location
[R] List (cached)
[R] List Complete: 235 bytes in 0.32 seconds (0.7 KB/s)
[R] SITE CHMOD 777 /www/hoanggiang/g2data/cache/module/core
[R] 550 Could not change perms on /www/hoanggiang/g2data/cache/module/core: Bad file descriptor
[R] CWD /www/hoanggiang/g2data/cache/module/core
[R] 250 OK. Current directory is /www/hoanggiang/g2data/cache/module/core
[R] PWD
[R] 257 "/www/hoanggiang/g2data/cache/module/core" is your current location
[R] PASV
[R] 227 Entering Passive Mode (67,19,139,74,97,185)
[R] Opening data connection IP: 67.19.139.74 PORT: 25017
So, I have 2 questions:
1. Do I need to replace the database the way I did above?
2. Is there any way I can change permission to those folders?
Iced Coffee
Gallery version (not just "2"): 2.0.2
PHP version (e.g. 4.3.11): 4.3.11
PHPInfo Link (see FAQ):
Webserver (e.g. Apache 1.3.33): 1.3.34 (Unix)
Database (e.g. MySql 4.0.11): 4.0.25-standard
Activated toolkits (e.g. NetPbm, GD):
Operating system (e.g. Linux):
Browser (e.g. Firefox 1.0): Firefox 1.5
Posts: 32509
ask your webhost to run
chmod -R 777 /www/hoanggiang/g2data/
for you. if they do it with the root user, it will work.
Posts: 75
OK, thanks. If there is no other way.
Iced Coffee
Posts: 20
I'm in a similar situation and I can't figure out why the user/groups keep changing on me . . .
If they wanted to, could someone with such an error (assuming it's due to this) run a php:
<?php
shell_exec("chown -R user:group /home/website/public_html");
shell_exec("chmod -R 777 /home/website/public_html/modules/Gallery/g2data");
?>
to reclaim ownership?
Posts: 32509
FAQ: I get a warning for missing themes / modules in the upgrader, what should I do?
FAQ: I get a ERROR_PLATFORM_FAILURE, what should I do?
FAQ: How can I upload a theme or module via FTP when I used the preinstaller?
Posts: 20
Valiant,
None of those FAQ answered my question.
I asked if a chown as I wrote it would be appropriate for reclaiming ownership of files so that you can then successfully chmod them.
I know you said you don't ask people to write code, but I'm not asking you to ask me to. I'm just asking if it would be appropriate as I described.
Mike
Posts: 32509
only the root user can chown. since every normal webhosting company doesn't run php scripts on their webservers under root, it won't work.
the above linked faq entries are related to platform errors and how to change permissions.
Posts: 20
Thanks, Valiant.
One last question along those lines - If you have g2data files that are having their user/group names (as well as permissions) altered on a semi-regular basis away from what they should be (and thus becoming non-chmod-able), is it possible, under any circumstances, that Gallery 2.1.2 code is doing it?
Supplementarily, might the fact that "Apache modules mod_security, mod_dosevasive, mod_speling and mod_layout are known to need special configuration to work with G2," possibly have anything to do with such a circumstance?
My host is somewhat difficult when it comes to Gallery, so he tends to blame anything wrong with its function on it, whether or not it should be. I, on the other hand, love Gallery, so I kind of need the knowledge to defend when I want something done with it ...
Posts: 32509
> If you have g2data files that are having their user/group names (as well as permissions) altered on a semi-regular basis away from what they should be
that would be bad.
> is it possible, under any circumstances, that Gallery 2.1.2 code is doing it?
in g2.0 under certain circumstances. that was a bug. in g2.1.2, it shouldn't be because of gallery2. but of course there could still be other bugs having this effect.
@mod_security:
possibly
@webhost:
some webhosts don't consider that changing the ownership of an account's files to the account owner could be a bad thing. in the case of g2 it is.
so maybe you should ask them if they periodically run scripts (backup / restore / move) that change the file ownership from anything (e.g. apache) to the account itself.
Posts: 20
Thanks as always, Valiant. We may be getting somewhere here. Things keep switching away from 777 daily, so I passed along your message to my host. His reply:
If it helps, from cPanel:
Are there any other details I should request from him to help with this?
I appreciate anything that helps me get this right. This is the 2nd host I've tried, and I really don't want to change hosts yet again (too much time/energy). He seems to be willing to do what it takes to get this going as it should. I think I just need to know what to tell him.
Thanks,
Mike
Posts: 32509
lol, yeah, i know that disk space issue for ISPs, i had the same fun with my webhost about 2 years ago.
there's not much i can suggest other than:
- either trust your users or
- change your disk quota monitoring scripts to "du -csm" on the home dirs of the users or something like that
- switch to suexec / php-fastcgi which a) offers better security and b) scripts are executed under the accounts which solves the disk quota issue as well
but changing the ownership without asking the customers is probably not the way to go.
alternative
- maybe you can tell g2 to generate all files / dirs with 777 permissions (site admin -> general: filesystem permissions). you'd also have to chmod -R 777 the whole g2data folder.
no guarantee that this will work though.
i really suggest to stop this cron job.
Posts: 20
I passed your suggestions along.
To check, he disabled the chron job for a day, and surely enough, everything stayed functioning properly (at least so far). However, what is peculiar to him and me, is that there are several others he hosts that use Gallery, and I am the only one experiencing this problem. As a result, he's not interested in changing anything drastic in terms of how he hosts.
It also doesn't make sense because he's only changing ownership, and my files are having their permissions modified as well ...
Do you know why my gallery would be affected and others not? I am thinking maybe they are on different versions of Gallery, or perhaps not Nuke integrated, but I don't know why that would really matter - it's a chmod/chown problem ...
If this can't be resolved, I'm going to have to look for my 3rd host in two weeks. Other than this, I'm really happy with my current one, so that's a nightmare I really don't want to go through.
Still got my fingers crossed.
I think the next step after this is to see both before and after a chron job what happens. I'll keep you posted, and thanks for all the diligent attention. It's funny how 90% of the time you put into a website always seems to go into the smallest and most trivial of details.
Mike
Posts: 32509
- webserver creates a file with permissions 755 -> webserver has r+w+x permissions, user X has r+x
- root chowns the owner of the file to user X -> webserver has r+x and user X has r+w+x
thus chowning changes permissions for the webserver user.
@different gallery's not affected:
g1 is probably less affected than g2. and maybe not all of those galleries are "active" (actively adding new pics).