Ultimaker
[5.7.1] Cura can no longer load in STL files: "cannot open files of the type of "
Cura Version
5.7.1 EDIT: also appears to be happening on 5.10.0 AppImage.
Operating System
Linux Arch
Printer
Not relevant
Reproduction steps
When drag-and-dropping STL files into Cura, the following message is displayed:
cannot open files of the type of
(note that the actual file extension is not even in the message)
~~Uninstalling and reinstalling~~ Rebooting fixes the problem for 2 or 3 uses, then the same problem starts to occur again. Even without having restarted the App. Restarting the App does not fix the issue, only a ~~full reinstall~~ reboot does.
It appears the extension of the file gets lost somewhere in the process of loading it.
Actual results
cannot open files of the type of
Expected results
Load the STL, as it did before.
Add your .zip and screenshots here ⬇️
See above.
Thanks for the report. Take a look at #16249 and see if @MariMakes suggestion works for you.
@GregValiant today I encountered the issue again. I checked the Marketplace and could not find the STL Reader at all! (The STL Writer was present)
I rebooted (which solved the issue, as per the above description) and checked again: it was still missing. So I guess something is going wrong here.
After the problem hits, use the "Help | Export file for technical support" command. Zip that smf file and post the zip folder here. It will contain a project file, the model, all your settings, and your Cura.Log file. Maybe something in there will give a clue.
Here's the requested file:
(Note that I had to change the file extension from .3mf to .txt because Github didn't allow the former)
Also, an extra observation: Today I tried loading in a 3MF model instead of an STL. This gave the same behavior.
With Cura running, go to the MarketPlace and select the "gear" icon. Scroll down to "USB Printing" and "disable" it. After restarting Cura see if you can load a file. Do you happen to have a USB device plugged in to the computer (ear buds, headphones, etc.?). It looks like Cura is trying to connect to a serial device that is not a printer and the routine just keeps looping.
I just encountered the issue again. I disabled the USB printing in the Marketplace, restarted the app, tried to load in an STL, ... same issue.
Do you happen to have a USB device plugged in to the computer (ear buds, headphones, etc.?).
Not really. I do have a USB-C docking station connection, as well as a KVM switch, but aside from that nothing weird.
Extra info: I just noticed that "Open recent" can still open the files when the bug is active. However, if we browse to the same file and then drag&drop, it refuses again.
Now this is even more interesting!
I just found out that, if the bug occurs, I can fix it by clicking File -> "New Project". In the warning dialog about the bed being cleared, I click "Yes". After that, I can drag STL files to Cura again. Heck, it even appears they load remarkably fast, compared to how long it usually takes.
EDIT: I think I have what is going to create a breakthrough! I tried to drag a new file to the board just now. Surprisingly, it loaded the previous STL again. I tried this several times through various methods, every time it opened the previous. Even after restarting Cura or clicking "New Project".
This leads me to believe that because of some bug, Cura is overwriting the path of the selected model with the previous one. In the case I created just now, it's an existing one. However, in most cases I haven't loaded anything yet that session. So it's overwriting the path to the model with an empty string. Because this is not an STL file, it says it's not supported. This also explains why the sentence in the error message appears incomplete. The filetype is "" (empty string). Hence, the error message doesn't make sense.
I have been able to work around the issue for a while, but today it's back to square one. Cura is again barely usable.
I recorded the behavior I described in the previous comment. Please pay attention to the filenames that I drag and compare it to what appears on the board. https://github.com/user-attachments/assets/31d10828-183e-4d7d-85e7-802f735717a6
It is clear that regardless of what file is dragged, it's always loading in the string of the previous model. Note that this scenario is difficult to end up in: when performing these actions immediately after loading Cura, the path to the model it's trying to load is an empty string, resulting in the error "Cannot open files of ".
EDIT: This also happens with the latest 5.10.2 and 5.11.0-beta .release.
@HellAholic I can't reproduce this on my Windows system. Is it something you can look at?
Cura receives binary PNG data (the thumbnail or preview icon from the file manager) instead of the actual file path during a drag-and-drop operation. This explains:
- The incomplete error:
cannot open files of the type of - The “previous file” re-loading behavior (because Cura’s file path buffer isn’t being updated)
- The log containing PNG binary data
The problem only occurs after some time or after the user interacts with the file manager — consistent with desktop environment (DE) drag-data caching issues.
Most Linux file managers send multiple MIME types on drag-and-drop, such as:
- text/uri-list → proper file path(s)
- image/png → thumbnail preview (for icons)
- text/plain → fallback
Normally, applications like Cura pick the text/uri-list entry, but if a file manager or custom Qt theme changes the MIME order or encoding, Cura might receive the PNG thumbnail blob first and treat it as the filename. Which looks like it's the case based on the logs.
This issue is specific to:
- AppImage builds (using their own Qt runtime, isolated from system Qt) - Such as Cura
- Certain Arch-based setups with custom GTK/Qt theme bridges (e.g., kvantum, qt5ct, qt6ct, breeze, etc.)
Try another file manager, or temporarily disable the custom themes and see if the issue resolves.
Oh wow! This is amazing! I've been bathing in frustration for what feels like ages now, and all I had to do was install a different file manager!
I tried Thunar now and after a brief experiment the problem indeed appears to have vanished! (Was able to drag and drop 4 objects without encountering the issue once. Also didn't have to resort to any workarounds)
AppImage builds (using their own Qt runtime, isolated from system Qt) - Such as Cura Certain Arch-based setups with custom GTK/Qt theme bridges (e.g., kvantum, qt5ct, qt6ct, breeze, etc.)
I believe this part of your analysis is incorrect though. I had the issue both with AppImage builds, as well as with binaries installed through the package manager. I do use Arch, but not with a GTK or Qt theme I believe.
In any case, many thanks to you @HellAholic ! You have made my life a lot easier :D
I will leave it up to you maintainers to decide whether this ticket should be closed now, or if a solution should be added now that we know the root cause. (E.g. add a fallback where Cura will try the second MIME type when it detects the first one didn't contain the path to an STL)
Small update: I now also had the bug with Thunar... So maybe I was just lucky last time...