Hey All, circling back on this after a while, I don't think it was a permissions issue after all.

I suspect the way calibre desktop and calibre-web handle capitalization is slightly different and changes stored in metadata.db are case sensitive, so when I uploaded my library folder there were for whatever reason changes to the capitalization of author names that caused the issue.

Solved this by renaming folders and files in file manager to match what the error message was expecting, for example if the "Betty Smith" folder wasn't found, I renamed lowercase "betty smith" to "Betty Smith", after which I was able to normally use calibre-web. Had to do this for ~5-10% of books which is a pain but glad to have it working again. If anyone has found a better solution eager to hear it, scanning through the library for books with missing covers was a good indicator of where the broken links were.

@joseph this is great, thanks!

@santabroo I did once have all my Calibre Web books stored on a Hetzner Cloud Volume (different from their storage boxes) and have that Mounted as Cloudron Volume.

I was rsync-ing my local Calibre Library up to that Hetzner Cloud Volume. I'm not sure if I ever tried upload via the Calibre Web interface too, but if I did I can't remember what happened.

I think it very likely would work though if you moved your Calibre Web app Data Directory to a Heztner Cloud Volume but of course this would only be possible if your Cloudron is running on a Hetzner Cloud VPS.

@timconsidine thanks for documenting this! FWIW, on the latest version I had to update the command slightly to this to get it working: python3 /app/code/calibre-web/cps.py -s user:pwd -p ./app.db -g ./gdrive.db

I copied over my local Calibre library to the Calibre Web library (located on a Volume.
One of them is Paul Auster’s „Winter Journal“ in the epub format. The book shows up fine, I can open it in the browser to read it, but when I search for „Auster“, I get the above error.

@timconsidine yeah, I think TTS is a functionality of the desktop app.

I found this existing feature request in calibreweb issue tracker - https://github.com/janeczku/calibre-web/issues/2897

I remember this tripping me as well. When you create a user, the default permission does not include reading the book (not sure why, maybe something to check upstream). You have to check the Allow eBook Viewer permission on the right hand column.

image.png

@jdaviescoates Hello

I don't know if this is much help, but I have landed on using the following procedure:

First, on my Cloudron box, I mount my library as a shared volume. I then sync this volume to the Calibre web app using the following syntax:

rsync -azP --delete /mnt/volumes/<volumeid>/ /home/yellowtent/appsdata/<appid>/data/library

Notice the trailing slash on the source, but not on destination.

The drawback on this method is that changes I make in the Calibre web app are overwritten when doing an rsync. So I try to not use the web app for changes (uploads, metadata edits etc).

More on this on this topic: Calibre not able to write on mounted (cifs) volume

I was about to say the same thing as @girish looks like the issue is something to do with Cloudflare.

I also spotted this:

image.png

09:00:15.390
Some cookies are misusing the recommended “SameSite“ attribute 2
09:00:15.390 Cookie “remember_token” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite login
09:00:15.391 Cookie “remember_token” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

@girish said in Calibre not able to write on mounted (cifs) volume:

@odie so, just to take a step back. If we ignore all this CIFS stuff ...

On Cloudron the library is at /app/data/library by default. This maps to the host path at /home/yellowtent/appsdata/<appid>/data/library (might want to double check this path). Is that path not enough to sync via ssh?

Thanks. I've been moderately successful with this.

I can sync using rsync and the -rz (and rzv, rzP) flags.

The syntax I use is:

rsync -rz /CIFSshare/ /home/yellowtent/appsdata/<appid>/data/library

This way, I manage to sync from the CIFS mount to the /home/yellowtent/appsdata/<appid>/data/library folder. Calibre-web now runs with a writeable database.

Two minor problems with this:

using the -r option, everything syncs on every subsequent execution of the command (ie all files are copied from the CIFSshare) using the -a option instead of -r, the database would be writeable on first sync. But using the -a option resulted in a locked db on second, third etc. run.

The bigger problem is this:
When I use rsync, changes I make on the Cloudron/calibre-web app are not synced back to the NAS folder. So basically, this leaves me to lose edits made via Calibre-web on Cloudron every time I update the library from one of the clients (since local changes on Cloudron calibre-web are not synced to the CIFS share). Relying on a manual sync after every library update on Calibre-web is next to impossible (I often read on my mobile devices, and I like to edit metadata while reading).

So basically, it almost appears safer to keep the library on a read-only CIFSshare...

I have this same problem. The Calibre database mount is treated as read only, despite being read+write in both my "volumes" window (I mount as CIFS in Cloudron, and the folder is both readable and writeable in the file explorer), and as read+write in the calibre web app locations setting.

When trying to upload a file to the database, I get an error message "Oops! Database Error: database is locked." in the Calibre app, and the following output from the error log:

Sep 10 20:06:09[2023-09-10 18:06:09,560] DEBUG {cps.uploader:261} Temporary file: /tmp/calibre_web/d7303b9d1838487ba3d8f808792aa2c8 Sep 10 20:06:09[2023-09-10 18:06:09,804] ERROR {cps.helper:560} Rename title from /tmp/calibre_web/d7303b9d1838487ba3d8f808792aa2c8 to /media/CalibreLib/Unknown/[00-test]testaddcmx (614) failed with error: [Errno 1] Operation not permitted Sep 10 20:06:14(Background on this error at: https://sqlalche.me/e/14/e3q8) Sep 10 20:06:14[2023-09-10 18:06:14,858] ERROR {cps.editbooks:304} Database error: (sqlite3.OperationalError) database is locked

From the terminal (Calibreweb terminal when cd'ing /media), owners and permissions are listed like this:

root@3590754a-5015-4c95-a587-3048aa867498:/media# ls -al total 8 drwxr-xr-x 1 root root 4096 Sep 9 12:26 . drwxr-xr-x 1 root root 4096 Sep 9 12:26 .. drwxrwxrwx 2 998 998 0 Sep 10 18:06 CalibreLib

Additionally, I also have the same problem as described in this folder (the database location is not stored persistent):

https://forum.cloudron.io/topic/4215/calibre-web-database-location-is-not-stored-persistent/6

Even if the app is not updated, it resets folder location after every nightly backup, it seems.

My Cloudron is v7.5.2 and the Calibre Web App is running the latest version.

Any ideas on how to troubleshoot and fix these two errors?

Thanks!

(moved from separate thread)

Hello,
So, I had a different post asking if using Google Drive would work, then went ahead to try anyway. I followed this guide: https://github.com/janeczku/calibre-web/wiki/G-Drive-Setup

It worked! For about 10 days. Now, suddenly, the app can't see the Google Drive. Anyone have any idea what happened?

And, the drop-down menu where you can choose the GDrive folder doesn't work, so it seems it might be a Cloudron-related issue?
3886d2ac-69a1-4f4c-b277-30a51145af76-image.png

Thanks!

So the "guest" user is already used internally for anonymous access https://github.com/janeczku/calibre-web/issues/949

Just tried this again with latest version and email change works now.

LDAP was removed from the package.

We have removed LDAP, so will close this thread for now.

Is there any more info on this and can someone reproduce this?

Latest package version has both backend and frontend updated now. We had to remove the anyways not working LDAP though. See https://github.com/janeczku/calibre-web/issues/2652

@nebulon indeed this one is 👌