Nemo 4.4.2 The location is not a folder using SMB #2411
Comments
|
I'm also experiencing this issue. I can reproduce it like this:
But restarting nemo temporarily fixes the problem. You have to do it on the command line: Maybe it is connected with a slightly different SMB issue I reported some weeks ago. |
|
Your conditions are different from mine. You are using a Bookmark and I am not. If you click on the Bookmark it is not surprising it shows that error because the bookmark is a file not a folder. |
|
As I wrote in my first answer, it is working once after login and once again after killing Nemo. |
Same problem using ftp url. Once unmounted, using the bookmark does n't work "The location is not a folder". As suggested, I tried the "killall nemo" command : the bookmark worked again, but just 1 time. (after, i have to use the 'killall nemo' command to make nemo working again) So, i tried this:
So, I don't think it is bookmark problem. but something else. |
When using Linux Mint 18, the remote folder was automatically mounted when using bookmark |
|
Just wanted to put this here too: #2049 (comment) |
|
Just thought I'd add that closing all Nemo windows and waiting a few minutes and then trying again works as a workaround. On Ubuntu 20.04. |
|
Nemo 4.8.4 on Gentoo here, still seeing the issue as of today. Do we have any idea why that is the case? |
|
Nemo 5.4.2 on freshly installed Mint 21 + updates till today, still same problem with ftp and smb links, but never ssh. This seems to be a very long-term issue indeed... EDIT: well, I should know better, just had the issue with an ssh (sftp) bookmark... |
|
Same issue on ubuntu 22.04.1 LTS with cinnamon-desktop installed, has nemo 5.2.4-1. Issue is same with bookmark or re-typing the sftp location in the location bar. I noticed that when the location is slightly different from before (e.g. adding username by starting with sftp://username@ip-address in the sftp URL) it works until that one is unmounted as well. Kind regards, Dennis |
|
This issue still exists on Nemo 5.6.4 (Mint Linux 21.1 Cinnamon 5.6.8) My steps:
I makes no difference using the bookmark or entering the url directly in the location field. |
|
After reading #2049 I can confirm the following workaround: I can successfully re-mount the bookmark IF the mounted smb folder was NOT SELECTED during unmount. Thus if I want to unmount I first have to select any other folder and then click the unmount icon of the smb folder in the sidebar. |
|
Same for me, Linux Mint 21.1 x86_64 | Nemo 5.6.4
|
|
Having this same problem... fun |
|
The thing is, this issue is now over a year old and I see no attempt to address it at all. This worries me. EDIT: I am now on Nemo 5.6.4 and it's still the same... |
|
@Joe1962 That's exactly what I was thinking. So many people are affected by this bug. But instead we now have new mouse pointers, icons, colors and Aqua theme by default in Mint 21.1. Don't get me wrong, Mint is still my favorite distro (I wouldn't use it otherwise), but I don't understand the prioritization. |
|
Exactly, the prioritization of what seems important to some doesn't seem important to the developers. And a new thing which I dislike was implemented or was not tested or overlooked in 21.1: The Move/Copy window that appears when in Nemo no longer has a minimize button. |
file when using the popup menu. - Remove leftover reference in get_icon_name() - Remove leftover location and parent ref in bookmarks_check_popup_sensitivity. Ejecting a mounted location using the eject button would fully dispose of the related NemoFile. Right-clicking and unmounting from the popup menu would succeed, but the extra reference here would prevent it from being disposed of properly, and prevent attempts to remount it later. ref #2411 - this issue can still occur but is reduced to a single reproducible case.
I have dug into this issue further and have come to the conclusion that "Locations is not a folder" probably occurs as a result of a busy server or network interruption (i.e., a timing problem). This is probably normal behavior and is probably the reason it does not happen frequently. However, what seems incorrect behavior is that Nemo seems to keep this "Location" in it's valid list even though it was never a successful operation. As a result, subsequent attempts to mount the same "Location" fail with the same "Location is not a folder" error. Nemo has to be killed and restarted in order to correct this problem. |
|
It's not about misplaced priorities. It's about being able to reliably reproduce a problem. This issue had been looked at multiple times in the past, without any luck reproducing it. A key detail that I finally realized was that in most cases the method of unmounting made a difference. The bug would seem to only occur when right-clicking and selecting unmount from the menu, not by clicking the 'eject' icon next to the location name. This is actually not the only way it manifests, but it was the first reliable way of doing so that I found. The issue is with the location's file 'object' not being fully destroyed when being unmounted. This could occur not just with smb locations, but mounts as well. The commit linked above fixes a couple of places where this was potentially occurring. It appears to eliminate the problem in many, but not all scenarios. If you primarily work in the 'list' view, you should have few problems. If you switch between view types, this will still manifest in certain scenarios. Fortunately if this does occur, changing the view type, or navigating elsewhere and back should make the location mountable once more. I'm trying to nail down the remaining causes for this still. |
|
I do not believe it to be a network timing issue, at least in my scenario. I 'git cloned' and tried to follow the code back from the error message, but had to give up after a while. I am not familiar with the codebase, do not 'speak' C (though knowledge of java allows me to understand things somewhat) and do not have a proper IDE for C development at hand, sorry... I will check the commit to see where it applies, I had totally missed it in the thread. |
This has not been my experience (i.e., your comment about the method of unmounting). I never use the method you describe. This error ONLY occurs when I try to mount an SMB folder that exists on another machine. And it occurs very rarely. But, it is not so much about the fact that the error occurs. It is more about the fact that after it occurs Nemo doesn't forget that it happened. Every subsequent attempt fails as well. It is obvious that Nemo is keeping track of the mounts it tries (whether successful or not). So, somewhere in the code there is a situation where the mount is recorded and kept even though it failed. I have setup Mint in a Virtualbox and am going to use GDB to understand the flow. Once I have done that then I will try and determine where, in the code, that it keeps track of these mount instances. It will be at that point that there is a fault in the code (as it should not record that mount if the operation is not successful). It really doesn't matter why the mount was unsuccessful (at least not for me). I only care that Nemo keeps reporting the same error simply by looking at previously acquired information. It should never make assumptions that conditions will always be the same. |
|
nice to see people working on the bugs, thank you all for the hard work, wish i knew enough to help. I just stopped unmounting networked mounts till it is fixed :) |
|
I too just randomly faced this issue, Yet with my issue this only happens with certain directories using smb , One directory in my flock has this issue and continues on that particular directory, Also noticed permissions to manage files has vanished randomly as well on that same directory, I have tested this using Nemo, PCManFM, and Thunar. Nemo is the only one facing these issues. I noticed after this issue occurred and testing with other File Managers and accessing the SMB shared directory, Nemo mysteriously worked and was able to access the directory as well. Yet the file permissions is still lost on that particular drive through Nemo. Hope this information helps on the diagnostics of the issue. |
|
Can no longer reproduce after 1f43989 but I'll wait for confirmations before closing. |
|
Trying to build nemo for testing, so kept trying "meson setup builddir" and installing the dependencies it wanted until it got to "Run-time dependency gobject-introspection-1.0 found: NO". It just won't find it even though it is now installed. For reference, this is on Mint 21.2. Any ideas? |
|
For Mint just build the deb packages - First, go into Software Sources, and enable source code repos, then refresh like it prompts you. Then, The packages will be created in the parent directory, You can also grab the packages here: https://github.com/linuxmint/nemo/releases/tag/master.mint21 |
|
ACR-Jeff: > I too just randomly faced this issue, Yet with my issue this only happens with certain directories using smb , One directory in my flock has this issue and continues on that particular directory, When you say it continues on that same directory, do you mean that after Nemo receives the error the first time that you continue to see the error? Or, do you mean that various times, after you have reset Nemo or logged in again that you see the same error on that same directory? You also mention "certain directories". Can you give us more detail about those certain directories? |
|
Mike Webster: > Can no longer reproduce after [1f43989] but I'll wait for confirmations before closing. I want to look at those changes more closely as a preliminary look makes me think you have fixed the issue I was talking about on the forum (i.e., That it is not important that the error actually occurs. It is more important (and that needed fixing) was to prevent Nemo from remembering the error once it had encountered it on the 1st instance. And so that, it is no longer necessary to restart Nemo to prevent the error from occurring. I have been trying to find out how to fix this. So, if you have resolved it great! |
Thanks, guess I used Slackware and Vector Linux for way too many years before switching to Mint, LOL. |
|
As suggested by [Sunnyhollow], on Nemo 5.6.4/ Mint 21.1 : I confirm closing all Nemo windows and waiting a few minutes and then trying again works as a workaround. |
|
FWIW, I haven't had this issue anymore since switching to LMDE 6, Nemo 6.0.2. |
|
I have not experienced this problem in some time even with a prior version of Nemo than that of 6.0.2. So, I will mark this problem as resolved. |
I am using Nemo 4.4.2. It very periodically gives an error of "The location is not a folder" when in actual fact it is a folder that I have mounted many times in the past. This is when using SMB.
Another interesting thing is that right-clicking on that folder and clicking on Properties shows Type, Size, Volume, Accessed, Modified, Created are all set to "unknown". Locations shows correctly.
It also says Permissions could not be determined.
Restarting Nemo does not help.
Logging out and logging back into my account resolves the problem.
Steps to reproduce Occurs randomly.
Expected behaviour Should open the folder
UPDATE: July 7 2023:
I have dug into this issue further and have come to the conclusion that "Locations is not a folder" probably occurs as a result of a busy server or network interruption (i.e., a timing problem). This is probably normal behavior and is probably the reason it does not happen frequently.
However, what seems incorrect behavior is that Nemo seems to keep this "Location" in it's valid list even though it was never a successful operation. As a result, subsequent attempts to mount the same "Location" fail with the same "Location is not a folder" error.
The text was updated successfully, but these errors were encountered: