tobean Posted January 6, 2015 Report Share Posted January 6, 2015 Hi! I tried to upgrade from 3.0.5 to 3.1.0. My system configuarion is: Apache, PHP 5.4.35, MySQL 5.1.73-1+deb6u1. On the system check page I get 4 error messages that directories are not writable (var, var/cache, var/plugins and plugins). Some other directories have the sampe permissions (777) and the system says it's OK (e.g. www/admin/plugins) I checked it serveral times but these directories are definitely 777. I have also changed all directories and sub directories to 777 but nothing changes. I used chmod 777 with telnet login. I have a similar error message in my 3.0.5 installation but everything worked fine (no problems): "Error: File permission errors detected. These may impact the accurate delivery of your ads, See the debug.log file for the list of unwritable files." What's the problem? Is it possible to deactivate this test in the system check page of the installation procedure? Has anybody an idea or solved this problem? Thanks in advance for all tips! Tobean Quote Link to comment Share on other sites More sharing options...
Erik Geurts Posted January 19, 2015 Report Share Posted January 19, 2015 Please review the upgrade instructions at http://www.revive-adserver.com/support/upgrading/ You will have to make sure all files and all folder and sub folder and all files inside those have the correct permissions. If they don't then the upgrade wizard will not let you continue. Richard Foley 1 Quote Link to comment Share on other sites More sharing options...
dalken Posted January 20, 2015 Report Share Posted January 20, 2015 Hi Erik, I have a similar error when trying to upgrade from 3.0.5 to 3.1.0. /home/www/[RVFOLDER]/www/images Directory must be writeable I checked and re-checked again, I used Filezilla for a recursive 777 on the www/images/ directory and I can visually see that all files and subfolders of www/images/ are 777, I also executed without error the SSH command given by upgrade wizard : File permission errors have been detected, and must be fixed before you can continue. To fix the errors on a Linux system, try typing in the following command(s): chmod -R a+w /home/www/[RVFOLDER]/www/images ... but I'm still blocked Any idea what else I could try ? Thanks a lot Regards, Quote Link to comment Share on other sites More sharing options...
tobean Posted February 6, 2015 Author Report Share Posted February 6, 2015 I'm sorry, but update is impossible even if I set the whole adserver directory to 777. The error message is still the same (4 diretories not wirteable). But they are writeable, definetly! So I have to give up and hope to a new version without this error... Quote Link to comment Share on other sites More sharing options...
imnotsure Posted February 9, 2015 Report Share Posted February 9, 2015 Are you using suphp? Ive ran into some issues (not during install though) but some files/dirs I had to chmod to 644 in order to make it work with suphp enabled. Quote Link to comment Share on other sites More sharing options...
tobean Posted February 10, 2015 Author Report Share Posted February 10, 2015 Are you using suphp? Ive ran into some issues (not during install though) but some files/dirs I had to chmod to 644 in order to make it work with suphp enabled. What is suphp? I have a managed linux server from 1and1 with PHP 5.4.35 Quote Link to comment Share on other sites More sharing options...
smscotten Posted February 22, 2015 Report Share Posted February 22, 2015 Revive needs some very simple changes in order to deliver an acceptable installation/upgrade experience: When it fails to write to an expected location, tell the user what location cannot be written to. At worst you could write a message to the error_log. This is especially important because for whatever reason (a horribly misguided one is my guess) Revive's installer thinks it needs the absolute path from filesystem root—not from webroot—in order to perform an upgrade. So if Revive's installer may *think* it wants to write a file somewhere totally outside the webroot. Which is bad. Especially bad when you're instructing people to set permissions to 777. Furthermore, even knowing that "the supplied Images Folder" is what couldn't be written to, where did that path get supplied from? If you report the path back that provides context so that the person reading the error doesn't bang her or his head against a brick wall trying to change the wrong directory. It doesn't matter whether the user or Revive is wrong about the path to the Images folder; it only matters that we know that we're tallking about the same folder. Case in point: by editing InstallController.php at line 793: $errMessage = $GLOBALS['strImageDirLockedDetected'].' {'.$aConfig['config']['store']['webDir'].'}'; // appended filename in brackets error_log($errMessage); // new line added I can see in the error logs that the Revive installer is checking the folder permissions on an empty string. There is simply no solution to this issue that inolves changing directory permissions or creating a directory. The instructions provided by the error message are flat wrong. So with all due respect, Erik, your answer that users should learn to RTFM is dismissive and insulting. In my case, in order to get the installer to move forward, I had to change webDir in the [store] section of my .conf.php to the absolute filesystem path. So that's a whole other issue: you should never need to know what the absolute filesystem path is. Never. Never ever. There is no reason to. None at all. And it probably breaks all kinds of cross-platform requirements, and it looks like you're trying to compromise the security of the server, and potentially you could be enabling a security exploit. So stop it. I have to congratulate Revive on the detail in the upgrade guide, but it could be written with a bit more attention to context. It's not clear, for example, that having two copies of the database is a suggestion while having two copies of the codebase is an absolute necessity. The first thing that I did was make a new dev instance on a virtual machine with a new copy of the codebase and a new copy of the database. And then I made a new copy of the database which was never needed. Another copy of the database isn't a bad thing. The point is that the instructions were unclear enough about the process—despite the agonizing level of detail—that you ought to reexamine how those instructions are written. It's all just suggestions here. It's free software and I haven't put the work into your software package to be in any position to make any demands. But hopefully free advice is, like free software, sometimes worth more than you paid for it. Erik Geurts 1 Quote Link to comment Share on other sites More sharing options...
Erik Geurts Posted February 23, 2015 Report Share Posted February 23, 2015 Thanks for your feedback and the free advice. I'm sure you realize that the instructions were written to cater for a huge variety of users, from complete novices to absolute gurus. It is impossible to tailor it to each individual case. It is not true that having two copies of the database is mandatory. It is just a safety precaution in case you run into an issue half way through the upgrade process. From your text, I can tell you're not a novice, and I'm sure you were able to use the instructions as guidelines for your own work. But then you should also have been able to realize that the second copy of the copy of the database was not needed. You started modifying the process and then blame the author (who happens to be me) that the rest of the instructions don't match. That simply doesn't make sense By the way, I never wrote "RTFM", I was much more polite than that, and you shouldn't put words in my mouth. Quote Link to comment Share on other sites More sharing options...
smscotten Posted February 23, 2015 Report Share Posted February 23, 2015 Erik, I'm not blaming you that the instructions "don't match". I'm saying that in your eagerness to make the instructions include all possible levels, you went far enough that it backfired and that they lost clarity. I know that the second copy of the database isn't necessary. I'm just saying that it was not clear from your instructions which steps were necessary and which steps were helpful hints. But stop right there if you are saying that the "Directories Must Be Writable" issue is the result of something I did differently from the instructions. I did not stray from the instructions until I encountered a problem where the support forum (here) had the author (you) responding to another user (tobean) with the same problem with a response that was, if polite, dismissive. You made it absolutely clear that you did not bother to read his or her report. Tobean wrote: "I have also changed all directories and sub directories to 777" You replied with by saying the Tobean should review the instructions and that "You will have to make sure all files and all folder and sub folder and all files inside those have the correct permissions." So in response to Tobean telling you that she or he had complied with step 5 of the preparations section of your instructions, you suggested that the solution was to follow thie instuction in step 5 of the preparations section. Can you see how that fails to be even slightly helpful? Do you see how disrespectful that is? Of course you didn't write the "F" word in there but it's the same level of disrespect. I'm sure that you didn't mean an insult. You're a busy person and I'm sure you just didn't read the question as deeply as you normally would. The only important question here is: what can Tobean (another user landing on this thread) do when faced with the "Directories Must Be Writable" error? Erik Geurts 1 Quote Link to comment Share on other sites More sharing options...
tobean Posted February 27, 2015 Author Report Share Posted February 27, 2015 Thank you "Newbie". What is the best solution to solve this problem, Eric? Normally, I don't like to edit config files (InstallController.php ??) Tobean Quote Link to comment Share on other sites More sharing options...
rachelangelo Posted March 11, 2015 Report Share Posted March 11, 2015 Hi there, I have the same permission issue, not upgrading but migrating to a new hosting. - I've chmod required folders (var, images,...) to 777 just to check if that was the problem: nothing was solved. - I've check config file and webDir was set to [MYDOMAIN]/[adserver_folder]/www/images, I think that's ok too But I still get the "File permission errors detected." The problem is that debug.log writes no error or warning messages, so I cannot guess were the problem is. BTW, old campaigns and banners -created in the old hosting - are ok, but when creating a new banner this is not displayed, as it was unable to write the images folder, even it is added to the batabase. ¿Any idea? How could I get some clues about what is going wrong? I would really appreciate your help. R Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.