Module updates fail with “File Transfer failed, reason: Cannot copy”

Which version of Drupal 7 core introduced a critical bug in the update module? The last four Drupal releases have had very little changes.

I'm also experiencing this. When a new version of the module is identified by Drupal and I then try to update it gives this error. At first I thought it might be something to do with file permissions on the tmp directory but I have tried with 777 and even removing the htaccess file but no joy. Could it be related to a change in PHP version on the host? I'm on 7.97 with PHP 7.2.34.

The error message from the issue summary suggests, that the problem is likely with the permissions of the sites/all/modules folder, not /tmp folder. Please double-check the owner and permissions of that folder, so we can confirm or rule out this. Thanks.

I also have the same problem - permissions are fine but all updates fail but downloads are in temp folder. I can successfully move the files to the relevant modules folder and restore the site functionality but not sure what the bug is?

Is SELinux involved?

Server is running Cloud Linux.
PHP version 7.2

Hello.

I have the similar issue with update module. It doesn't want check and views available updates on my Drupal 7.96:

There was a problem checking for available updates for Drupal. Check the available updates page for more information and to install missing updates.
There was a problem checking for available updates for your modules or themes. Check the available updates page for more information and to install missing updates.

When these problems started? Last releases were only security releases not touching update manager or similar. Last bigger release was in December 2022 - 7.93. Were you able to download updates after you upgraded to 7.93? Does this started only when you upgraded to 7.94 or later?

Do you have anything relevant in watchdog / server error log? Probably some other error message, etc.?

Thanks for your response poker10

I'm on Drupal 7.97 and I have updated since 7.93

I have the following error logs on the server:
[22-May-2023 09:32:42 Europe/London] PHP Deprecated: dirname(): Passing null to parameter #1 ($path) of type string is deprecated in /home/golffeaturescom/public_html/includes/common.inc on line 2970
[22-May-2023 09:32:42 Europe/London] PHP Deprecated: dirname(): Passing null to parameter #1 ($path) of type string is deprecated in /home/golffeaturescom/public_html/includes/common.inc on line 2970

[22-May-2023 16:01:10 Europe/London] PHP Fatal error: Uncaught Error: Undefined constant PDO::MYSQL_ATTR_USE_BUFFERED_QUERY in /home/golffeaturescom/public_html/includes/database/mysql/database.inc:332

The first two are running PHP 7.2. The last is switch to 8.0 which killed the site until switch back.

I have possibility to check this issue on Drupal 7.95 and 7.96 - the same behavior with errors.
Drupal watchdog doesn't record any error related to update module.
Some info from my PHP/NGINX logs:

nginx_1      | 2023/05/22 15:07:18 [info] 51#51: *575 client timed out (110: Operation timed out) while waiting for request, client: 192.168.176.5, server: 0.0.0.0:80
nginx_1      | 2023/05/22 15:07:18 [info] 51#51: *577 client timed out (110: Operation timed out) while waiting for request, client: 192.168.176.5, server: 0.0.0.0:80
nginx_1      | 2023/05/22 15:07:18 [info] 51#51: *579 client timed out (110: Operation timed out) while waiting for request, client: 192.168.176.5, server: 0.0.0.0:80
nginx_1      | 2023/05/22 15:07:18 [info] 51#51: *581 client timed out (110: Operation timed out) while waiting for request, client: 192.168.176.5, server: 0.0.0.0:80
nginx_1      | 2023/05/22 15:07:18 [info] 47#47: *576 client timed out (110: Operation timed out) while waiting for request, client: 192.168.176.5, server: 0.0.0.0:80
nginx_1      | 2023/05/22 15:07:18 [info] 47#47: *578 client timed out (110: Operation timed out) while waiting for request, client: 192.168.176.5, server: 0.0.0.0:80
nginx_1      | 2023/05/22 15:07:18 [info] 47#47: *580 client timed out (110: Operation timed out) while waiting for request, client: 192.168.176.5, server: 0.0.0.0:80
php_1        | 192.168.176.8 -  22/May/2023:15:06:18 +0000 "POST /index.php" 200
nginx_1      | 192.168.176.5 - - [22/May/2023:15:07:18 +0000] "POST /batch?id=36984&op=do_nojs&op=do HTTP/1.1" 200 221 "https://test.docker.localhost/batch?op=start&id=36984" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"
nginx_1      | 192.168.176.5 - - [22/May/2023:15:07:19 +0000] "POST /batch?id=36984&op=do_nojs&op=do HTTP/1.1" 200 242 "https://test.docker.localhost/batch?op=start&id=36984" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"
nginx_1      | 192.168.176.5 - - [22/May/2023:15:07:20 +0000] "POST /batch?id=36984&op=do_nojs&op=do HTTP/1.1" 200 222 "https://test.docker.localhost/batch?op=start&id=36984" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"
php_1        | NOTICE: PHP message: Xdebug: [Log Files] File '/proc/self/fd/2' could not be opened.
php_1        | NOTICE: PHP message: Xdebug: [Step Debug] Could not connect to debugging client. Tried: 172.17.0.1:9003 (through xdebug.client_host/xdebug.client_port) :-(
php_1        | 192.168.176.8 -  22/May/2023:15:07:20 +0000 "GET /index.php" 302
nginx_1      | 192.168.176.5 - - [22/May/2023:15:07:20 +0000] "GET /batch?id=36984&op=do_nojs&op=finished HTTP/1.1" 302 5 "https://test.docker.localhost/batch?op=start&id=36984" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"
php_1        | 192.168.176.8 -  22/May/2023:15:07:20 +0000 "GET /index.php" 200
nginx_1      | 192.168.176.5 - - [22/May/2023:15:07:23 +0000] "GET /admin/reports/updates/update HTTP/1.1" 200 5181 "https://test.docker.localhost/batch?op=start&id=36984" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"
nginx_1      | 192.168.176.5 - - [22/May/2023:15:07:23 +0000] "GET /js/admin_menu/cache/397119be3834ca5fcf5c8923cf17f044 HTTP/1.1" 200 24267 "https://test.docker.localhost/admin/reports/updates/update" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/104.0.0.0 Safari/537.36"

@ankondrat4 That looks quite different.

SELinux is a Linux security feature, not a Linux distro.

Oh, sorry, it is not related to current issue? Maybe I go to create new issue related to update module or what... I don't find any solution to repair normal work of update module now...

Re #10.

The MYSQL_ATTR_USE_BUFFERED_QUERY problem should be similar to this one: https://www.drupal.org/forum/support/upgrading-drupal/2023-01-02/undefined-constant-pdomysql_attr_use_buffered_query-in-drupalmysqldriverdatabasemysqlconnectionopen → . Probably there is some mysql extension missing on the newer PHP on the webhosting. The constant is used in the code for many years without problems and was not added recently.

Also can you please check if you have correctly set your filesystem directories and if all are writable? You can check it there: admin/config/media/file-system.

Re #13 SELinux is disabled.

@ #15 good call on the permissions Default was not writable - embarassing don't know what happend there!

On PHP extensions I have the following running:
pdo
pdo_mysql
pdo_sqlite
mysqli
mysqlnd

I too am seeing this issue, but I don't think it's caused by a cahnge to Drupal core.

The last successful module update I performed was on 27 February 2023, running Drupal core 7.94 and PHP 7.4. I made a site and database backup immediately before performing the module update. I've restored those backups and attempted to repeat the module update - it now fails.

My PHP extensions were previously set as per those in #17. I have subsequently changed them, but on reverting to those previous settings I still get this module update issue.

I don't know where to look next.

One more thing you can try is to set greater value for update_max_fetch_attempts variable, or truncate cache_update table.

Sorry @poker10, as a user, not a developer, I need to question how to make those changes.

update_max_fetch_attempts I see is a constant defined in update.module - do I simply edit the value in this file and save it? Change 2 to 4 perhaps.

And I can see the cache_update table using phpMyAdmin, but what exactly do you mean by "truncate" this.

Or maybe someone more experienced should move this forward?

SteveWilson, truncate cache_update table means do it empty, delete all rows from it. SQL query: TRUNCATE TABLE cache_update;

Thanks ankondrat4, I truncated cache_update table and attempted another module update (using my current configuration of Core 7.96 and PHP 7.4) - the error persists.

@SteveWilson What, precisely do you see on screen? Is it the same as what is in the summary of this issue?

Attached is a screenshot of what I see when attempting to update the Content Access module on my test site.

Contrary to what the issue summary states, the compressed (in my case) Content Access module file is downloaded to the tmp directory and is extracted there. The previous version of the module is deleted from the modules folder, a Content Access folder can be seen there, but all it contains is an empty README.MD file.

@ #24 exactly the same. Updates are present in the tmp folder but module folder empty.

I too have exactly the same error as #24.

Can anybody else confirm when the update was successfull for the last time?
Are you using a private filesystem?

The last successful module update I performed was on 27 February 2023, running Drupal core 7.94 and PHP 7.4. I made a site and database backup immediately before performing the module update. I've restored those backups and attempted to repeat the module update - it now fails.

So the problem is not in 7.94 and below.

7.95 was a very simple security fix - this couldn't have caused it.

7.96 was a more complex security fix - affecting system_file_download(), file_download() and image style generation. However this should only affect private files / images, so unless there is a very specific config using private filesystem somehow, then I don't think it could have caused it.

7.97 was a hotfix - this couldn't have caused it.

---------------

I have tested this on a very simple linux setup (debian) with vanilla D7.97, running PHP 8.1 and when where were correct permissions for the tmp folder and sites/all/modules folder, then the update process completed sucessfully. So it doesn't seem to be a global issue.

The error message File Transfer failed, reason: Cannot copy suggests (and the IS confirms that), that the update manager was able to delete the existing folder, but it is not able to copy a new folder here. If the permissions for sites/all/modules are correct (you can try with 777, but then revert ASAP, because it is a security risk), then I would double check if the module is physically downloaded in the tmp directory (it could have been deleted in the meantime, etc...).

I'm not using a private file system, it's a standard build profile.

sites/all/modules permissions are 755, as are sites/default/tmp.

Module files are definitely downloaded to tmp and extracted there. tar.gz file is in update-cache-xxxxxxxx, extracted folders/files are in update-extraction-xxxxxxxx.

I too conclude that this issue is not caused by a recent Drupal core update - when I revert to 7.94, the module update that previously worked, no longer does.

I'm running on in a shared hosting environment. Could this issue be caused by a change my hosting supplier has made?

I too have exactly the same error as #24.

Did you guys tried using drush up module_name?

We seem to have got a bit stuck on this.

I've just created a clean install of Drupal 7.97 with PHP 8.1 running and attempted to upload module xmlsitemap with the error as below. Attempt wth Views - same result.

Both new folders created in sites/all/modules but only Readme in xml and D7UPGRADE.txt in Views. So in the latter case the error message says the D7UPGRADE.txt file can't be copied but that is the only file that has been colpied.

Any further thoughts much appreciated, I am also wondering if there is some change on the server that is causing this. My server is on Krystal.uk

I too am hosted on Krystal.uk. Is this the case for other users experiencing this issue?

Okay I’ve taken up with Krystal

Thanks for doing that @Robar. Please do report here the outcome of your investigation with Krystal.

@SteveWilson you said in an earlier post that you found this fault on different servers? does this mean not only Krystal?

If I gave the impression that I'd experienced this fault on different servers I apologise - I am hosted only on Krystal. We know that two of us experiencing this issue are hosted on Krystal, but there are others who have not declared their hosting service. We cannot, therefore, be certain that the issue is unique to Krystal hosting.

My hosting provider is raiolanetwoks.es.

The Basic Server information is:
Versión de Apache 2.4.57
Versión de MySQL 10.6.12-MariaDB-cll-lve
Arquitectura x86_64
Sistema operativo linux
Versión de Perl 5.26.3
Versión del kernel 4.18.0-425.3.1.lve.3.el8.x86_64

Response from Krystal.

Hello Rohan,

Thank you for your response.

We've seen other reports of this issue and our system administrators have extensively investigated ruling out Imunify, modsec, permissions etc.

However, when our system administrators have been testing on Krystal and non-Krystal based machines (along with clients), the issue doesn't appear to be limited to the Krystal servers and appears to be a Drupal issue unfortunately.

As such, this is something that would need to be further reviewed with a developer until a fix is provided by Drupal.

Re #38

the issue doesn't appear to be limited to the Krystal servers and appears to be a Drupal issue unfortunately.

It would be very helpful if someone can provide steps to reproduce on a clean install of Drupal 7.97 on a standard Linux configuration (ideally not on a paid hosting, so that we can test that).

Mine has been doing this for the last two updates. I have to copy zip file for each modules to the modules folder, delete the old folder and unzip it. And hope there are no other changes. Sometimes it disables the module.

I am currently stuck on Drupal 9.2 and I dare not do any updates.
PHP 7.2.34

I did change my hosting recently, and I assumed this was about permissions or a PHP module switched off. I'm quite relieved to see there are developers working on this.

I’m getting concerned about how this gets escalated as we don’t seem to any closer to a solution.

See #40.

I posted that comment before I had finished typing.

This is a critical issue and comment #40 is from a provisional Drupal 7 core maintainer. There really is no further way for this issue to be escalated. In order to move forward a community member must:

• Determine whether the problem is platform-specific. And if it is, what are the platform attributes that differ between working and broken platforms?
• Determine whether the problem is caused by Drupal. And if it is, which specific version of Drupal introduced the broken behavior?

I’ve just created a clean install of Drupal 7.97 on my localhost and can confirm that all runs fine new modules install without problem. Trouble is it doesn’t help me identity why I have this problem on my shared server. I’ll take it up with them again.

I feel there must be a clue in the failure to copy error which says it can’t copy the only file it does copy! The update process can clearly access the module folder as it has removed the existing module files so not a permissions issue. I have been unable to find any clues in either Drupal or server logs.

Update and new module installations run fine on Drupal 10. on my shared server using composer.

Any thoughts about how to identify the problem, which does appear to be platform specific, would be welcome. #44 suggestion is beyond my capabilities I’m afraid!

Some more info. This appears to be server related, not Drupal core related.

I tried it on an account running on CentOS v7.9.2009 STANDARD xen hvm and it works flawlessly (running Drupal 7.97)

For me, it fails on a server running CloudLinux v7.9.0 STANDARD standard. Not sure if that is useful info.

It applies to new module installations, too. The installer is able to create the new module directory within /sites/all/modules and even a sub-folder within the new folder and both have 755 permissions. It also creates a single zero byte file (644) at which point it craps out.

Update: my logs indicated that it's related to Imunify 360

Sure enough, I went to the Imunify 360 settings panel in cpanel and then to its Proactive Defense section. There, I could see a list of failures. I went to the first error (a block) and clicked the gear and chose "ignore detected rule for the file" which adds the rule to the Ignore list.

After that, I was off to the races and was able to run updates and installs. Hope that applies to some of you other folks, too.

Brilliant @bearstar conform that's a fix. Many thanks

Thanks @bearstar, this also works for me. For the sake of completeness, and for Drupal core maintainers, I've included a screenshot of the imunify360 error message.

I don’t think there is anything that can be done about that on the Drupal side—it is not a critical bug in Drupal. I suggest this issue should be made a normal support request.

Many thanks @bearstar. The problem was with Imunify360 for me too. 'Ignore all rules for file' for ../includes/filetransfer/local.inc sorted it and I can now perform updates again. :-)

