Local file link doesn't work except on home/root partition (MX linux)

So I have tried various file linking variations and the common factor is that file links work when they are in the home directory on the root partition but not when they are on another partition. This is regardless of the exact syntax used: whether “(file:///…)” or simply “(/…)” or “(file:///run/user…)” or even “(…assets/…)”.
In some cases such as adding the file as an asset or using “run/user” it finds the file but says “Document file … is locked for editing by unknown user” : And then offers the option to open in read only or to open a copy for editing.
If I open a folder location using “run/user” then any files I try to open in that folder also will only open in read only.
There are 2 file types which are exceptions to this
I am currently on MX Linux 21 (Actually AVLinux MX edition).
I don’t know if this behaviour is the same on Windows or Mac.

To use Logseq as a “2nd brain”, being able to link to files on my computer is pretty much an essential for obvious reasons. So I really hope this can be fixed.

When I open the page in Obsidian the file links work perfectly although it seems to prefer "(<file:///…>) .
So for now I may have to use Obsidian, which is a real shame because the Todo functionality amongst other things seems to work quite differently; so although I can open my Logseq pages, the 2 apps are not as compatible I would like.

Replying here from the other thread. You said:

I have tried sym-links as well as uploading files to the assets folders (which is not my preference).

As you can see, the best I can get, is the document file locked message…

I don’t understand, in the following cases, which one works and which one gives “file locked” or other errors?

  • file in the /assets folder
  • symlink inside /assets folder pointing to a file outside the graph
  • symlink pointing to a file on another partition

Also, have you checked the file permissions?

And does this happens consistently with every file, no matter the content?

However in the long run I don’t really want to have to add sym-links for every file I want to link to - it will become cumbersome over time.

In that case you can just add a symlink to your whole home or other partition.

Sorry I think I responded in the other thread…but here is def better.
So I tried so many things it’s hard to keep track of…but what it boils down to is quite simple.
Anything that is outside the root partition: which in my case includes my Logseq folder containing the assets folder either doesn’t work at all or gives the afore mentioned error.

  1. I tried creating assets from within Logseq (…/assets…) (where logseq creates a file reference with a long number at the end)
    This only worked with a PDF file. But with Libre Office docuemnts for example it gave me the error.
  2. If I simply copied the file into the assets folder and did (…/assets…original filename), then it didn’t respond at all when you click the link.
  3. I tried (file:///run/user…) and that gave the error message.
    If I linked to a the containing folder using run/user, and then clicked on the file, it did the same: The folder address was clearly some kind of relative path, not the actual path.
  4. I tried symlinks in various places including on the root partition/home folder and the assets folder: In all cases clicking the links gave no response at all.

As for the file permissions: well they open perfectly from within Obsidian and also from Thunar which is the file manager on my distro; so I don’t think that is the issue; however some of the files were created in Windows, so I will double check with files created in Linux. But as I say, if Obsidian, Thunar and other applications open the files without issue, it seems unlikely to be a permissions issue.
If you would like me to upload something, so you can see the exact syntax then let me know; although I might need some guidance on how to do that; if of course it is possible. Obviously that wouldn’t be able to test my actual file links - but you’d at least see more detail.

Again I really appreciate your getting back to me on this.

Check this reply about file locking on Linux:

In case you have those hidden files you just need to delete them.

Thanks for the thought Alex - I have double checked, but no lock files; which doesn’t surprise me because I would expect that would affect opening the files from Obsidian too if it were the case.
But obviously, really worth checking out just in case.

Obviously there is a either a difference by design between how Logseq and Obsidian handle local file linking which means that it works in one but not the other; or it is just a bug; or perhaps it’s both :slight_smile:

I also seem to remember seeing an older thread about relative file linking not working…but I think that was about a year old or something; however there was no indication that it was resolved as I recall.

In any case, I really appreciate your input again, and I will try to do some more tests with different files in different locations in the next few days.

Yours is clearly a different issue, because when the file is not found it doesn’t say “file locked”.

That error message means the files were locked somehow and as mentioned in that link, there isn’t only one way to lock a file on Linux.

Have you tried with other files, maybe download something from Internet and add it as an asset to Logseq?

To be clear, relative links should work as long as they point to something in the graph folder.

I will do some tests with some other documents; perhaps simple text documents for example.

So I created a simple text file and put it in my Linux Data partition (The same partition that my Logseq (data) folder lives).

Link file did not work: 1st of all if you use “/link” and then fill out the boxes, it creates a new page not a link (it goes blue and you can see faint double brackets)
If I type the syntax myself [TestTextFile](file:///path…) or (<file:///path…>) it goes green and looks like a link; but nothing happens when you click on it.

I tried embed file - both from original folder and also from assets folder doesn’t work
(Looks like link or something, has little icons - but nothing happens when you click on it and it doesn’t display anything)

The only thing that works is “/upload an asset” - which creates (…/assets/file name_asset number)
So long as I then select Mousepad to open the file.
If I select Libre Office Writer; then it gives me that message as before, so I can only open it in read mode. So Logseq seems to have problems with LibreOffice which Obsidian doesn’t. I will see if I can try linking to LibreOffice doc from a third app, if I can think of one to try.

Hopefully this can be some useful data.
As I mentioned before: I don’t want to have to upload everything to the assets folder anyway; from what I understand that would mean duplicating data, which would just gets messy and end up using a lot of hard drive space that I don’t have. ( over time with continued Logseq useage, I would likely want to link to a good proportion of the documents across my multiple hard drives and partitions). I would be happy to use the assets folder should I want to embed anything; but it is not a replacement for file linking for me.

I tested an audio file from an NTFS partition also: File linking did not work at all just as above.
Uploading it as an asset actually embedded the file, so it was playable from within Logseq. That wasn’t actually what I expected, but good to know. It also confirmed my concerns about file duplication and hard drive space.

I will continue trying some things. I have not yet got any sym-link to work, but I might try with some other files, just in case.

Meanwhile I am testing various combinations of plugins in Obsidian to see if I can get it to behave like Logseq … Oh what fun :slight_smile:

It would be great to know if there is any intention for file linking to be fixed in the near future.
As of now it still doesn’t work as per the above.
I don’t know if any devs are reading this bug report or not, but if so would love to hear from you.
Meanwhile I will keep checking as each update comes out, in case there are any improvements.

Since updating to 0.10.4 One txt file in assets that was fully working before is now in the semi working category (open as read only etcetera); and the run user files that were in the semi working category are now not working at all.
Just thought I would keep the thread up to date.

I think you should find what in your custom machine configuration is triggering the problem. No one can address a vague issue that no one except the report author can reproduce. Until there is a precise way to reproduce the bug there is no hope it will be fixed.