Upgrade from 2.1.4 to 2.1.6 fails, because of 'smf_2-1-5_patch.tar.gz'?

[NoError666]

Trying to upgrade SMF from 2.1.4 to 2.1.6

- Clicked on the forum admin link "upgrade to 2.1.6".
- Error, the file "smf_2-1-5_patch.tar.gz" needs to be writable.
BUT, there is no such file in the Packages directory on my server. (Almost all files in that directory are set to 0644, three is set 0666).

- So I downloaded 'smf_2-1-5_patch.tar.gz' from simplemachines.org.
- And tried to "Add package" in the forum, by uploading it, but got the error message:
"The package you are trying to install cannot be located. You can manually upload the package to your Package directory." (Bing translation)
Very strange, because the file IS existing on my local computer.

- So I manually uploaded (with ftp) 'smf_2-1-5_patch.tar.gz' to the forums Packages directory on the server, file rights set to 0644.

- Clicked again on the forum admin link "upgrade to 2.1.6"...
... same error as in the beginning. It says:
"The following files need to be made writable to continue with the installation:
/smf_2-1-5_patch.tar.gz"

What is going on?

[Aleksi "Lex" Kilpinen]

If you uploaded the package manually to your /Packages folder, then you should be able to install it in Admin -> Package Manager. Forget the link to upgrade.

[NoError666]

The smf_2-1-5_patch.tar.gz file is in /forum/Packages/ on the server (uploaded with ftp).
But there is no package in Admin - "View packages", message "No packages yet".

The forum and packages folder are located in folder /forum/ (has been so for many years).

All paths settings seems ok, but maybe the 2.1.4 version thinks the package folder is in the web root?

[Aleksi "Lex" Kilpinen]

Interesting, I'd suspect either there is something really wonky with permissions - or something in the server configuration is stopping SMF from actually interacting with the files. Can you double check the file is still there? If it is, do you have access to your server's error log? If you do, is there anything there that could be related?

[NoError666]

The file is there (rights 644. Folder Packages has 755).

Checked server error log, and php error log, no (related) errors.

[Kindred]

suggest deleting the 2.1.5 file directly on the server and trying again through the package manager - not direct upload to the server.
Either use the link at the top of the package manager or use the "upload a mod" in to package manager to upload the patch.

[NoError666]

suggest deleting the 2.1.5 file directly on the server and trying again through the package manager - not direct upload to the server.
Either use the link at the top of the package manager or use the "upload a mod" in to package manager to upload the patch.

Deleted smf_2-1-5_patch.tar.gz from Packages folder, and followed your suggestions.
Same result as previously.

--
In the packet manager under "File rights, Current status", everything is WRITABLE. It seems ok.

But when trying to upload smf_2-1-5_patch.tar.gz (from my home computer),
with Packet manager - Add package - Upload,
it fails with error message:
"The package you are trying to install cannot be located. You can manually upload the package to your Package directory."

That causes 2 errors in the forum error log:
move_uploaded_file(/smf_2-1-5_patch.tar.gz): Failed to open stream: Permission denied
move_uploaded_file(): Unable to move '/tmp/phpT7Eftt' to '/smf_2-1-5_patch.tar.gz'

So when trying to upload a file there is a permission problem, where?
According to the packet manager "File rights, Current status" everything seems ok.

Edit:
the permission for the /tmp/ folder is 0755, so that should not be the problem.

[Kindred]

you may need 775 or 777 - depending on your host's setup

[NoError666]

you may need 775 or 777 - depending on your host's setup

same problem with permission 777 for /tmp/ folder.

But according to the forum error log:
move_uploaded_file(): Unable to move '/tmp/phpT7Eftt' to '/smf_2-1-5_patch.tar.gz'
it seems the smf script is trying to copy the file to the server ROOT?? ( / )

[Kindred]

I think that you have a bad configuration in your php settings....   Check with your host

because the only reason it would be attempting to write to THAT location is if there is a php failure

[Aleksi "Lex" Kilpinen]

What is repair_settings.php?

Maybe double check all path configurations, just to be sure. Easy with repair_settings.php

[prdx]

Edit:
the permission for the /tmp/ folder is 0755, so that should not be the problem.

The `/tmp` directory is a special location in *NIX systems, commonly used for temporary file storage by various processes and users.

The recommended permission setting for `/tmp` is `1777`. 
- The `777` part allows all users to read, write, and execute within the directory. 
- The leading `1` sets the sticky bit, which is crucial: it prevents users from deleting files they don't own, even if they have write access to the directory.

So while `0755` looks fine at a glance, it can cause issues in environments where multiple users or processes rely on writing to `/tmp`.

If you're on shared hosting, you might not have the necessary privileges to change this. 
However, if it's your own server, you can adjust the permissions with the following command:

Code (shell) Select Expand

sudo chmod 1777 /tmp

[NoError666]

What is repair_settings.php?

