[Enhancement]: store the books in a cloud #1097

Closed
opened 2026-04-24 23:31:57 +02:00 by adam · 11 comments
Owner

Originally created by @vsuh on GitHub (Apr 24, 2023).

Describe the feature/enhancement

It would be great to have ability to store some part of collection in some cloud.

Originally created by @vsuh on GitHub (Apr 24, 2023). ### Describe the feature/enhancement It would be great to have ability to store some part of collection in some cloud.
adam added the enhancement label 2026-04-24 23:31:57 +02:00
adam closed this issue 2026-04-24 23:31:58 +02:00
Author
Owner

@Weldawadyathink commented on GitHub (Apr 25, 2023):

FYI, you can use rclone to mount cloud storage as a local filesystem, and audiobookshelf can use that. It takes some setup, but once it is working, its reasonably reliable. I have had a similar setup running without issue for about a year now.

I remember some discussion about using an s3 compatible service as storage a while back on discord. It would be a really neat feature.

@Weldawadyathink commented on GitHub (Apr 25, 2023): FYI, you can use rclone to mount cloud storage as a local filesystem, and audiobookshelf can use that. It takes some setup, but once it is working, its reasonably reliable. I have had a similar setup running without issue for about a year now. I remember some discussion about using an s3 compatible service as storage a while back on discord. It would be a really neat feature.
Author
Owner

@advplyr commented on GitHub (Apr 25, 2023):

Can you be more specific?

I think it is up to the user to mount volumes where the books are.

@advplyr commented on GitHub (Apr 25, 2023): Can you be more specific? I think it is up to the user to mount volumes where the books are.
Author
Owner

@Weldawadyathink commented on GitHub (Apr 25, 2023):

I think it is up to the user to mount volumes where the books are.

Yeah, that is what I was referring to. For example with the rclone docker plugin:

volumes:
  audiobooks:
    driver: rclone
    driver_opts:
      remote: 'server:path'
      allow_other: 'true'
      vfs_cache_mode: 'full'
      vfs_cacbe_max_size: 2G
      no_modtime: 'true'

The idea from discord was to have audiobookshelf use s3 storage directly, not through something like rclone. ABS would put files into s3 itself, then instead of hosting the downloads through the ABS server, the client could download or stream the files directly from s3. It could open up some interesting scenarios like having ABS hosted on a server with relatively poor bandwidth, but still have downloads and streams be super fast because the files are hosted through amazon (or any other cloud provider). It is probably much more work than it is worth, but it would be an interesting feature.

@Weldawadyathink commented on GitHub (Apr 25, 2023): > I think it is up to the user to mount volumes where the books are. Yeah, that is what I was referring to. For example with the rclone docker plugin: ``` volumes: audiobooks: driver: rclone driver_opts: remote: 'server:path' allow_other: 'true' vfs_cache_mode: 'full' vfs_cacbe_max_size: 2G no_modtime: 'true' ``` The idea from discord was to have audiobookshelf use s3 storage directly, not through something like rclone. ABS would put files into s3 itself, then instead of hosting the downloads through the ABS server, the client could download or stream the files directly from s3. It could open up some interesting scenarios like having ABS hosted on a server with relatively poor bandwidth, but still have downloads and streams be super fast because the files are hosted through amazon (or any other cloud provider). It is probably much more work than it is worth, but it would be an interesting feature.
Author
Owner

@vsuh commented on GitHub (Apr 25, 2023):

not everyone deploys the audiobookshelf image to the clouds. Some (like me) run the server on their home LAN. Storing books in the cloud would allow you to listen (or put new books) while away from home.

@vsuh commented on GitHub (Apr 25, 2023): not everyone deploys the `audiobookshelf` image to the clouds. Some (like me) run the server on their home LAN. Storing books in the cloud would allow you to listen (or put new books) while away from home.
Author
Owner

@AeonPrime commented on GitHub (Apr 25, 2023):

So if you're running it locally, what stops you from accessing it while away? I am running ABS at home as well and I have set up port forwarding to the docker host and have no issues accessing the service from anywhere.

Where I store the books doesn't have any effect on whether or not I can access them via ABS. As long as you can mount the cloud as a a path or volume on the host machine, you can add it to the library, doing so myself.
And about adding new books ABS has an upload feature or you could just look into accessing your local infrastructure remotely.

Sure, direct cloud integration would be neat, but considering it's already possible I don't see the problem here.

