New 2.0.10 on new server: Package manager unable to modify read-only files

[Deprecated]

The problem is obvious but I haven't seen this before on other servers. I have to enter my server FTP data each time I install a mod package. Obviously SMF is using FTP to chmod the files.

It's a PITA to fill in this information each time I add a mod package. Can I just set the permissions of all SMF's files once and not need the FTP data any more?

I'm thinking:

find * -type d -exec chmod 755 {} +
find * -type f -exec chmod 644 {} +

and maybe:

chown -R www-data:www-data *

I'm running nginx and web applications run as www-data. Will setting the folder and file permissions as per above do the job? Do I need to change the owner too?

Or if not this then how do I get rid of having to use FTP to change file permissions each time I install a mod package?

Thanks!



ETA:

Actually it's worse than I thought. Even with valid FTP data ("FTP connection established.") I get "You cannot download or install new packages because the Packages directory or one of the files in it are not writable!"

I think the reason I'm running into this problem is because I've always run SMF under Apache and this is the first time I've installed SMF on a server running nginx.

[Illori]

do you have a temp and backup folder located in the packages folder? if not create those and try again.

[Deprecated]

Thanks! Better... I got this:

Some of the files the package manager needs to modify are not writable. This needs to be changed by logging into FTP and using it to chmod or create the files and folders. Your FTP information may be temporarily cached for proper operation of the package manager. Note you can also do this manually using an FTP client - to view a list of the affected files please click here.
The following files need to made writable to continue installation:

/******/Packages/temp/delme.tmp

It also cached my FTP data which was at least a bit easier, but I'm not used to entering that data at all. I've done maybe 50-75 SMF installations (including my test setups) and never faced this problem before. My best guess is I've never installed SMF on nginx and always used Apache instead. Pretty sure it's related to a difference between the two HTML server softwares.

Actually it cached my admin login/pass not my FTP login/pass but even when I corrected that it still won't proceed.

[Deprecated]

I fixed it. I hit it with a bigger hammer!

find * -type d -exec chmod 777 {} +
find * -type f -exec chmod 666 {} +

I'm not entirely happy since I doubt all files need to be writable, but at least it worked.

Comments?

[JBlaze]

Keeping files with 777 permissions is not advisable. That means that anything can write to them, including malicious files that could end up on your server.

If you inadvertently enter the incorrect information, and it saves, you need to purge your cookies for that domain to try again. SMF saves the FTP info in a cookie rather than on the server.

[Deprecated]

I completely agree about 777 being inadvisable. However the FTP route was unable to install the mod package.

That is why I haven't closed the topic as solved. This works, but just because something works does not make it right.

Again, the FTP route was unsuccessful in enabling installation of mod packages.

The installer recommends "777 or 755 (depending on server)" for most of the top level directories, which may be okay, but it can't be good to have *ALL* directories and *ALL* files unlimited access, as I am sure you will agree.

I've never run into this problem before but I've always run SMF under Apache; this is my first server with nginx. Perhaps others who use nginx can comment on whether they did or did not run into any issues.

The files are owned by root, web applications run under www-data, but the FTP is set up for the root account so it should be able to change file permissions with no ownership problems.

[JBlaze]

I honestly can't help you with nginx as I've never used it myself. I've always been an Apache guy myself. Best bet is to ask in Server Performance and Configuration.

[Deprecated]

Thanks. I understand. Nginx is gaining popularity but AFAIK Apache is still king. I've always run Apache (over 10 years) but a friend recently convinced me to try nginx. Initially nginx was rather intimidating but as my knowledge grew I passed a point where it's easier to configure than Apache, for me. I am of course discussing support of multiple sites. Single site servers are much less demanding for either system.



I'm a software engineer. Eventually I'll dig in and spend a day or a week or whatever it takes to find out what is really happening, and update this topic with my findings.

[JBlaze]

From what I gather, nginx is better at handling many connections concurrently. It's optimized more with less features and addons, whereas Apache gets slowed down by the amount of modules it can use. Also, allowing .htaccess overrides slows it down even more, which nginx doesn't allow.

I still much prefer Apache, and will continue to use it until I see fit to change.

[Deprecated]

I was considering mentioning that but wasn't sure it was the place to discuss it. Primarily what fascinates me is the "C10K" problem, the ability to handle 10,000 simultaneous connections! Nginx can, Apache can't, or that's what I hear.

Instead of .htaccess you handle that stuff in your server blocks. The implementation is quite different but the result is the same. (There is one server block to handle each URL being served.) As far as modules, you just add them and configure them in, PHP being a good example. (php5-fpm)

One thing I really like is how simple it is to add more sites, not that Apache might be just as easy. It's just a matter of creating a home directory, then copy another server block and search and replace the URL, restart nginx and your new site is up and running.

Up until about 18 months ago I had only dealt with shared hosting services. Since then I've really enjoyed the additional server work. It's been fun to get into a whole new world that I vaguely knew there but was always hidden from me. Even better, I have access to change things I don't like instead of having the shared hosting service tell me they won't change that just for me.