Thanks everybody for your valuable information!

It really works, but we should know what caused this error and what we changed with this setting, whether it will cause problems later.

It would be great if someone can get in touch with the hosting, to check the reason why the Imunify360 is flagging/blocking the filetransfer/local.in, as it seems that this did not happen in the past. Then we can check if is caused by any change in Drupal, or only more strict control by these external services. Thanks!

Okay I’ve gone back to Krystal to see what they can tell us.

The hosting provider said there were no changes to their system.
The interesting coincidence is that before that there was an error phenomenon that I had never experienced before: the size of the database suddenly became 8 GB, cPanel showed this, but phpMyAdmin showed the normal size of 40 Mb. Because of this, the storage space was also marked as full, but the registration, content uploading and backup from Drupal still worked. The service provider said that they don't know the reason, because they can't look that deep into MySQL and cPanel either. They said it was caused by stuck data. What is stuck data? And 8 GB???

Response from my hosting provider, doesn’t help much!

In most cases it'll be Imunify360's ModSecurity rules detecting something in the POST request which has a signature similar to that of some sort of malware injection.

There are thousands of rules in ModSec, so it's actually rather common for some things like updates to get falsely flagged.

Beyond disabling the specific rule that's causing the issue, we won't go much further into it.

I don't know whether it helps, but attached is the full Imunify360 report, for the action it performed, for one of my failed Drupal module updates (it's a sequence of screenshots I'm afraid - I couldn't see how to export the report).

