Evert Wagenaar's picture

Hi all,


I tried this for several days now. Unfortunately it does't work. I use the WordPress Jessy Virtual Appliance with Parallels Desktop 12.


Update WordPress

Downloading update from https://downloads.wordpress.org/release/wordpress-4.8.1-no-content.zip…

Download failed.: cURL error 28: Operation timed out after 299976 milliseconds with 5192319 out of 6532179 bytes received

Installation Failed


I get the 'Download failed.: cURL error 28:....' message after a few minutes. Seems it times out when iy's almost done...


Any help would be greatly appreciated.





JanKo's picture

Had the same problem. Check you VM network adapter type settings when the vm is powered off. The selected network card is probably the legacy version. Try changing it to the virtio adapter. In my case the download was much faster then and the timeout didn't occur anymore.  Hope this helps. Cheers, Jan 
Evert-Jan's picture

Did you use Parallels Desktop for Mac? I can't find any setting for the Network Adapter. Can only choose between WiFi and Default.
JanKo's picture

Yes, it's Parallels Desktop 12 for Mac. I'm not using the English version so I'm not sure about the labeling, but try looking in your VM config settings under the hardware tab (with the VM powered down). When you select your network (e.g. Network 1) in the list to the left your should also see matching details. You are right that there is a dropdown for selecting the standard adapter, wifi (bridged) or host-exclusive network. I have mine set to bridged network and there to the standard-adapter. Below the dropdown you'll find a tiny triangle which opens up some advanced settings. There you will (hopefully) find the adapter hardware which will be emulated. This is where you can switch it from legacy to Virtio or other types like intel PRO/1000 MT.    Best of luck, Jan
Jeremy Davis's picture

So perhaps JanKo's suggestion might help?

There is also a possibility that it's related to permissions. It may be caching the download to a location it can write to, but if so, then the last step would be to move the complete download to where ever it will be unzipped. If it can't write to this final location, then that may be causing this issue?

You can test that fairly easily by logging into your server via SSH and then manually download it like this:

curl https://downloads.wordpress.org/release/wordpress-4.8.1-no-content.zip
If that succeeds, then that demonstrates that the issue is likely not networking (unless it's intermittent network problems).

If so, try giving the webserver account (www-data) full read/write access to the WordPress webroot (/var/www/wordpress) like this:

chown -R www-data:www-data /var/www/wordpress
Please note that this isn't WordPress security best practice, but it's the price that you need to pay for the convenience of being able to do updates via the WebUI.

Add new comment