Version: 6.4.5 Severity: minor Bug Description: When you access "My Computer" with Nemo, if you find listed disks that are not mounted at boot, you cannot access them by double-clicking on them. You need to right-click and choose "Move up" to bypass the problem, or access it via the left sidebar. Thank you to correct this as soon as possible. Best regards. Philippe
Hi Philippe, thanks for the report, and sorry for the late reply. I tried to reproduce it on Debian 13 with nemo 6.4.5, adding a disk with unmounted ext4 partitions (also one listed in /etc/fstab with noauto): in "Computer", a double-click mounts the partition and opens it, after asking for the password. So it probably depends on the disks you have. Could you please tell me: - which disks and filesystems they are (internal or USB, NTFS, encrypted, ...) - what exactly happens on double-click: an error message (which one?) or nothing at all - the output of these two commands, run as your user: lsblk -f gio list -a standard::display-name,mountable::can-mount computer:/// By "Move up" in the context menu, do you mean "Monter" (Mount)? Best regards, Fabio
Hello Fabio, I hope you’re doing well :) When Debian 13 was released, I couldn’t mount any disks by clicking 2x on them in "My Computer". While doing new tests, I just realized that the problem is fixed for EXT4 drives but it persists with NTFS drives. - Absolutely nothing happens when I click on it. - Yes, it is indeed about Mount (Monter) and not Move Up. Sorry, this is due to a translation error from "Reverso transator"... The disks affected by this issue are : - PC801 NVMe SK hynix 512GB: Volume de 511 Go NTFS /dev/nvne0n1p3 - WDC WD121KRYZ-01W0RB0: Medias NTFS /dev/sda1 I am attaching 2 files "lsblk -f" and "gio list -a" containing the results of the commands made. All good to you and best regards. Philippe
Hi Philippe, thanks for the details and for the attachments. I tried again on Debian 13 with nemo 6.4.5, this time with NTFS, on a disk laid out like your Windows one (EFI, MSR, NTFS data, NTFS recovery). In "Computer", a double-click on the NTFS volume asks for the password, mounts it and opens it; after unmounting it, a second double-click mounts and opens it again. When the NTFS volume is marked dirty (as Windows can leave it, e.g. with "Fast Startup"), the mount fails, but nemo shows an "Unable to mount location" error, both with double-click and with "Mount". So I still can't reproduce the "nothing happens". The double-click and "Mount" send the same mount request, so I need to see what happens on your system. Could you please: 1. tell me whether a password prompt appears when you use "Mount", and whether it appears on double-click; 2. open two terminals and run `udisksctl monitor` in the first one and `sudo journalctl -f` in the second one; then double-click one of the NTFS disks in "Computer", wait about 10 seconds, stop both commands with Ctrl+C and send me their output; 3. send me the output of: grep -i -e ntfs -e sda1 -e nvme0n1p3 /etc/fstab ls /etc/polkit-1/rules.d/ 4. tell me which ext4 disk you tried (a USB disk?), since lsblk shows no unmounted ext4 partition. Best regards, Fabio
Hello Fabio,
As previously mentioned, the only affected disks are NTFS.
They both have a GUID partition table.
They deliberately did not boot into Debian.
One of them is a SATA platter drive (WDC WD121KRYZ-01W0RB0).
The other is an NVME SSD (PC801 NVMe SK hynix 512GB).
1) Mount works without problems, the double click does not work however.
2) Files "udisksctl monitor" and "sudo journalctl -f" is attached at this e-mail.
3) Files "grep -i -e ntfs -e sda1 -e" and "ls etc" is attached at this e-mail.
/etc/polkit-1/rules.d/ contains no files or folders
4) WDC WD121KRYZ-01W0RB0 + PC801 NVMe SK hynix 512GB are problematic.
Thank you for trying to resolve this.
Excellent weekend to you.
Best regards.
Philippe
Hi Philippe, thanks, the journal you sent was the missing piece. The "FAILED to authenticate" lines from polkitd show that the password request is started but dismissed before you see it. I reproduced it on Debian 13 in a virtual machine: when you double-click, the second click is still held down when the password request arrives, so the Cinnamon authentication dialog cannot take the mouse and keyboard (input grab), and the request is silently dismissed. It doesn't take a slow click: a normal double-click is enough for this to happen. "Mount" works because it is activated from the menu after the button is released. So the problem is not in nemo but in Cinnamon. It was fixed upstream in Cinnamon 6.4.12 (the dialog now retries for a couple of seconds), and the fix is already in Debian testing/unstable, but Debian 13 has Cinnamon 6.4.10. I tested the fix on Debian 13 in the same virtual machine and the dialog then appears every time. A stable update takes time and may not be accepted: a recent one for a problem that affected many more users (downloading spices) took about a month to be approved. So at the moment I don't plan one just for this, but since the fix is only in a JavaScript file, you can apply it by hand if you want: sudo wget -O /usr/share/cinnamon/js/ui/polkitAuthenticationAgent.js https://raw.githubusercontent.com/linuxmint/cinnamon/46e896385aac28c2e9a8a343fb316ea62fb9cfca/js/ui/polkitAuthenticationAgent.js then log out and back in. That is the upstream file of the fix for the 6.4 series: the same file as in Debian 13 plus the fix (the same upstream commit also contains another small fix for the authentication dialog). To go back to the original file at any time: sudo apt install --reinstall cinnamon-common Could you tell me whether the fixed file solves it for you? I'm reassigning the bug to cinnamon and marking it as fixed in 6.4.12-1. Best regards, Fabio
Hello, Thank you for that very comprehensive response. To be honest, I prefer to wait until this code is validated and then integrated directly into Debian during its next update to test the result. But from what I’ve read, I think it should work. I had it analyzed by some free AIs. They found some problems to solve, I am attaching files containing their analysis for you. Best regards. Philippe
Hi Philippe, thanks for the feedback. The file is taken from the upstream 6.4 branch and, as I wrote, it contains only two fixes, one of which is the problem affecting you. Anyway, if you prefer not to try it, that's fine: from the test I did it looks like the solution, and it is already in Debian testing/unstable. About the llm analyses: I had a look. They are generic remarks on the whole file, not on the problem you reported, and they mostly concern code that has been there for years (as one of them notes, much of it comes from GNOME Shell, from which this file derives). None of them comes with a real case where something actually goes wrong. Verifying each point properly would take hours, for me and for the upstream developers, for probably little benefit, so I won't follow them up unless one of them shows up as a real problem. Allow me a more general word of caution, which is not meant as a criticism of you. Language models (LLMs) are called "artificial intelligence", and many people without experience think they really are intelligent, without any idea of how they basically work. They can be very useful, but they can also do damage. In the last months I have been using them a lot, and they have helped me a lot. But it took me dozens of hours to learn how to use them well, to set up their basic instructions and memory, and to prepare test environments for the first automatic checks. Even with all that, I always have to guide them, correct them and check what they produce. They have saved me time in triaging dozens of bugs and in contributing some fixes upstream, but I still had to spend a lot of time by hand: I don't know exactly, but surely well over a hundred hours by now on Cinnamon bug triage and contributions in the last months. Unfortunately many inexperienced users use LLMs to produce piles of bug reports and contributions without the necessary research and checks, often with poor or wrong results that only waste the maintainers' time. Just yesterday I spent time reviewing some contributions that, I suppose, were made by someone inexperienced who quickly ran an LLM on issues and bugs left open. Many of the problems that LLMs find are not very relevant, or have never been reproduced in practice. And some changes that seem to fix a small problem in a narrow piece of code do serious damage in the larger, real context. One of the changes I looked at yesterday gave me exactly that impression: it looked correct in the few lines it touched, it probably didn't come from a real problem anyone had seen, and in the bigger picture it would have broken something important. This is why I prefer not to invest too much time in fixing long lists of small problems found by quick LLM scans: the risk is wasting a lot of my time and of the upstream maintainers' time for a small advantage, sometimes with more risks than benefits. Even while I work on a specific problem, the LLMs point out other issues they notice along the way: I ignore most of them and consider only a few, after evaluating them. Best regards, Fabio
Hello Fabio, Thank you for your message. The bug is not serious, I can easily bypass it, I had reported it mainly for the comfort of other beginner users. I haven’t coded in a long time. I practiced Basic, Pascal, and a bit of Z80A assembly. But that was a long time ago... More recently, I did some CSS and bash of course :) I am very reluctant to have an AI that manages my system for me with 'root' rights. I don’t want this type of solution on my machines. But I admit that today their help has become relevant. As for me, I only use it online via free solutions. Claude is very good at 3D printing. And I really like the AIs from Infomaniak and Proton. If you had the time to describe your local AI installation to me by private message, I would be delighted. I didn’t want to burden you with these 4 AI analyses, but just point out that the code provided can certainly still be improved. However, David Zeuthen would need to have time to take care of it. I’m putting copies for him, you never know... As for me, I think we should gradually move all free code under the expertise of AI to optimize its code, but it will certainly not happen overnight... If you agree, we are waiting for the release of Debian 13.8 and if this bug is resolved, I will close it then. Best regards. Philippe
Hi Philippe, I removed David Zeuthen from Cc. I suppose you added him because he wrote the initial part of that code (for GNOME Shell, back in 2010), but he isn't involved in Cinnamon's copy, which the Cinnamon developers have maintained separately, and I don't want him to receive unwanted mail. Please avoid adding people who are not involved. And if it was for those LLM analyses, let it go: rough LLM analyses made in a simple chat should be avoided for bug reports and contributions, as I was partly trying to explain in my previous message. As for the bug, I'm closing it with version 6.4.12-1, where the fix is already present (Debian testing/unstable). The bug tracker keeps track of versions, so it will still show as affecting Debian 13 (6.4.10-2). But closing it doesn't mean the fix will be in Debian 13.8: as I wrote, a Debian 13 update just for this is not planned for now. About LLMs, since you asked: getting memories and skills written by others might help a little, but not significantly. What matters is that the person using LLMs really understands how they work, and has some experience in the things they do with them, in order to check the results. It's better to learn and write your own memories and skills, based on what you need to do, knowing exactly what is in them and why; that also helps to notice when the LLM doesn't follow them or is having problems. An essential thing to understand is that LLMs are less reliable than normal software. Apart from bugs and hardware problems, normal software produces a predictable result; LLMs, on the contrary, make mistakes much more often, and may also not follow instructions and memories. Besides that, you have to give them everything they need to have more context and reliable data: the more they rely only on their internal memory and training, the worse it gets. Having them run tests also helps a lot to reduce the problems in what they produce (without tests the results tend to be poor), and then you still need human review, preferably by someone with at least some experience. As for test environments, you have to state in the global memories that tests must not be done on the host but in the environments prepared for them (can be useful use llm on different device and remote connect to it), and take the time to prepare and test those environments. I prepared chroots, Docker containers and virtual machines with libvirt/KVM, but it's up to each person to choose based on what they need and what they have experience with (for checks, and also for part of the manual tests in the same environments). I also don't give LLMs access to my mail; for my GitHub account I created a read-only token, and I don't let them make commits (also in local). Even when they help me write or improve commit messages, mails, GitHub messages and so on, I always send them by hand, after checking them myself and, if needed, changing them again. That's also because translations of what I write in Italian have got worse since all translators started using LLMs: they change too much, sometimes cutting too much, adding things, or even ending up with the opposite meaning. Anyway, I think it's better to end this here, to avoid off-topic messages on the bug. Best regards, Fabio
After testing Debian SID + Cinnamon, I confirm that the bug seems to be resolved. Regards.