The Imunify360 change log indicates that changes are introduced very frequently.

The Drupal 7.98 update fixed the problem, no need for the Imunify360 exception setting

The only issue I can think about that could have caused this to work is this: 🐛 [D7 backport] Update status does not verify the identity or authenticity of the release history URL Fixed . Drupal 7.98 changed the default URL for fetching the updates from HTTP to HTTPS, so if Imunify360 was complaining about the links being insecure, this could have an effect on that.

I think that the introduction of Drupal 7.98 is a red herring. I installed 7.98 and removed the Imunify360 exception, and yes, module updates then installed correctly. But I wanted to test whether it was the HTTP to HTTPS change in D7.98 that fixed it. So I set:

$conf['update_fetch_url'] = 'http://updates.drupal.org/release-history';

in settings.php and retried a module update - it worked perfectly.

I poked around looking at other changes in D7.98 but got nowhere. So I decided to revert a site to a pre D7.98 state - just to confirm that the issue is still present there. It isn't - having reverted to a D7.96 site and database backup I tried a module update and once again it worked perfectly.

I am forced, therefore, to conclude that a faulty, corrupt or inappropriate rule in Imunify360 was causing this issue and that it has now been fixed.

Whether I'm right or wrong, I'm happy for this issue to be closed.

Thanks to all contributors to this issue.

Years ago, I was a prepress operator. There, only the printing press could spoil what I did. Ever since I've been in the online world, creating websites, I've often thought of giving up on this whole thing, because it depends on so many things whether something is good or not, and what's good also breaks down because one of the components (hosting provider, php, mysql, server component changes, but even the ISP) can mess something up. This is so fucking shit. And then I didn't even talk about modules and browsers.