Hello everyone,
I have a multi-site installation of Gallery V. 2.3.2 that has been working fine for several years. All of a sudden (Mar. 9, 2013), when browsing to one of the 2 multi-site installations, only a blank page with a '0' was displayed. When the other multi-site installation was browsed to, it displayed the same blank page with a '0' on it. When the core installation was browsed to, the updater page was displayed. I tried running the updater, and it authenticated and ran through the system checks. everything but the Storage Directory Permissions showed a pass. I received the following error message:
Storage Directory Permissions
Failed
+ Inaccessible or missing files (1)
Error: Some files and or directories in your storage directory are not writeable by the webserver user. Run chown -R webserverUser /hermes/bosweb/web212/b2122/ipw.comeshow/public_html/home/bcalbums/ OR run chmod -R 777 /hermes/bosweb/web212/b2122/ipw.comeshow/public_html/home/bcalbums/.
I then used FTP and ran all the files through recursive CHMOD 777 and ran the system checker again with the same results. I then came to this site and did some research. That lead me to try running the file gallery2/lib/support/index.php, which then gave me an error message saying that 'folder or file /hermes/bosweb/web212/b2122/ipw.comeshow/home/bcalbums/ does not exist!' But it does exist and I just spent hours CHMODing all the files to 777!
After further reading, I attempted to clear the cache, at which point I got the following results:
(Screenshot image) ClearCacheErrors.JPG attached below.
and also tried using the application to make the data storage folder writeable using the same support application as used for clearing the cache. Nothing made a difference, so I contacted my host and asked them to see if they could make the storage data writeable by the server. I gave them both of the above error messages (not the screenshot).
What they did was to move my storage data from above the /public_html/ folder to inside the /public_html/ folder!
I thought, OK, let's see if I can make Gallery work this way; so I altered the config.php file to point to the new location and ran all the storage folder files through CHMOD 777 again. Still no luck!
I confirmed that all 3 installations of Gallery have version.dat files, but I'm not certain that the version numbers are in fact correct or not.
phpinfo can be seen here: comeshowme.com/v-web/gallery/phpinfo.php (safe_mode is off) REMOVED AS NO LONGER APPROPRIATE.
I set Gallery to debug buffered and got the following: debugMar2013.txt attached below
and I have an old system info page from 2011 here: g2sysInfo.txt attached below (I need Gallery working to make a new one).
The core Gallery installation is at http://comeshowme.com/v-web/gallery/
If anyone can help me with this it would be very much appreciated because after 2 days of solid working on this, I'm burned out and my head hurts. I'm out of things to try and don't know how to read all those information outputs.
Thanks in advance!
Posted: Tue, 2013-03-12 05:02
Posts: 44
FURTHER TO THE ABOVE:
I ran CMOD 777 on my data directory again and found 2 folders that were not accessible: /bcalbums/smarty/templates_c/ had 2 folders named %%1038386857 and %%3605277982 that could not be accessed. It said it was a forbidden command argument. They remain at 755, and I cannot even look inside them. What are they for?
Another question I have is about the application for clearing the cache: Since I have 3 installations, I also have 3 data storage folders. I seem to only be able to run the application for the core installation of Gallery2. Will this application clear the cache of all 3 storage folders with one click?
I also read the FAQ section about 'Restoring Gallery 2 From A Full Backup', where it explains about the version.dat file and how to find the version number from the database. I tried using MySql to find the information and when I ran a search using the 'core' and '_version' parameters with 'LIKE' as the operator, I came up empty. I then used '=' as the operator and I was shown a blank page. I have to admit, I really don't know what I'm doing and I hope I didn't mess up my database! I then tried using the browse tab rather than the search tab, and I found a version number of 1.1.6, but I don't think that can be right since my notes from last year show I have Gallery version 2.3.2 and core module 1.3.0.2.
I hope all this makes sense to someone, because it sure doesn't make sense to me. I'm a real noob when it comes to this sort of thing.
Anyway, thanks for reading and hopefully someone will be able to give me some direction.
Posts: 44
In the FAQ section about file permissions, it suggested deleting the /smarty/templates_c/ folder if all else failed. I did that and I still get the same response from the Upgrader utility! What am I missing?
Posts: 8339
it should be
chmod -R 0777 /path/to/data/directorywhere the -R is for recursive
feel free to remove the templates_c directory, gallery will recreate it. also the same with anything inside the cache directory - although I'd skip the derivatives
each site needs its own copy of the /lib/support directory the tools located therein only work locally
IMHO multisite is a waste of time/energy. disk space is cheap. each site should have its own gallery.
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
Thanks for your reply suprsidr. My mistake in grammar. In my FTP program, I checked the box for recursive CHMOD, so YES it actually was -R 0777; but as mentioned above, the 2 folders in the templates_c directory that have the double percent signs could not be accessed by my FTP software and thus were deleted. This also did not help.
As for the tools in the /lib/support/ directory; do they rely on the core application for anything? I tried running a multi-site version and it just returned an error message:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator,
and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
http://comeshowme.com/v-web/gallery2/lib/support/index.php 09:48 PST
Does this information add any clues to what could be wrong? (I know the host upgraded from PHP version 4 to version 5 since my last need to look at my server set-up.)
Posts: 44
Oh... I just thought of something:
I only changed the config.php file of the core installation to point to the new data location, so that might be why the multi-site /gallery2/lib/support/index.php utility cannot function. Confirmation of this would be appreciated. I plan on moving all 3 data storage locations back to their original location, but thought I would at least try doing the trouble-shooting as it stands, just in case the host has done something to make the old location un-usable (causing all my problems in the first place).
Posts: 8339
I would.
Personally I would ditch multisite and put a complete codebase up for every site.
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
That sounds reasonable, but if the host has done something to no longer support Gallery 2, then that too would be pointless. I need to solve the why of the data directories giving me the error message. Their support is more than useless as indicated in my initial post. I need someone to look at the links I posted and decipher the meaning for me.
Posts: 8339
converting to separate codebases will cut 1/2 out of the debug loop foreach site.
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
Thanks for your continued input, suprsidr.
Are there any written instructions for converting multi-site installations to independent, when the storage folder is not writeable by the server? I could not find any.
Secondly, if I was successful in making the conversion, would you be able and willing to do the debugging for me, as I don't understand what all that information means?
Posts: 8339
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
The core installation and 1 other use the default theme. One of the multi-sites uses the Carbon theme. Other than that they are plain-Jane installations. I'm not certain of what I am supposed to look for when you say to make sure all the modules and themes are present. As far as I know, they all come in the codebase package.
Perhaps this sounds like a silly question to you, but in my mind, the CORE installation is a stand-alone installation. If the core installation cannot pass the system checks now, I don't understand why it would pass after overwriting all the codebase (except for config.php). Would you please be so kind as to enlighten me about how these things work? The more I understand (rather than blindly following instructions), the less I will need help in the future. And anyone ELSE following this thread will have a better understanding as well.
We appreciate you sharing your extensive knowledge of this software.
Posts: 44
suprsidr: What do you think about upgrading to Gallery 3 instead of simply converting to stand-alone versions? Would that be just as simple or does G2 need to be operational in order to make the jump to G3? I do like all the features that G2 has, but if you think that G3 is superior, then that may be one solution.
If you do suggest making the jump to G3; would you recommend the one-click installation provided by the host or a manual install by me? I originally installed G1 via the host's Simple Script, but over the years the upgrades have all been done manually by me. I also created the multi-sites myself. Initially, I couldn't get the sites to work until I made some changes to the config.php file and instead of leaving the BaseUrl (or Base Uri; can't remember which) blank, I needed to specify the path.
Posts: 8339
You need working G2's to migrate.
I think G2 is superior, it is mature, secure, and more feature rich.
This means that any themes or module active on each site should be in that site's codebase.
I would think you would just copy your current codebase to each separate site(making sure not to overwrite the individual config.php)
With multisite you only have one codebase shared among your 3 sites, so debugging is harder.
Separate sites, separate codebases makes for easier debugging.
In another thread recently(last weekish) another user was having similar difficulties w/ 2 of his sites.
Turned out that his host had moved him to a new server and something as simple as a wrong path in config.php had him pulling his hair out.
So check your site's details.
Twice this week I have been hired to fix G2 site's for different users who simply could not correctly move/configure their instances.
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
YIKES!!!
I just noticed something else:
In your previous instructions, you wrote, "chmod -R 0777 /full/system/path/to/g2data"
Are you saying that if my data is stored in /root/basement/public_html/g2data that all the folders before the g2data folder also need to be 0777 and NOT just the g2data folder and everything within it? I know this is NOT the recommended way of doing it, but my host moved my data folder up into the public_html folder, so if I followed your instructions the way I am understanding them, I would be exposing all of my entire website to the world!
Posts: 8339
no it doesn't mean all other directories will be 777
The best practice is to have your g2data in the same directory as public_html
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
I was wondering about exactly that issue when this first showed up. The problem I have is that the FULL PATH is not obvious to me. The Gallery installation module helped me with discovering my full path when I was initially setting it up. I questioned the host's tech. support about this and that is when they moved my data folder instead of answering my question. Below is my message to them (Please note the very last line and note the difference of the path names):
When browsing to my main Gallery installation (it is a multi-site install) I see only the Gallery Upgrader (which provides system checks). When running the system checker, I get an error of Storage Directory Permissions Failure: Inaccessible or missing files (1)
Error: Some files and or directories in your storage directory are not writeable by the webserver user. Run chown -R webserverUser /hermes/bosweb/web212/b2122/ipw.comeshow/home/bcalbums/ OR run chmod -R 777 /hermes/bosweb/web212/b2122/ipw.comeshow/home/bcalbums/.
NOTE:
When I browse to either of the other 2 Gallery installations (they run off the main installation), I get a blank page.
Gallery provides its own helper applications and when I opened one of those to change file permissions, I saw another error message saying:
Folder or file '/hermes/bosweb/web212/b2122/ipw.comeshow/home/bcalbums/' does not exist!
Note: Please look at the [details]. You might be able to change the filesystem permissions of the failed directories successfully yourself with an FTP program or a command line shell.
I used FTP to recursively change the storage folder permissions to 777, and while the commands were being executed, I did notice some red-coloured text scrolling by, but it goes way to fast to read it. I assume the red means it failed to execute the command. There were just a very few red-coloured messages. Thousands of files were successfully changed. However, none of the 3 Gallery installations work, and I still get the same error messages.
I then went to iPower's Control Panel and clicked on the icon for SERVER INFORMATION. There it shows the root directory as being /home/users/web/b2122/ipw.comeshow. I don't know if this is just a naming thing or if file structure has been altered on the server.
Posts: 44
I read somewhere that the best way to protect the data was to have /root/basement/g2data/
where the public_html folder is also in the same /basement/ folder (as in /root/basement/public_html/)
This keeps those g2data folders out of prying eyes. I'm pretty confident that this is what you just said above, but for clarity of anyone else reading this, I think an example is worthwhile. (of course, each person's set-up will have names different than ROOT and BASEMENT. I just made those up.)
Posts: 8339
create a new php file in your public_html info.php
contents:
<?= $_SERVER["DOCUMENT_ROOT"] ?>then visit it w/ your browser. Should report the path.
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
You, sir, are a genius! The path shown by the script is exactly as shown on the control panel. I bet they moved my site! That would explain the 'file does not exist' error message. I will alter my config.php file and report back, but I have a lot of hope that this is the origin of my problems. NOT at all impressed by my host's handling of this situation. They had much better support in the past, but as they grow, they get worse and worse. Thank goodness for this forum and people who spend countless hours helping others out!
Posts: 44
I am very excited and happy to report that after several days of pulling my hair out, it was a simple fix. The host moved my site and did not inform me of that crucial fact, even when asked about it. The core Gallery cleared the system checks and the site loads up when browsed to.
Now I need to put things back in order as they were initially, and perhaps even move to 3 independent installations as suggested by suprsidr. This could take a while, but I wanted to report back as soon as possible.
THANK-YOU SO VERY MUCH suprsidr!!! Your knowledge and suggestions are invaluable!
Posts: 44
Of course there MUST be complications:
I used the Host's file manager to copy my data directories from where they put them in the public_html folder to be back in the same folder as public_html.
However, there are lots of images and even a few short videos, so the copy process took a very long time and I noticed an error message saying "internal server error".
I figured it timed out, so I checked what had actually been added to the root directory and what had not. The strange thing is that everything is there according to the host's file manager, but when I check with FTP, there are quite a lot of items missing. At first, I thought that since my host uses an array of storage media,the File Manager was accessing one storage media and the FTP was accessing another and it would simply take a little time for the 2 to synchronize their data. However, after leaving it over night, nothing had changed.
I used the host's file manager to delete one of the affected folders from the root directory and it said file deleted, yet it remained visible even after refreshing the pane several times. So I selected each and every file within the folder and deleted them. Then deleted the folder. Finally it didn't show any more. Success, I thought! However, when I again copied the affected folder from the wrong location to the correct location (I'm glad I used copy rather than move) and it once more shows up using the File Manager, it still doesn't show up when using FTP!
Just to be sure that the original files in the public_html folder can be seen by the FTP software, I did navigate there and can see the affected folder and all the images within it, so it is not a case of those files being unreadable by the FTP software.
Has anyone had such an experience? Is there a solution or explanation?
Posts: 8339
I have a super secret script that lets you execute shell commands via PHP
command would be
mv -R /full/path/to/public_html/g2data /full/path/to/g2datahttp://www.westwind.com/reference/os-x/commandline/files-folders.html#mv
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
After going over my scribbled notes that I made while struggling through this issue, I see that I also had a warning from my database:
While attempting to discover the core module version from my database, I ran across the following messages:
Can anyone explain this to me?
Can Gallery repair this on its own?
Posts: 8339
there are 2 indexes for PluginMap:
pluginType
pluginId
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
Ooooooo NICE!!! This could come in REAL handy! THANK-YOU !
Posts: 44
I will need to do some research on this, as I am not getting your point. I may be a long time on that mission. I'm a slow reader. But thanks again for your continued support.
Posts: 8339
IOW don't worry about it.
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
I attempted to use your secret script to delete a folder using the command:
rm -R /home/totp_albums/albums/clients/client1/"#9 Lucas Kirk 2012 season and awards night"
but it failed to execute. Did I write it incorrectly or is there a problem because of all those spaces in the filename? By the way, I did not name that file, one of my users did.
Posts: 8339
the entire path would have to be in quotes, not just the sketchy part.
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
I tried again using
rm -R "/home/totp_albums/albums/clients/client1/#9 Lucas Kirk 2012 season and awards night"
but it still failed. I think it is the # mark in the file-name. All the directories that failed to be copied have the # in front of the name.
Posts: 8339
try escaping the #
rm -R "/home/totp_albums/albums/clients/client1/\#9 Lucas Kirk 2012 season and awards night"
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
I tried both the above method and putting quotes around just the last directory name (outside of the 'escape' slash). Both attempts failed. <sigh>
My hope is fading...
Oh... I delete and re-upload shellExec.php as I go to use it, but since validating myself upon first use, it allows me directly into the user screen every time I access it without asking for a password. Is that normal? Persistent cookie?
Posts: 8339
I was recently working on a shared host for a client. I was also running into these limitations w/ shellexec.php and adjusted the script to accommodate. But I did not save my changes locally.
If you want me to look further into this you can hire me.
-s
________________________________
All New jQuery Minislideshow for G2/G3
Posts: 44
I'm just a retired guy on a fixed pension, doing this as a hobby, so if I can learn to do things on my own, I prefer to do it that way. One does not generally learn anything when someone else does the work. How much would you estimate it would cost me if I did run into a wall and hired you? Obviously you have far more experience & knowledge in these things than I do and could likely have the thing resolved in short order.
Posts: 44
Just a quick summary for anyone that may be following this issue:
My host moved my site, so the absolute paths specified in the config.php files were no longer valid. When I questioned them about this, they moved my g2data files out of the root directory and into the public_html directory. When attempting to copy my files back to where they belonged, I ran into problems with 2 directories in the 'smarty' directory. Those are named with two percent signs in front of their filenames. (I also have problems with some albums that were named with a hashtag at the beginning of the filenames in one of my multi-site installations.) Once placed into the root directory, these badly-named files cannot be deleted, re-named, moved, or otherwise accessed.
My solution was to create a brand new g2data directory within the root directory and copy all but the smarty directory into this new spot. Then by editing config.php to point to the new spot, my core installation became operational once more. Gallery created a new smarty directory and its associated files on its own.
I wanted to see if I could do the same for the multi-site installation that had no badly-named files, but it seems something is still not quite right. Whether I try to access the updater, the /lib/support/index.php utility, or the gallery site itself, I now get an internal server error message, rather than just the blank page with a zero as before. I think I will simply attempt to change the multi-site to a stand-alone and see if that will resolve the situation, because I can't even get the current installation to display any debug information with the associated config.php file file set to
$gallery->setDebug('buffered'); I just get that same server error message.As for those albums named with the hashtags, my plan is to rename each album without the hashtag before copying them into the root directory location, then attempt to rename them back to having the hashtag once they are in place and have had their permissions set to 777. Otherwise I will need to find a way to alter the database so it knows the new names that don't have hashtags. Or... not include those roughly 1,000 images and have the person responsible upload them all again.
I'll keep you posted as things develop.
Posts: 44
Final comments:
Turning the muli-sites into stand-alone as suggested above by suprsidr did the trick and all 3 Gallery installations are now fully operational. Thanks again suprsidr!
As for the issue of folders named with a hashtag:
I did as planned in the post above, and found that when I attempted to put the hashtag back into the name after changing permission to 777, I was not able to do it through the host's File Manager (it refused and said it was an invalid name). I then used my FTP software to rename the albums (with hashtags) and was then able to run Gallery. From Gallery's EDIT ALBUM page, I was then able to rename the albums again so that they had valid filenames and the actual names in the g2data folder matched the names in the database (because Gallery itself made the changes).
I also use SMF forum software and wanted to see if that was affected by the site being moved, so I browsed to the site and it came up as normal, except for a banner warning across the top saying that the path to one of my files was wrong, and that I should 'click here' to fix it. I clicked the link and a window opened, showing the various paths to files from the website domain name onwards, and one that had an absolute path. I edited the absolute path to reflect the change, clicked 'save' and that was it! That's some super slick piece of work! Had I checked on SMF before working on Gallery, I would likely have been spared all the frustration because I would not have contacted my host and they would not have messed things up even more!