Maybe double check all path configurations, just to be sure. Easy with repair_settings.php

YES there it is!
The following paths are missing (for some unknown reason) accordning to repair_settings.php:
- Packages Directory: Value not found! Recommended value: "/.../Packages".
- Tasks Directory: Value not found! Recommended value: "/.../Sources/tasks".

Where can those paths be set MANUALLY? (I didn't run the automatic repair thing).

I'ven been looking for those kind of related path settings a while now but can't find them.

I think that you have a bad configuration in your php settings....   Check with your host

because the only reason it would be attempting to write to THAT location is if there is a php failure

File upload works in other platforms on that same server account,
it should be the same php settings.

[prdx]

Packages and Sources/tasks are at the same level that $boarddir is pointing (forum root).

You can do from there:

Code (shell) Select Expand

mkdir -p Packages Sources/tasks
chmod 0755 Packages Sources/tasks
Also you should use chown to make them the same owner as the www user (www-data, apache, nginx or such).

EDIT: Also, check the /tmp directory permissions described in my earlier post if you struggle to use the Packages directory, maybe it's used too for decompressing.

EDIT2: Again, Settings.php let's you configure a full path for Packages, tasks and so. But if you don't specify or the directory is not valid it will setup a valid directory relative to $boarddir:
$packagesdir = '';
if (!is_dir(realpath($packagesdir)) && is_dir($boarddir . '/Packages'))
       $packagesdir = $boarddir . '/Packages';

[Aleksi "Lex" Kilpinen]

Where can those paths be set MANUALLY? (I didn't run the automatic repair thing).

Well, you don't have to accept the suggested values, you can just input values MANUALLY in repair_settings.php - It is a dedicated tool just for this purpose.

But I think these should be defined in https://github.com/SimpleMachines/SMF/blob/release-2.1/other/Settings.php and usually do not change.

[NoError666]

prdx:
Thanks! The upgrade problem is solved, with this new lines in Settings.php, after the $boarddir and $sourcedir strings (and maybe I'll put in a path check later):
$packagesdir = $boarddir . '/Packages';
$tasksdir = $sourcedir . '/tasks';

(I've checked Settings.php before but there was no $packagesdir or $tasksdir so it was a bit confusing).

I will check with my host about the fourth bit (the "sticky" one).

Aleksi:
Thanks! The recommendations for repair_settings.php is to first backup all data and all files...
..."just in case". So for the moment I'll prefered not to mess with more than these two paths.

[NoError666]

The upgrade problem is solved, with this new lines in Settings.php, after the $boarddir and $sourcedir strings (and maybe I'll put in a path check later):
   $packagesdir = $boarddir . '/Packages';
   $tasksdir = $sourcedir . '/tasks';

clarification: the one line added
   $packagesdir = $boarddir . '/Packages';
solved the upload problem. (It assumes of course that the folder /Packages exist).

The other line ($tasksdir = ...) I did add after the upgrade was completed.
The absence of that path during the upgrade did not seem to had any effect on the upgrade. (And no errors in the error log).

The `/tmp` directory is a special location in *NIX systems, commonly used for temporary file storage by various processes and users.
The recommended permission setting for `/tmp` is `1777`. .....

for the shared server system my host is using,
the recommendation is 0755 for the /tpm/ directory (and other directories),
I've been told when I asked about the 1777.

Anyway, permissions of the /tmp/ directory had nothing to do with this upload problem,
despite the forum error log:
   move_uploaded_file(/smf_2-1-5_patch.tar.gz): Failed to open stream: Permission denied
   move_uploaded_file(): Unable to move '/tmp/phpT7Eftt' to '/smf_2-1-5_patch.tar.gz'
Because the problem was the missing path to the Package folder,
that caused the forum script trying to copy the file to the root of my server account.

[prdx]

Anyway, permissions of the /tmp/ directory had nothing to do with this upload problem,
despite the forum error log:
    move_uploaded_file(/smf_2-1-5_patch.tar.gz): Failed to open stream: Permission denied
    move_uploaded_file(): Unable to move '/tmp/phpT7Eftt' to '/smf_2-1-5_patch.tar.gz'
Because the problem was the missing path to the Package folder,
that caused the forum script trying to copy the file to the root of my server account.

It may have something to do indeed.

move_uploaded_file(): Unable to move '/tmp/phpT7Eftt' to '/smf_2-1-5_patch.tar.gz'

This command attempts to move a file from the `/tmp` directory to another location.

If `/tmp` has permissions set to `0755` and the file isn't owned by the same user, the operation will fail. That's because a "move" operation is actually a copy followed by a delete — and you can't delete the original if you don't have sufficient permissions.

That said, I suspect your hosting provider may handle this with additional configurations — like assigning a special group to `/tmp` and including all relevant users in that group, or something similar.

But as you said, the destination was probably a bigger problem than the temporary file placement. Hopefully the fix you applied in the `Settings.php` using `repair_settings.php` file solved it!