If you checked the path and permissions are okay, then I would still encourage you to check the disk usage at that path. Based on the triggers for that error, I see the following possibilities:
- Target path does not exist (but if you uploaded a different file type, then it probably does)
- Target path is not writable (file permissions)
- Target path's disk is full or does not have enough space left to write the file (this is possible, especially if you have partitioned the hard drive, and have not placed the wiki attachment directory in a large data partition).
- Target path uses a stream wrapper instead of an absolute path (doesn't appear to be the case here)
- Unable to get an exclusive file system lock on the target path
- The source upload file disappeared from disk before it could be written to the target path (don't think I've ever seen this happen, but possibly it's related to a problem in the Imagick implementation, see below)
As for the 502 and underlying errors:
In VaultWiki we have hardcoded a time limit of 5 seconds for processing a user upload via Imagick, in order to protect you when a botnet tries to upload 100 files at once and possibly freeze your server. This limit was added because Imagick is designed in such a way that it is vulnerable to image bombs (small image files that can inflate to millions times memory and/or time usage) and other security holes.
When added to the 1 second connection limit and the 3 second transfer limit, this results in 8-10 seconds of time allotment per image uploaded.
You can work around this issue by reducing the dimensions of the image you are uploading before you upload it.
OR
While we do include support for Imagick, it is only because of vBulletin's native support. We STRONGLY recommend disabling vBulletin's Imagick support on your site, as well as disabling permission for user uploads of avatars, as well as some other user image types that might let users upload images from a remote server. Also disable vBulletin's options to automatically resize uploaded images that are too large.
As we reported to vBulletin developers in late 2017, which led to them ending support for vBulletin 4 that quarter, their implementation of Imagick and some of these other image features even without Imagick contains security holes, most notably against image bombs and slow-loris type attacks, and should not be used in public without major changes. We successfully performed such attacks against our own test sites so we knew they were viable.