Jump to content

Upgrade To 3.1.0 Not Possible - Directories Must Be Writable


Recommended Posts



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!





Link to comment
Share on other sites

  • 2 weeks later...

Hi Erik,


I have a similar error when trying to upgrade from 3.0.5 to 3.1.0.

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


Link to comment
Share on other sites

  • 3 weeks later...
  • 2 weeks later...

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 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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • 2 weeks later...

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.



Link to comment
Share on other sites

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.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...