It explains why I can't reproduce the problem, but it doesn't help me figure out the cause. A docker environment isn't quite the same as a full-fledged Linux distro. For example one known problem is that you need so set a UTF8 locale to be able to access files with special characters.

Without taking a look at your actual configuration I can only guess.

Did you running the newest version of the container linked in the "YacReaderLibraryServer dockerized" post? I used this one when testing for UTF8 encoding problems and it worked fine (besides the missing locale).

The docker image referenced in the other post hasn't been updated for 9.5.0 yet...the source repo for the image definition shows an update to 9.5.0, but the lack of distributed image leads me to believe that something isn't working yet, and the author is probably investigating.

Running in Docker is just running in user space with boundaries...it shouldn't be any different than running in Linux natively. And prior to 9.x, I had no problems at all running the server in Docker. So I'm just trying to find out what changed in terms of system calls between 8.5.0 and 9.x.

One thing I did notice is that 9.x now creates settings files under /usr/share/yacreader, so I tried changing the ownership of that directory to the user running the server...but that didn't make any difference. Fundamentally, I can't figure out why the "Directory not found." error is occurring, when the path does exist. There must be *some* other requirement than the path just existing, such as access to a data file or something.

It is different from running Linux natively. Yes, with the correct configuration there is no difference, but a docker image is a stripped down version of the Linux distro it is based upon. It does not provide the same environment as a full distro, just the bare necessities. Here's an example:

www.yacreader.com/forum/support-linux/11...s-w-special-chacters

If you want me to help you on this you have to give me something to work with. I can not help you based on assumptions. I need the docker file and the actual configuration, so I can reproduce your environment.

Btw, we do not work with system calls. The only change we introduced into the source code that could be related is path verification. As for the question why this particular feature fails in your case I can't even guess without taking an actual look at the setup.

Giving you my existing Dockerfile wouldn't help...I use a private base image and private repositories, so you wouldn't be able to build it. I can try to come up with a version that does the same things using public images and repositories, to reproduce the problem more generically.

However, this is why I was referencing the other report for the same symptom on the "official" image...it seems like the problem is happening there as well, and that's with an image using public content.

Thanks.

I've just tested with the new "official" docker image which runs 9.5.0. I can add, create and update libraries just fine. I don't think that the server code is the problem here, but you can always run git bisect and prove me wrong

My suggestion is that you try running the "official" image and see if this helps. If it doesn't, please post the process (logs) that led to the failure to find your mount so I can try to reproduce the issue.

Actually … I have one more idea. Have you tried running the YACReaderLibraryServer commands on the container as root?

It took me a long while to resolve this one, but it seems that the problem is building the server on Fedora (or using the libraries that are packaged for Fedora).

I kept going over and over the code and the build, not being able to figure out what had changed with 9.5.0 that caused this problem, and what were the relevant differences between my Docker image and the "official" one. In the end, I couldn't really identify anything of significance, other than the fact that I was starting from Fedora. So, even though I hadn't had any problems with Fedora prior to 9.5.0, I tried building my image based on Ubuntu, i.e. switching the library packages as bundled for the Debian-based systems.

Shazam! Everything works fine, no problems at all. In the end, I was able to back out every other change I had made for debugging purposes, so that the only difference between my starting point and what is now working just fine is that I'm starting from Ubuntu instead of Fedora. And that's just fine with me. I have no concerns with just using Ubuntu as my base image...but I wanted to let you know in case you wanted to investigate why building the image from Fedora resulted in this problem.

Building from Fedora originally wasn't a problem (I had a working Fedora-based image for a year prior to the 9.5.0 release), but it seems to be the problem now. My guess (and this is only a guess) is that the server build is being affected by something in one of the Fedora packages providing the Qt libraries that changed or has a latent defect that wasn't being exposed prior to 9.5.0.

Many thanks for the suggestions and advice in investigating this one! And as always, even more thanks for providing such a great product!

Glad to hear that you've solved the problem. I'm still puzzled about what went wrong on you Fedora container, but I'll call it quits here - there's only so much I can test.

If you'd like to do me a favour it would be great to have some feedback on the prebuilt Fedora packages we supply on

build.opensuse.org/project/show/home:selmf:yacreader-rpm/

They compile fine, but I haven't gotten any response if they actually work as intended from our userbase so far.