@AeonPrime commented on GitHub (Apr 25, 2023): So if you're running it locally, what stops you from accessing it while away? I am running ABS at home as well and I have set up port forwarding to the docker host and have no issues accessing the service from anywhere. Where I store the books doesn't have any effect on whether or not I can access them via ABS. As long as you can mount the cloud as a a path or volume on the host machine, you can add it to the library, doing so myself. And about adding new books ABS has an upload feature or you could just look into accessing your local infrastructure remotely. Sure, direct cloud integration would be neat, but considering it's already possible I don't see the problem here.
Author
Owner

@Dr-Blank commented on GitHub (Apr 27, 2023):

@vsuh

not everyone deploys the audiobookshelf image to the clouds. Some (like me) run the server on their home LAN. Storing books in the cloud would allow you to listen (or put new books) while away from home.

You can mount your cloud storage to your local machine using rclone. I suggest you look into it if you haven't already, and if you have but cannot seem to figure out any part, feel free to ask in discord or reddit, it is really easy to set up.

Besides I don't think providing native support for cloud storage should be even supported, there are tools specifically to handle that.

@Dr-Blank commented on GitHub (Apr 27, 2023): @vsuh > not everyone deploys the `audiobookshelf` image to the clouds. Some (like me) run the server on their home LAN. Storing books in the cloud would allow you to listen (or put new books) while away from home. You can mount your cloud storage to your local machine using [rclone](https://rclone.org/). I suggest you look into it if you haven't already, and if you have but cannot seem to figure out any part, feel free to ask in discord or reddit, it is really easy to set up. Besides I don't think providing native support for cloud storage should be even supported, there are tools specifically to handle that.
Author
Owner

@advplyr commented on GitHub (Apr 29, 2023):

This will not be supported for the reason @Dr-Blank mentioned

@advplyr commented on GitHub (Apr 29, 2023): This will not be supported for the reason @Dr-Blank mentioned
Author
Owner

@mpldr commented on GitHub (Jan 8, 2024):

May I ask to reopen this? My reasoning being, that mounting network shares is notoriously error-prone, and I would much rather my uploads fail, than that they fill up my limited local storage. UI wise, there is also some free real-estate below the "Browse for folder" button where an "Enter Remote Location" could be placed. I would also propose not to add anything fancy like caching, that's for people using the backend to figure out as this – like OIDC – would be a more advanced setting.

Just my 2¢ :)

@mpldr commented on GitHub (Jan 8, 2024): May I ask to reopen this? My reasoning being, that mounting network shares is notoriously error-prone, and I would much rather my uploads fail, than that they fill up my limited local storage. UI wise, there is also some free real-estate below the "Browse for folder" button where an "Enter Remote Location" could be placed. I would also propose not to add anything fancy like caching, that's for people using the backend to figure out as this – like OIDC – would be a more advanced setting. Just my 2¢ :)
Author
Owner

@jph commented on GitHub (Sep 19, 2024):

I've tried mounting storage volumes using goofys1 and rclone2 and neither work. There are generalised io errors in the logs. I can provide logs if anybody is interested however this issue does appear quite stale.

Unfortunately, expanding your storage in this way when it comes to docker has lots of problems. I've rarely had it work at all.

@jph commented on GitHub (Sep 19, 2024): I've tried mounting storage volumes using goofys[^1] and rclone[^2] and neither work. There are generalised io errors in the logs. I can provide logs if anybody is interested however this issue does appear quite stale. Unfortunately, expanding your storage in this way when it comes to docker has lots of problems. I've rarely had it work at all. [^1]: https://github.com/kahing/goofys [^2]: https://rclone.org/
Author
Owner

@davinkevin commented on GitHub (May 17, 2025):

I would love to see it implemented.
The application is not really friendly with NFS (like almost everything else btw)

Object storage like minio is easy to setup for home-lab or more… and adb could leverage it for the best of those operating adb 😉

@davinkevin commented on GitHub (May 17, 2025): I would love to see it implemented. The application is not really friendly with NFS (like almost everything else btw) Object storage like `minio` is easy to setup for home-lab or more… and adb could leverage it for the best of those operating adb 😉
Author
Owner

@luolong commented on GitHub (Feb 11, 2026):

I would like to add another reason for supporting S3 natively. It is pricing.

When hosting libraries on cloud, the volume needed to host a large'ish library of books, the HDD volume prices tend to go up much more rapidly than when storing them on S3 compatible storage backends.

@luolong commented on GitHub (Feb 11, 2026): I would like to add another reason for supporting S3 natively. It is pricing. When hosting libraries on cloud, the volume needed to host a large'ish library of books, the HDD volume prices tend to go up much more rapidly than when storing them on S3 compatible storage backends.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#1097