Upgrade falid 3.0.1 -> 3.1.0.1 (Unable to move files)

Software Support
, ,
1

Hi everybody!

I was tryng to upgrade my OJS version from 3.0.1 to 3.1.0.1, but I’m getting many errors while upgrading the database.

All like this example:

[homolog] < PHP Warning:  rename(files/journals/10//articles/5085//submission/5085-108-24112-2-2-20180321.docx,files/journals/10//articles/5085//submission/proof/5085-108-24112-2-10-20180321.docx): Arquivo ou diretório não encontrado in /srv/www/periodicos/releases/4/classes/install/Upgrade.inc.php on line 2586
[homolog] < Unable to move "files/journals/10//articles/5085//submission/5085-108-24112-2-2-20180321.docx" to "files/journals/10//articles/5085//submission/proof/5085-108-24112-2-10-20180321.docx".

In portuguese “Arquivo ou diretório não encontrado” means file or folder not found.

BUT, the file is there:

$ cd /srv/www/periodicos/shared/files/journals/10/articles/5085/submission/
$ ls
5085-108-24112-1-2-20180321.docx  5085-108-24112-2-2-20180321.docx

Could it be a error with path formation? (10//articles) and (5085//submission)?

I beliave that this is not a permission issue, because the user who is trying to peform the update is the owner of the folder and subfolders.

I’ve tried to run the command with sudo:
$ sudo php {{release_path}}/tools/upgrade.php upgrade
Then I get a permission issue.

2

Hi @rafaelmansilha,

Check that your files_dir is set correctly in config.inc.php. It looks like you might have files in there, but you probably need to specify a full path.

Regards,
Alec Smecher
Public Knowledge Project Team

3

Hi @asmecher,

files_dir = files

I’ve automated the upgrade process using the deployer tool, so the files_dir folder is in a shared folder and is referenced through a symbolic link:

$ ls /srv/www/periodicos/shared/
config.inc.php  files  public

Symlink:

/srv/www/periodicos/current$ ls -lsa
0 lrwxrwxrwx   1 www-data www-data     32 Mar 27 10:28 files -> /srv/www/periodicos/shared/files

Can a symbolic link cause this failure?

4

Hi @rafaelmansilha,

Possibly – but also beware of accidentally exposing your files_dir for direct access via the web server. This is a dangerous configuration and can lead to server compromises, e.g. if authors upload harmful submissions in script formats that can be executed server-side. At the very least, it can lead to your submission documents being exposed to anyone who can guess their URLs.

Regards,
Alec Smecher
Public Knowledge Project Team

5

Hi @asmecher,

Now I see i’ve been setting the shared dirs after the database upgrade, as the last upgrade didn’t change the files, it occur without problems.
Thank for the heads up, We have take the precautions :wink:

Regards,
Rafael Mansilha.

6

Hai @rafaelmansilha,

how to solve this problem? I have the same problem.
Can you help me?

Dear,
Aprik

7

Hi @Aprik,

I was using Deployer to do the upgrade, as Files where in a symbolic dir I was trying to do the database upgrade before de deployer sett de symlink for files dir, in my case, I just had to change deployer recipe to make the symlink for files dir before the database upgrade.

Check for permissions, it may be it.

8

hi @rafaelmansilha

so this is just a matter of permission?
I already gave 777 / rwx

I’m not familiar with Deployer, But i wanna try. Can you give me a reference on how to upgrade using Deployer?

Dear,
Aprik

9

I could be a matter of permission, but as you have give 777, it should’t be.

Have you look at files_dir = files in your config.inc.php?

About deployer, I’ve just optimized, using a recipe, but you could look at the docs: https://deployer.org/docs/getting-started.html

10

Hi all! Just a couple of quick notes on files/permissions…

  • 777 permissions are never safe to use. They can be valuable for testing but please don’t leave them set that way.
  • If your files_dir is set to files in config.inc.php, your installation is probably unsafe! The files_dir should be configured outside your web root, or if that can’t be done, it should be protected from direct access via the web server. See docs/README.md under “Recommended Configuration” for more on this.

Regards,
Alec Smecher
Public Knowledge Project Team

11

Dear @asmecher @rafaelmansilha,

I don’t think my case is about access permissions. Maybe another problem.

I also found this problem:
Fatal error: Uncaught Error: Call to a member function getId() on null in classes/install/Upgrade.inc.php:2476 Stack trace:
#0 lib/pkp/classes/install/Installer.inc.php(415): Upgrade->fixGenreIdInFileNames(Object(Upgrade), Array)
#1 lib/pkp/classes/install/Installer.inc.php(265): Installer->executeAction(Array)
#2 lib/pkp/classes/install/Installer.inc.php(186): Installer->executeInstaller()
#3 lib/pkp/classes/install/form/UpgradeForm.inc.php(40): Installer->execute()
#4 lib/pkp/pages/install/InstallHandler.inc.php(104): UpgradeForm->execute()
#5 lib/pkp/classes/core/PKPRouter.inc.php(372): InstallHandler->installUpgrade(Array, Object(Request))
#6 lib/pkp/classes/core/PKPPageRo in classes/install/Upgrade.inc.php on line 2476

Can you help me?

Regards,
Aprik

12

Dear @asmecher @rafaelmansilha,

Thanks for your help.

I have successfully upgraded.
I checked the database and replaced the data in the ‘genres’ table which contained the data in entry_key = Null.

But there are still many problems that arise. One of them is the appearance of OJS so messy.
I will try to fix it.

If I am not successful, please help me.

Regards,
Aprik