The object cannot be accessed due to insufficient user rights

[Libro1]

I think I got some new info about this known issue.
After trying in vain everything I found on this website about it (and more), I noticed the error happens to me when any of the folders -leading to the file I’m trying to save- contain even a single instance of the character “#”. When I remove that, everything seems to work fine. I’m working on a Windows 10 machine, trying to edit files on a Qnap NAS. It only happens to LibreOffice files on the NAS. Should I make a bug report? Where? Thank you, I hope this report helps someone

EDIT: Clarification

[Villeroy]

Rename the office document with # in its name so it has a .zip suffix and try to open it with a zip tool of your choice (office documents are zipped xml).
I would expect that the zip tool shows the same problem.

[Libro1]

It does not show any error, actually. I tried by renaming it (Windows just opens the zip as a folder, showing me what’s inside the archive (see attached screenshot). If I create a .zip with 7-zip instead, then it just zips the file. But more importantly, the issue does not seem to happen for hastags in the file name. That in itself does not cause any error. The issue arises if there are hashtags in any of the folders of its path.


\\192.168.0.1\Grandparent\Parent\File.ods = No error
\\192.168.0.1\Grandparent #\Parent\File.ods = Error
\\192.168.0.1\Grandparent\Parent #\File.ods = Error
\\192.168.0.1\Grandparent\Parent\File #.ods = No error

[Villeroy]

Then it might be an issue with LibreOffice indeed. LO identifies files by URLs rather than path names. In URLs the # has a special meaning.

[Libro1]

Thanks, I didn’t know that. Do you perhaps know where I can find out more info about the way LO works with special characters in file paths? I’ve only managed to find this topic: Apache OpenOffice Community Forum - [Solved] Can't open files if special characters in file path - (View topic)


I’m trying to understand if I can tell LibreOffice to deal differently with hashtags in paths or if I should substitute every hashtag in my system with a plus sign, that seems to not cause any problem. It would be a lenghty task, because I use hashtags everywhere to find my stuff quickly.

[erAck]

Whether LO internally handles it as file URL or not should be transparent (and a contained URL reserved character be encoded internally). In fact I can load and store files in directories containing a # hashmark or space hashmark without problem on Linux. Though that might be a problem in the system file path conversion, I’d suspect something in conjunction with the NAS used; I’d assume that storing in such directory on a native Windows drive wouldn’t be a problem. If you could try?

[Libro1]

Your assumption is correct, there’s no problem if I try that. And I suspect the cause might be found in the system file path conversion as well. In fact, I tought about asking this on the Qnap forum, but while researching the error I started finding results in this one, so I started here.