mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: Symlinks are not properly traversed in a library #1427
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#1427
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @chris6611 on GitHub (Sep 30, 2023).
Describe the issue
AudiobookShelf is not properly traversing symlinks in the filesystem.
I have a very large mounted folder of audiobooks at /mnt/unionfs/audiobooks/Audiobooks_English so to trim down the library for audiobookshelf, I have a folder at /media/username/audiobooks containing symlinks to folders in the aforementioned folder.
When I add the folder of symlinks to a library, the full path gets appended to the symlink path if the symlink folder's volume is not in the full path.
Scenario 1:
For example, /media/username/audiobooks -> /audiobooks in docker, and /mnt/unionfs/audiobooks/Audiobooks_English -> /mnt/unionfs/audiobooks/Audiobooks_English in docker.
The path attempted to be found is /audiobooks/mnt/unionfsAudiobooks_English/B.V. Larson; I assume '/audiobooks' is removed from the full /mnt/ path because its the folder name of the symlink-containing folder within the container.
Scenario 2:
For example, if /media/username/audiobooks -> /abs in docker, and /mnt/unionfs/audiobooks/Audiobooks_English -> /mnt/unionfs/audiobooks/Audiobooks_English in docker, then the attempted path to be found is '/abs/mnt/unionfs/audiobooks/Audiobooks_English/B.V. Larson'.
Screenshots are below:
Scenario 1:
Scenario 2:
Can this be fixed so that we can be allowed to use symlinks within the container? The paths may need to be handled differently by possibly checking if each of the root library folder's subfolders is a symlink using fs.lstat on the subfolders and within the callback function, call the .isSymbolicLink() method.
Steps to reproduce the issue
Audiobookshelf version
v2.4.3
How are you running audiobookshelf?
Docker
@RXWatcher commented on GitHub (Oct 3, 2023):
I just hit this issue as well.
@nichwall commented on GitHub (Oct 3, 2023):
https://discord.com/channels/942908292873723984/942908295579062335/1150947935861870714
(Message from above discord link)
I believe this is due to the nodejs library used for interaction with the filesystem
Watcher used for watching for changes in the filesystem. As of right now you should be able to symlink files, but not folders.@RXWatcher commented on GitHub (Oct 3, 2023):
Well, the problem I'm having is that ADS just crashes with the huge directory that we have with 200K audiobooks so I was creating symlinks based on the first letter of the authors last name..ala instead of /audiobooks/author/audiobook_title/audiobook_title.mp3 for all 200K, I was making a different directory structure: /audiobook_symlinks/A/author/audiobook_title/audiobook_title.mp3. I can try making symlinks to the actual files. It'll just require a bit more scripting to do it..otherwise I'm fiddling with modding fileUtils.js to just accept symlinks and find the correct target path.
@amasover commented on GitHub (Jan 13, 2024):
I ran into this issue today, running Audiobookshelf as an app on Truenas Scale. I experienced it as @nichwall stated: file symlinks work correctly, but not folder symlinks. Neither hostpath volumes, nor NFS shares work (as both will expose the symlinks inside the container, I believe).
My old installation was to run Audiobookshelf in a container on a VM, with my data accessible via an SMB mount configured in the VM's fstab. Thus, the SMB server was responsible for resolving symlinks, and they were never exposed to the VM or the container. So I never ran into this issue before, despite heavily using symlinks. As a workaround, I can probably revert back to the old setup.
Do we know what the exact issue is with the upstream dependency? And is there an issue open against that project that we can track?
@aetx commented on GitHub (Apr 10, 2024):
For my setup (relative symlinks and running Audiobookshelf directly via node/systemd service), changing the setting for
realpathto false inrecurseFiles(server/utils/fileUtils.js) fixes the problem.However, I am not familiar with the codebase (nor node.js tbh) and don't know what other problems this might cause, but it is a workaround that seems to work for me (for now).
@admlko commented on GitHub (Feb 1, 2025):
I can confirm changing
realpathtofalsefixes this issue but also not sure what are the implications in the bigger picture.Would be great to get this supported but for now, I just have to remember to change the setting when upgrading Docker image.
@Sreini commented on GitHub (Jul 8, 2025):
just want to chime in and say I am also running into this right now
@ezra-sg commented on GitHub (Feb 10, 2026):
I was able to get around this issue by using a relative path for the source directory when making the symlinks. In my case, the source volume is at the root of the audiobookshelf container fs, and for whatever reason it didn't like when I did an absolute path with
ln -s. So for example, from within/audiobooks/Author Name/Book Nameyou should runln -s ../../../my-source-direcrory/book-name/* "/audiobooks/Author Name/Book Name"Hope this helps!