"the Packages directory or one of the files in it are not writable!" BUT IT IS!

Started by themavesite, December 06, 2011, 05:40:45 PM

Previous topic - Next topic

themavesite

I want to install a mod through the package manager but when I upload it and try to install, SMF gives me this error

QuoteYou cannot download or install new packages because the Packages directory or one of the files in it are not writable!

Though I set the file and folder permissions in /Packages to 777...

Anyone knows what the problem is??
TMS Forums
Since 2008 and still going strong! Join today! http://forums.themavesite.com/index.php

Illori


MrPhil

777, paradoxically, isn't always writable. Your host may run security software such as suPHP that blocks access to the [world writable] folder (and, incidentally, lets SMF write to the folder with 755 permissions). I don't think that SMF looks at the permissions -- IIRC it actually tries to write. So, a 777 permission will result in a failed write, and the message that it's not writable. Always start with 755 for permissions. Only if you're told that SMF can't write, try 775, and as a last resort, 777. Try to change 777 back to 755 when you're done with your update operation. But first, see if you're missing your temp folder.

themavesite

I made a temp folder, still get this error

"You cannot download or install new packages because the Packages directory or one of the files in it are not writable!"

I'm on my own VPS btw.
TMS Forums
Since 2008 and still going strong! Join today! http://forums.themavesite.com/index.php

Illori



Illori


themavesite

Quote from: Illori on December 08, 2011, 09:10:35 AM
try 755, not all servers like 777

Still get

QuoteYou cannot download or install new packages because the Packages directory or one of the files in it are not writable!

:(
TMS Forums
Since 2008 and still going strong! Join today! http://forums.themavesite.com/index.php

themavesite

Quote from: themavesite on December 08, 2011, 09:42:15 AM
Quote from: Illori on December 08, 2011, 09:10:35 AM
try 755, not all servers like 777

Still get

QuoteYou cannot download or install new packages because the Packages directory or one of the files in it are not writable!

:(

Nobody?
TMS Forums
Since 2008 and still going strong! Join today! http://forums.themavesite.com/index.php

MrPhil

1) You created the directories that are needed? (especially "temp")
2) The ownership of the directories are consistent with the rest of your site?
3) You tried 755 permissions, then 775, and as last resort, 777 (for directories)?
4) You tried 644, then 664, and as last resort, 666 (for files)?

TeeJay

I'm getting the same error message on numerous SMF sites
Tried all the above suggestions but no success
Running 2.02 on 1and1 shared servers

Illori


SimpleGost

I have same error and  i tried everything i'm on vps, i dont know what type of php to set...
suphp, or mod_php?

I still getting error, PLEASE help!

evildrome


pkrack

I was having that issue and got solved when i created temp folder. One thing i noticed that you should not have a temp file in packages. Like temp.zip or temp folder will also not work

SimpleGost

Guys , i found solution :)
just switch to mod_php_ruid2

all will be working great, as like in shared hosting ;)

BlondChick


SimpleGost

SOLUTION FOR THIS IS REALLY CLEAR, OK?

If you using shared hosting, just set permissions to your packages directory to 777.
If it didn't work, and even with temp folder, then contact your host via ticket, because problem is in hosting , and it will be fixed fast

If you using VPS , and you have problem with permissions, solution is really EASY, change php type, change from mod_php (or suphp,etc..) to mod_php_ruid2 and all problems with permissions, installing mods, ownerships will be fixed

MrPhil

Quote from: InternetFazoni on February 26, 2012, 10:52:12 AM
SOLUTION FOR THIS IS REALLY CLEAR, OK?

If you using shared hosting, just set permissions to your packages directory to 777.
SIGH. 777 (World Writable) doesn't always work!. Many hosts forbid such permissions and will bar access to such directories, Maybe you'll get a 500 error, maybe you'll just get an inability to write. But STOP GIVING OUT BAD ADVICE -- you should always start with 755, and only if that doesn't work try 775, and as a last resort, 777.

You need to understand how your hosting service has configured PHP, so that you know when PHP is allowed to write to a given directory.

opan


Arantor

Quote from: MrPhil on February 27, 2012, 01:23:27 PM
Quote from: InternetFazoni on February 26, 2012, 10:52:12 AM
SOLUTION FOR THIS IS REALLY CLEAR, OK?

If you using shared hosting, just set permissions to your packages directory to 777.
SIGH. 777 (World Writable) doesn't always work!. Many hosts forbid such permissions and will bar access to such directories, Maybe you'll get a 500 error, maybe you'll just get an inability to write. But STOP GIVING OUT BAD ADVICE -- you should always start with 755, and only if that doesn't work try 775, and as a last resort, 777.

You need to understand how your hosting service has configured PHP, so that you know when PHP is allowed to write to a given directory.

Add to that, any new files written by that process (e.g. new mod files) are still entirely vulnerable because they're owned by the web server.

The entire damn process of packages for SMF is vulnerable and there's no way to solve it without redesigning the entire system.

christopher94523

I am getting the same errors and have tried the same folder permissions of 755/777

   "An Error Has Occurred!
   You cannot download or install new packages because the Packages
   directory or one of the files in it are not writable!"

This was NOT a problem when I upgraded to 2.0.1, so I am confused.
All that I have done is create a Pair Networks linking from https to the http code.
Perhaps the "install" code is hardcoded or expects something else?

Note that I had no problems when upgrading to 2.0.1 but had not added the SSL-based link.

best,
chris

christopher94523

The "solution" of enabling suexec does not fix the install problem w/r/t package and SMF upgrades.;
I was already set up to run PHP using the mod, as per the 2.0.1 upgrade, which gave me no problems, or all of the packages which I added:

   System CGI Enabled
   Virtual FTP is Disabled
   suEXEC is Enabled

There have been no installation-related changes on my VPS (at Pair Networks).
What changed in the installation process that -- not being adequately tested -- broke installs for many of us?

Rather than having each of us "reinvent the wheel", how about backing out the code changes that broke this for all of us?

I suggest undoing your code changes and then individually testing them as you add them, and using BETA testing format so that real world networking gets tested and not just the system upon which it was deemed "okay": core QA.

best wishes,
chris

MrPhil

Did you also try 775 permissions? Do you have the "temp" subdirectory under Packages?

Arantor

Quote
Rather than having each of us "reinvent the wheel", how about backing out the code changes that broke this for all of us?

I suggest undoing your code changes and then individually testing them as you add them, and using BETA testing format so that real world networking gets tested and not just the system upon which it was deemed "okay": core QA.

None of the changes in any release after 2.0 are to the package manager code, so it's not because of that that broke it.

The entire package process is fragile - and any of a number of host related changes could have broken it. I may be critical of SMF but I'm more critical of people jumping to conclusions without nearly enough information.

(Did you, for instance, actually look at what's in the packages to see what's changed?)

christopher94523

I am not critical of SMF; I really like it. I was a software quality assurance engineer for 25 years (Tektronix, Intel, Mentor Graphics, Analogy, etc.) so I had to follow a release process which rigorously tested (with manual and automated test suites) on numerous platforms, uses, and conditions.

A "bug" is hopefully a preventable state, but when one sneaks by the "gotcha" process it is thereafter tested for in the pre-release phase. When it prevents use of the software, that's considered critical, and everyone joins the effort to get it fixed and to get users into a "work-around" state.

I didn't make up "quality", although most QA people have disappeared so that the public gets used to the qualitylessness that neo-serfdom is implementing in the USA. It was what once made Japanese cars better.

If it is not pointed out 'how' to prevent a bug, then it won't get prevented, right? Process, process, process...
QA is not taught in school, except a way that a developer checks their own code. Detection requires a "sign-off" release process, eyes other than those of the developer, and a set of qualification methods (e.g., "black box" testing, "white box" testing, installation testing, BETA testing, regression testing, load testing) and now that quality isn't even expected, it has to get passed from one to another like some secret message being passed without secret police detecting it. The secret nis that quality matters and being critical of its absence is a form of complicity in its disappearance. It's not personal to point out that a process is lacking or that a bug exists. It's how we evolve and improve. True, doing it with ASCII is impersonal; there's no facial expressions, body language, or ways of seeing and correcting if you offend or misunderstand someone.

I cannot install packages or the update, so I am a bit miffed, and there are lots of others in the same sinking boat as well.a step backwards in "computer science".... However, I'm sure that SMF folks are trying to fix this bug, because trying to have each and every one of us fix it ourselves is labor-intensive, redundant, and "working harder, not smarter". It is a bug. And, if presented AS A GROUP, with a set of questions regarding our platforms, etc. it will probably show similarities and differences may assist them in solving where the code goes awry for those of us in this predicament. A paradox is just how will we install a fix if we cannot install.  ;-)

I will provide details regarding my setup to help out, but first, there needs to be a method of asking for details, so, maybe we can get that going first?

best wishes,
chris

Arantor

I'm not disputing there's a problem. I'm disputing the assertion you've made that it's a bug in SMF's later releases. You stated that you were able to do so, and now are not. Since no code has changed for some time in the package management code, it follows that if it is not that, something else must have changed, no?

In order for a package to succeed installation, not only must the Packages folder, a temp folder inside it (though that should be created/managed by SMF) but all files in Sources and Themes need to be writable to make it work.

The problem is that there are so many configurations that a single unified solution is unlikely to ever succeed.

Advertisement: