Could not upload package, please check directory permissions! SMF 1.1.14 New Ins

[own3mall]

I'm having problems uploading packages to my installation of SMF 1.1.14.   

I get the following error when attempting to upload a package:

An Error Has Occurred!
Could not upload package, please check directory permissions!

I've verified that the Packages folder has been chmod to 777 along with all of its contents.  I've even gone and run Packages --> Options --> Cleanup Permissions --> All files are writable.  After I ran this, everything had been chmod to 777 successfully.  However, I still receive the error message.  I've even created a temp folder and chmod it to 777.  No avail.  I can't get this to work.

I've reinstalled SMF 1.1.14 two times now, and each time, I get the same thing.  I've started out with fresh databases.

My server runs the latest version of php 5.  I've even remoted into my server and checked to make sure the permissions were correct on the SMF files and that they were set to the right group.  They were.

Any ideas why I'm having so many issues?  Anything else I can try?

[MrPhil]

Try 755 for directory permissions. Some systems forbid access to "world writable" files or directories, for security purposes. If 755 doesn't work, try 775. See my sig > FAQs > "Proper Permissions".

[own3mall]

Try 755 for directory permissions. Some systems forbid access to "world writable" files or directories, for security purposes. If 755 doesn't work, try 775. See my sig > FAQs > "Proper Permissions".

Neither 755 or 775 work.  As soon as I change the file permissions from 777 to either of the other settings, I get this:

To download packages, the Packages directory and files in it need to be writable - and they are not currently. The package manager can use your FTP information to fix this.

I'm the admin of the Ubuntu server it's being run off of in case that helps.

[Illori]

do you have a temp folder in your packages folder?

[own3mall]

Yes, there is a Temp folder and it has also been CHMOD 777

[Tyrsson]

Try 755 for directory permissions. Some systems forbid access to "world writable" files or directories, for security purposes. If 755 doesn't work, try 775. See my sig > FAQs > "Proper Permissions".

Usually if this is the case it would be due to suexec/suPhp and it would cause a 500 internal server error.

Do you have a temp directory within the packages folder? If not create it and chmod it to 077. Then try installing it again.

[Tyrsson]

Ok didnt see that post by illori.

If that is the case, we need not only the group but also the owner..... Well you said you checked that..... So next thing...... Link us to a phpinfo file to see if that will point us in the right direction.

[Tyrsson]

If you running on Ubuntu then its a ownership issue if you have not installed and config'ed suexec. I know cause I used Ubuntu as a test case for server setup when I was trouble shooting the whole chown issue awhile back.

[own3mall]

That doesn't make sense though.  If you look at the ownership of the files through nautilus they are set to the correct group.  It's not a permissions issue (I think... will do more research, but it would surprise me since I host many websites).   Before I tried reinstalling my forums twice, my SMF 1.1.13 installation worked fine.  It had been updated to the latest version upon release since about SMF 1.1.4 and was migrated at version SMF 1.1.13 to my server without issues (so I thought).  I then tried uploading packages to my server.  The files uploaded fine, but the packages would not install correctly.  They'd say they had been installed but no changes had been made.  Thus, I uploaded the 1.1.14 installation files and tried to start from scratch.  With the latest two installation attempts to try to get the package manager to allow me to upload packages, I've been able to install mods correctly if I upload the files myself via FTP.

Maybe I should try the full installation package of 1.1.13.

[Tyrsson]

The fact that you can upload files and install correctly via ftp is a clue, since the ftp account runs as your OS user. In ubuntu apache runs as www-data by default. Without suexec installed and config'ed correctly once you run a mod install and a file is edited by the script it will be owned by www-data.

In Nix, as you probably know, you must be the owner of a file to modify it, or it must be world writable. As for mods saying they were installed, but no edits being made there are several things that can cause that.

Apache mod_security being the usual culprit or even worse mod_security2 which as far as I know you can not use a .htaccess to get around since it will cause a 500 internal server error. In rare cases it can be due to a xml read/write issue but that is rare. Or if memory serves it can be caused by an open basedir issue as well.

Also, think about this. (I just trouble shot this issue with wordpress for a telecom company I consult for).

The reason you have problems when you upload files via the script, is due to the file *being* uploaded via the script. It is then owned by www-data. When you upload the same package via ftp, its owned by YOUR system user, ie your account. Hence the issue.

FTP, is a server, but it is a server that runs as your ubuntu user, what suexec does, usually in conjunction with apaches mod_userdir is allow apache to execute php, as your user, just as FTP executes.

[Tyrsson]

Also, please note. Permission and ownership are not the same thing and its not just group, its owner as well.

[own3mall]

Every file I uploaded over FTP shows up as having these permissions set to the file or folder (after the chmod through FTP):

Owner:  vsftpd (Create and delete files)
Group:  nogroup (Create and delete files)
Others:  Create and delete files

Even the packages I uploaded myself have the same permissions set to them on the actual ubuntu server when looking at the files that were uploaded.

Perhaps I need to check out my PHP settings to see how much execution time is allowed and whether or not the file upload is set high enough. 

[Tyrsson]

Your server is improperly configured. When you upload a file via ftp, the owner and group should be YOUR user. Not the servers user. vsftpd is the server process's user. That of course is not going to work.

Here is the process.

You upload a file via ftp.
File is owned by vsftpd.
Apache (and php since its running as the APACHE user www-data) can not access the file unless its 0777.
You chomd the file 0777, but for this to take effect you will have to run the command as sudo, This DOES NOT change the owner, the only way to change the owner/group is to run a chown from terminal. Now, at this point apache(php) can access the file, however, that does not mean it has the correct ownership. It only means you have set the file world writable. This should be enough, in most cases but is FAR from ideal.

What owner and group owns your public_html directory? Please, do not give me the info from ftp, I need you to login via ssh and -ls lrt so that we get all the info about the directories and files. This will tell you for sure. I need that info either in a PM or posted here so that I can confirm ownership/group. Just to be clear, I do not need just the info about the public_html, I need the info from all the directories under public_html as well.

[own3mall]

Your server is improperly configured. When you upload a file via ftp, the owner and group should be YOUR user. Not the servers user. vsftpd is the server process's user. That of course is not going to work.

Here is the process.

You upload a file via ftp.
File is owned by vsftpd.
Apache (and php since its running as the APACHE user www-data) can not access the file unless its 0777.
You chomd the file 0777, but for this to take effect you will have to run the command as sudo, This DOES NOT change the owner, the only way to change the owner/group is to run a chown from terminal. Now, at this point apache(php) can access the file, however, that does not mean it has the correct ownership. It only means you have set the file world writable. This should be enough, in most cases but is FAR from ideal.

What owner and group owns your public_html directory? Please, do not give me the info from ftp, I need you to login via ssh and -ls lrt so that we get all the info about the directories and files. This will tell you for sure. I need that info either in a PM or posted here so that I can confirm ownership/group. Just to be clear, I do not need just the info about the public_html, I need the info from all the directories under public_html as well.

How can you say that it cannot access the file?  Clearly php and apache are able to read the files with the ownership and group settings as they are set on my server.  I'm not the most experienced when it comes to Linux, but I used the EHCP (www.ehcp.net) package to get my server up and running.  I think their scripts are written to have the right ownership set on the files... I could be wrong though.

Here are my results:

ls -lrt
total 156
drwxr-xr-x  2 root   root      4096 2011-01-07 19:55 logs
-rw-r--r--  1 vsftpd nogroup      1 2011-03-06 01:43 UPLOAD_SITE_FILES_TO_httpdocs_FOLDER
-rw-r--r--  1 vsftpd nogroup     37 2011-03-06 01:43 index.php
drwxr-xr-x 17 vsftpd nogroup   4096 2011-07-31 00:51 httpdocs
drwxrwxrwx  2 vsftpd nogroup 139264 2011-08-03 22:54 phptmpdir


-rw-r--r--  1 vsftpd nogroup    515 2007-05-08 00:17 401.shtml
-rw-r--r--  1 vsftpd nogroup    515 2007-05-08 00:17 403.shtml
-rw-r--r--  1 vsftpd nogroup    515 2007-05-08 00:17 404.shtml
-rw-r--r--  1 vsftpd nogroup    515 2007-05-08 00:26 500.shtml
-rw-r--r--  1 vsftpd nogroup    515 2007-05-08 00:26 400.shtml
-rw-r--r--  1 vsftpd nogroup   1613 2008-11-21 19:30 buy.gif
-rw-r--r--  1 vsftpd nogroup   4786 2008-11-21 19:30 checkmark.gif
-rw-r--r--  1 vsftpd nogroup    950 2008-11-21 19:30 c.gif
-rw-r--r--  1 vsftpd nogroup   7894 2008-11-21 19:30 f.jpg
-rw-r--r--  1 vsftpd nogroup    807 2008-11-21 19:30 f.gif
-rw-r--r--  1 vsftpd nogroup    627 2008-11-21 19:30 g.jpg
-rw-r--r--  1 vsftpd nogroup   7934 2008-11-21 19:30 f2.jpg
-rw-r--r--  1 vsftpd nogroup    742 2008-11-21 19:30 img.php
-rw-r--r--  1 vsftpd nogroup      0 2008-11-21 19:30 google5c5a75108bfcb0a8.html
-rw-r--r--  1 vsftpd nogroup   7906 2008-11-21 19:30 g2.jpg
-rw-r--r--  1 vsftpd nogroup     20 2008-11-21 19:30 info.php
-rw-r--r--  1 vsftpd nogroup  36738 2008-11-21 19:31 logo.jpg
-rw-r--r--  1 vsftpd nogroup  20704 2008-11-21 19:31 online.jpg
-rw-r--r--  1 vsftpd nogroup  20716 2008-11-21 19:31 offline.jpg
-rw-r--r--  1 vsftpd nogroup    250 2008-11-21 19:31 sitemap.txt
-rw-r--r--  1 vsftpd nogroup  11384 2008-11-21 19:31 specials.jpg
-rw-r--r--  1 vsftpd nogroup  14556 2008-11-21 19:31 support.jpg
-rw-r--r--  1 vsftpd nogroup  17703 2008-11-21 19:31 top-logo.gif
-rw-r--r--  1 vsftpd nogroup    786 2009-03-27 14:10 b.jpg
-rw-r--r--  1 vsftpd nogroup   8063 2009-03-27 14:10 buyspecials.htm
-rw-r--r--  1 vsftpd nogroup  10375 2009-03-27 14:10 faq.htm
-rw-r--r--  1 vsftpd nogroup  16535 2009-03-27 14:10 order.htm
-rw-r--r--  1 vsftpd nogroup   1625 2009-03-27 14:10 style.css
-rw-r--r--  1 vsftpd nogroup   6475 2009-03-27 14:10 registration.htm
-rw-r--r--  1 vsftpd nogroup    955 2009-04-23 16:29 foot.jpg
-rw-r--r--  1 vsftpd nogroup  12739 2009-04-23 16:33 specials.htm
-rw-r--r--  1 vsftpd nogroup  29199 2009-07-17 15:58 buy.htm
-rw-r--r--  1 vsftpd nogroup    192 2009-11-19 16:59 robots.txt
-rw-r--r--  1 vsftpd nogroup  10629 2010-06-01 17:06 tos.htm
-rw-r--r--  1 vsftpd nogroup  12523 2010-11-05 17:55 index.htm
-rw-r--r--  1 vsftpd nogroup     19 2010-11-05 17:57 phpinfo.php
-rw-r--r--  1 vsftpd nogroup   1900 2011-01-07 19:55 ehcpinfo.html
-rw-r--r--  1 vsftpd nogroup 107720 2011-01-22 18:42 page.jpg
drwxr-xr-x  2 vsftpd nogroup   4096 2011-05-27 21:12 Banners
drwxr-xr-x  2 vsftpd nogroup   4096 2011-05-27 21:22 cgi-bin
drwxr-xr-x  3 vsftpd nogroup   4096 2011-05-27 21:22 domains
drwxr-xr-x  2 vsftpd nogroup   4096 2011-05-27 22:15 images
drwxr-xr-x 10 vsftpd nogroup   4096 2011-05-27 22:22 live_old
drwxr-xr-x  8 vsftpd nogroup   4096 2011-05-27 22:25 support
drwxr-xr-x  2 vsftpd nogroup   4096 2011-05-27 22:25 trialpay
drwxr-xr-x 14 vsftpd nogroup   4096 2011-05-28 01:45 live
-rw-r--r--  1 vsftpd nogroup   6628 2011-05-28 02:52 support.htm
drwxr-xr-x  5 vsftpd root      4096 2011-07-31 11:49 subdomains
drwxr-xr-x  2 vsftpd nogroup   4096 2011-08-01 00:20 webstats

I notice that subdomains belongs to the root group instead of nogroup.  Could this be the problem?  My forums directory is housed within the subdomains folder. 

Here's the subdomains folder:

drwxr-xr-x 12 vsftpd nogroup 4096 2011-07-28 11:47 forums_old
drwxr-xr-x  8 vsftpd nogroup 4096 2011-07-31 10:55 forums_not_working
drwxrwxrwx 10 vsftpd nogroup 4096 2011-07-31 23:45 forums

[Tyrsson]

Here is the bottom line. Its doesnt matter what script you used to get your servers running. The fact is you used a script, which means you did not set the server up. That is fine, but what I am telling you is this. Your ftp server should NOT own your files when they are uploaded. Your account should own the files. Period. I will sort through this as soon as I get time.

[own3mall]

Here is the bottom line. Its doesnt matter what script you used to get your servers running. The fact is you used a script, which means you did not set the server up. That is fine, but what I am telling you is this. Your ftp server should NOT own your files when they are uploaded. Your account should own the files. Period. I will sort through this as soon as I get time.

I still did technically setup the server.  I installed everything it needed.  I think the permissions are set correctly.  I just tried my own basic PHP upload script that I use on multiple websites using the same permissions (same ownership and group), and I had no problems uploading the file.

[Tyrsson]

I'm sorry but your just not getting it.

In a properly config'ed server the ftp server does not run as the servers user, not when uploading to an accounts directory. This is the fundamental part you are missing.

Say for website A you have an account setup with a username = websiteusera

When you upload via ftp to that directory the ownership and group should be reported as
owner: websiteusera
group: websiteusera

When a php script running under apache modifies any directory or file it should still, after modification be reported as:
owner:websiteusera
group:websiteusera

Yours IS NOT working this way. Therefore, YOU HAVE A CONFIG issue. Now whether you choose to address it is your concern and I have no control over that. I am simply trying to save you many hours of beating your head against your desk, trust me, I have been there and done it. I however, will not continue to try and convince you of the problem you have. When you have worked on it long enough and come to the same conclusion and would like help correcting the issue, then I will pick the topic back up.

I invite you to google around the web for your specific problem and research what I have been trying to inform you about. You will see that it is an ownership issue. If it wasnt, your -ls reporting would show the account owners being the owner/group of the directories and files, not the ftp or apache users owning them. Simple as that.

Good luck

[own3mall]

Yes, I am planning on doing more research on this ownership configuration; however, you have still not addressed why the SMF upload is not working.  My PHP script can upload a file with the same exact permissions.  It seems the SMF 1.1.14 has been broken in the way it handles uploads.  Seriously, it's not hard to write a working script.  It's not looking like an improper configuration.   Users do not get their own group / ownership accounts on my server.  There's only one user in the OS, and that's my account.  I don't see how it would be a good idea with security in mind to allow websiteusera to have their own ownership and group entries on a server.  There will be too many users and groups.  The way it's setup now seems to be the best way to handle it.

And again, when I migrated my SMF 1.1.13 installation over to my server, it was uploading files correctly.  The mods just weren't being installed properly, so I decided to start from scratch.  A full install of SMF 1.1.14 reversed my problems.  I could not upload mods, but the ones I uploaded via FTP did install.

I'm not attacking what you're saying, and I appreciate the advice you've given me thus far.   I just don't see how there's any configuration issues when everything I've tried works but this SMF install. 

[own3mall]

Would you recommend this guide?

http://www.server-world.info/en/note?os=Ubuntu_10.04&p=httpd&f=8

I'd be willing to try it, but as it is now, I will probably make a backup of my config.  However, if I go down this route, wouldn't I have to create a user account on my actual server for every client that is hosted on my machine?  I'd then have to assign all of those accounts to the correct group?  They'd all have their own home directory?  This doesn't make sense.  It makes much more sense to conglomerate users into one group nogroup and have the owner be the FTP server.

I don't get it 

[Tyrsson]

Well, see here is the fundamental problem you are facing. You are trying to run a shared hosting environment without correctly provisioning for it. Its not gonna work well, and here is why.

If you have say 4 sites, then those users SHOULD own their directories (but nothing above them). There is no real way around this without causing a security, or ownership issue, like the one you currently have.

For these types of situations is exactly the reason apache's mod_userdir module and php's suexec was created. To allow the servers to run as the hosting accounts owner. The configuration of which is far beyond what I wish to offer within this topic. However, think about this.

If user A has a directory at /var/www/usera
if user B has a directory as /var/www/userb

And both are members of the same group and the ftp servers user own them we end up with something like this:

/var/www/usera   owner=ftpuser/group=usergroup
/var/www/userb   owner=ftpuser/group=usergroup

Now, you set them both to 0777 now they both have the same owner and group, which means user A can access user B's files === HUGE SECURITY ISSUE!!!

Even without the directories being 0777 its a security issue, since they are all lumped into the same owner/group you have no way of limiting them to their own directory. Bad, very very bad.

Now, here is the thing about the guide you linked to. Suexec is only going to work correctly (as far as I know) if you have apaches mod_userdir enabled and config'ed, since it MUST know the user it should be running as. Not only that, but once you enable it, with your current permissions it will throw a 500 internal error upon every request since you have directory perms above 0755 and file perms above 0644 if iirc.

Server configuration can be a VERY technical undertaking. Its something that needs planned in full before you ever install the OS.

[Tyrsson]

Also, yes at first glance it would SEEM easier to lump everyone together, but once you do that, how can you tell them apart? See what I mean..... See the example above in my last post.

Yes, every account needs its own user. Period, or you have an insecure server environment. Limiting a user to their own directory is known a chroot'ing if memory serves and its a MUST, has to be, cant get around it in a shared environment unless you want total havoc the first time someone gets hacked.

Think about this. In your current config. If one site gets hacked, they all get hacked, and you are the one that will have to clean it up. It sucks, I have had to do it for clients that have setup servers the way yours is setup now.

Each account must have an owner for you to be able to identify that user. There is no way around it. Furthermore, the servers, yes that is plural because there is more than one.

Currently we are speaking on two different servers.

1. Apache (php runs as the apache user unless you specifically provision for it not too, ie suexec)

2. Ftp, which should run as the account owner when uploading or modifying files within a users directory, ir their docroot, their hosting space.

Here is where the ownership problems comes in.

Well, I really dont know how to explain it any better than I have. For an example, take the 0777 perms off of everything, and it will break down, unless apache is also running as the ftp user.

ownership (chown) doesnt not equal permissions (chmod).

Permissions (chmod) only holds true for those users that are within a group that gives access or for the owner, unless you are in one or are the other, explicitly, then you do NOT have access. Which can be gotten around by 0777 (world readable and writable), which you have been using, and which is a bad, VERY VERY bad idea within your current config.

[Tyrsson]

Yes, I am planning on doing more research on this ownership configuration; however, you have still not addressed why the SMF upload is not working.  My PHP script can upload a file with the same exact permissions.

What permissions would those be? 0777? No good, tells you nothing cause any user can both read and write the directory or file.

And yes, I have addressed the issue repeatedly within this topic.

Maybe this will help also:

http://wiki.simplemachines.org/smf/On_file_and_directory_permission_and_ownership

[own3mall]

After doing more research, it would seem that configuring suPHP & suexec is not worth the trouble.  It would appear that every virtual host I've added would need to have its own user created and lines added to each virtual host entry in the conf file. 

If apache was supposed to run this way, they would have it running like this out of the box.  Thus, I do not think it's fair to claim that servers running without suPHP or suexec are configured improperly.  Do any hosting control panels even support suexec and set it up properly?  If so, please point me in that direction .   This is way too complicated.  Unless my hosting control panel script creates users automatically, it would be too much work to mess up everything now.

I wish it were easy to configure.  I've read guides on setting it up, but if it's not compatible with the hosting control panel, manually creating users and configuring suPHP would take too long. 

Thanks for the help Tyrsson, I really appreciate it.  I don't have the expertise to set this up.  One of Linux's main flaws is how difficult this is. 

However, even with my configuration, I still don't understand why the package manager fails to upload files.  My directories are set for chmod 777, and it will not upload using the SMF script.  Works just fine for my upload script.  The file should at least upload according to everything I've read and what you've said.

[own3mall]

Also, from the article you linked me to:

When web hosts don't use suphp or suExec:

In this case, you still own files you create using ftp. Every time you use ftp to copy files to the server, they belong to you. But the webserver on these hosts does not run as you. It may run as "nobody", or else as a special username, perhaps "www-data" -- users who don't belong to the same group as your username does. This means that the webserver will not be able to write files in your directories unless you grant world write permission to your files and directories (chmod 777 for directories, 666 for files). Any new files created don't belong to you. That means that, if you are going to need to work with them later, you'll need to make these files world-writable, and directories world-executable, so that you can edit the webserver's files or delete them from webserver-created directories.

My directories have been chmod to 777.  Why doesn't the file upload?  Did SMF specifically decide to drop support for webservers that do not run suexec or suPHP?  I don't see a reason why the package can't upload! 

[Tyrsson]

Yes many hosting control panels support suexec etc. Cpanel I highly recommend.

If it was that easy, wouldnt every one be doing it?

None ever said being a host is easy, trust me I am one.

As for why it doesnt work with 0777, that is a good question. It would take me some time with shell access to answer that.

But here is my biggest concern for the users you are hosting. You have not even addressed the security issues I have raised with your server config. Hosting is not for the inexperienced unless you are willing to spend the time to learn and do things right. You owe that to the people you are hosting.

Do they run ecommerce via your site? If so and they get hacked and by chance find this topic, well you know they could hold you liable right?

[Tyrsson]

And no SMF has not chose to drop support for servers that are not using suphp/suexec, without it though its hard in a shared environment.

[Tyrsson]

After doing more research, it would seem that configuring suPHP & suexec is not worth the trouble.  It would appear that every virtual host I've added would need to have its own user created and lines added to each virtual host entry in the conf file.

If apache was supposed to run this way, they would have it running like this out of the box.  Thus, I do not think it's fair to claim that servers running without suPHP or suexec are configured improperly.  Do any hosting control panels even support suexec and set it up properly?  If so, please point me in that direction .   This is way too complicated.  Unless my hosting control panel script creates users automatically, it would be too much work to mess up everything now.

Also, if this is truly your opinion, well, I hate to say it, but you shouldnt be hosting anyone other than your own site. Simple as that.

[青山 素子]

* 青山 素子 sighs...

Time for a professional server admin to step in and comment on some of the issues expressed in this topic. (Seriously. My day job is managing servers.)

After doing more research, it would seem that configuring suPHP & suexec is not worth the trouble.  It would appear that every virtual host I've added would need to have its own user created and lines added to each virtual host entry in the conf file.

I wouldn't recommend suPHP, but suEXEC and FastCGI (usually through mod_fcgid) work very well. Yes, it means that you'll need to make a new user/group for each domain. This is a good thing as it partitions sites from each other. The default behavior means that one site's code can affect that of another site as both would be owned by the Apache user.

If apache was supposed to run this way, they would have it running like this out of the box.

Apache was created way back when static content was the practice and dynamic stuff was created by writing applications in C or C++ using the CGI interface. It was a simpler time back then.

Thus, I do not think it's fair to claim that servers running without suPHP or suexec are configured improperly.  Do any hosting control panels even support suexec and set it up properly?

I don't think it was explicitly claimed that not using suEXEC or suPHP is improper. However, it's tricky to use mod_php with Apache and normal FTP users (as opposed to virtual). You run into a lot of permission issues that way.

I believe both Plesk and Cpanel support suEXEC. ispCP Omega does as well, but I wouldn't recommend that at this time as it's too in-flux and immature for long-term use.

One of Linux's main flaws is how difficult this is. 

Nah, it's not the fault of Linux. IIS can be a pain to configure with the interaction between application pools, user contexts, account impersonation, etc.

However, even with my configuration, I still don't understand why the package manager fails to upload files.  My directories are set for chmod 777, and it will not upload using the SMF script.  Works just fine for my upload script.  The file should at least upload according to everything I've read and what you've said.

It's probably your configuration. Depending on how the permissions are in the various directories, the configuration of Apache, and other factors, it's possible that 777 permissions won't work as they are blocked as "too open".

The main problem is probably how you are handling FTP accounts. How are you configuring these? Are you using a control panel at all? Normally, for a plain mod_php install, you will want virtual FTP accounts so you can map user and group IDs and avoid a whole ownership problem.

My directories have been chmod to 777.  Why doesn't the file upload?  Did SMF specifically decide to drop support for webservers that do not run suexec or suPHP?  I don't see a reason why the package can't upload! 

Server configuration. SMF itself doesn't care how the server is configured. There is really no special support for suEXEC or suPHP that can be added or removed.

[abhizz]

Yes, I am planning on doing more research on this ownership configuration; however, you have still not addressed why the SMF upload is not working.  My PHP script can upload a file with the same exact permissions.

What permissions would those be? 0777? No good, tells you nothing cause any user can both read and write the directory or file.

And yes, I have addressed the issue repeatedly within this topic.

Maybe this will help also:

http://wiki.simplemachines.org/smf/On_file_and_directory_permission_and_ownership

I'm using ubuntu with smf directory permission guides  and i have no problem! thanks for the wiki direct link its useful

[own3mall]

I still can't get mine to work.  I've checked and checked permissions.  It's not working on my end.  Any way to get more info as to why?   What log files should I be looking at?

Everything works but SMF's package manager on my webserver.

[own3mall]

I can upload them manually through FTP, and they install just fine.  What a strange problem to have.

[Tyrsson]

I can upload them manually through FTP, and they install just fine.

Sorry but I do not have the time to re-post and repeat myself at length but the above quote should tell you all you need to know.

[abhi]

Yes, I am planning on doing more research on this ownership configuration; however, you have still not addressed why the SMF upload is not working.  My PHP script can upload a file with the same exact permissions.

What permissions would those be? 0777? No good, tells you nothing cause any user can both read and write the directory or file.

And yes, I have addressed the issue repeatedly within this topic.

Maybe this will help also:

http://wiki.simplemachines.org/smf/On_file_and_directory_permission_and_ownership

I'm using ubuntu with smf directory permission guides  and i have no problem! thanks for the wiki direct link its useful

Yes! you are right if we start with smf permission guides all will be fine! Before i have some problems in my ubuntu server with smf now all are fine!! Thanks community contributors