filebrowser
filebrowser copied to clipboard
symbolic links
filebrowser no longer follows symbolic links. Is there a way to get this feature back?
So, this is a good topic. It was removed for a couple of reasons, but I think there are circumstances I could enable it back.
First let me explain the reason I turned off following symbolic links:
- Symbolic links could include files outside of the index path.
- the way the index works, you specify a root path for the index and it walks through the directory and builds the index based on that path.
- Do you have symbolic links that point to directories or files outside of the root path? All files in the index need to have a path scoped to the index, so I didn't yet protect the index paths against that issue.
- Symbolic links can be circular -- which would mean the index would build forever and consume all memory. So even if the symbolic link is in in the root path, I would need to guard against circular links, and I didn't spend any time doing that.
So now, let's have a discussion about what kind of symbolic links you have and want supported:
- Are your symbolic links to folders? do they go outside of the specified root path?
- Do you expect the files to be searchable ?
- Can you provide any screenshots/ additional info how you use it on the OG filebrowser and how you would like it to work on this version.
I think I know how I could reintroduce symlinks with the following restriction:
- symlinks must link to somewhere inside the same index path given (ie
server.root)
Would the above restriction still work for your use case?
First of all, thank you very much for the quick and detailed response.
My use case is as follows: filebrowser is running under termux on an Android phone. I use it to exchange documents and photos or to stream music and videos via a direct Wi-Fi connection between Android, iOS, Windows and Linux devices. Termux uses symbolic links to make the Android directory available within the termux environment. The root directory for the shared files is therefore already a symlink outside the script directory. Since I have relatively few files and mainly photos are exchanged, indexing plays a minor role for me.
how interesting! That's a very unusual use case. (and now I want to try it)
Unfortunately, I don't think I plan to add out-of-scope symlink support because of the indexing complexities that would be introduced. I'll investigate how to make it possible, but I don't think it will be an option for this version.
However, I could see the top-level root path being symlinked and supported -- would that work? For example, if your root path was a symlink, such as:
/sdcard/symlink -> /sdcard/appdata/another-path
Then for the above I could make the root path work root: /sdcard/symlink
I think it would be just fine if the root path (or source path) was a symlink, just not sub directories (well, out-of-scope symlinks, that is. I could definitely support in scope symlinks)
That would be worth to evaluate. And for my use case, it would be sufficient as all the files being shared are within the android file system. Another approach could be to start the filebrowser from an folder within the android file system. The scope would change to not symlinked folders and files. I will try this tomorrow. However, I have to check if this is compatible with the scripts and tools I'm using to control the server via the android GUI. Next solution could be to activate symlinks only of indexing is disabled. It would be the most restrictinv workaround however for use cases with only few files to share acceptable.
I managed to set the correct path without using symlinks by setting both the root and sources:path to /storage/emulated/0/
Great! btw, it should have a warning, but using root and sources accomplish the same thing, and root gets ignored if you specify a source:
[WARN ] server.rootis configured but will be ignored in favor ofserver.sources``
ill leave this open, because its still worthwhile to support:
- in scope symlinks
- root path symlinks
Hi, thanks for your work on this fork!
Whilst symlink support is missing, it should be added as missing in the feature list. It would have saved me some troubleshooting time. I recommend any other removals from OG filebrowser also be listed.
My use case
I use symlinks to keep my config tidy.
- I don't want a bunch of sources down the left hand side, there are too many
- I prefer a single source with folders for each source
so
- I create a folder containing symlinks to all my sources (web htdocs folders)
- for increased neatness, i only include the web folders for which I require file access
- this is a total of a dozen or so locations
workaround
- i could point quantum at my /var/www folder
- but there would be too many sites included
- i do not want file access to all of them
- and i also have to click through htdocs to get to the files, which is annoying
notes
- i am unable to get the following to do anything
- include folders
- exclude folders
- ignoreZeroSizeFolders: true
thoughts appreciated
config
[root@next quantum]# cat config.yaml
server:
port: 8020
database: /opt/quantum/database.db
sources:
- name: "all"
path: "/opt/quantum/paths"
symlinks
[root@next quantum]# ls -laR
.:
total 76
drwxr-xr-x. 4 root root 68 May 4 20:37 .
drwxr-xr-x. 9 root root 131 May 4 20:01 ..
-rw-r--r--. 1 root root 120 May 4 20:49 config.yaml
-rw-------. 1 root root 131072 May 4 20:38 database.db
drwxr-xr-x. 2 root root 25 May 4 20:37 paths
drwx------. 2 root root 6 May 4 20:39 tmp
./paths:
total 0
drwxr-xr-x. 2 root root 25 May 4 20:37 .
drwxr-xr-x. 4 root root 68 May 4 20:37 ..
lrwxrwxrwx. 1 root root 32 May 4 20:37 web1 -> /var/www/web1.com/htdocs/
lrwxrwxrwx. 1 root root 32 May 4 20:37 web2 -> /var/www/web2.com/htdocs/
lrwxrwxrwx. 1 root root 32 May 4 20:37 web3 -> /var/www/web3.com/htdocs/
lrwxrwxrwx. 1 root root 32 May 4 20:37 web4 -> /var/www/web4.com/htdocs/
lrwxrwxrwx. 1 root root 32 May 4 20:37 web5 -> /var/www/web5.com/htdocs/
lrwxrwxrwx. 1 root root 32 May 4 20:37 web6 -> /var/www/web6.com/htdocs/
lrwxrwxrwx. 1 root root 32 May 4 20:37 web7 -> /var/www/web7.com/htdocs/
lrwxrwxrwx. 1 root root 32 May 4 20:37 web8 -> /var/www/web8.com/htdocs/
lrwxrwxrwx. 1 root root 32 May 4 20:37 web9 -> /var/www/web9.com/htdocs/
lrwxrwxrwx. 1 root root 32 May 4 20:37 web10 -> /var/www/web10.com/htdocs/
lrwxrwxrwx. 1 root root 32 May 4 20:37 web11 -> /var/www/web11.com/htdocs/
lrwxrwxrwx. 1 root root 32 May 4 20:37 web12 -> /var/www/web12.com/htdocs/
./tmp:
total 0
drwx------. 2 root root 6 May 4 20:39 .
drwxr-xr-x. 4 root root 68 May 4 20:37 ..
I won't be able to support the above under a single source, it could create conditions that are impossible to index (recursion).
I think you have two options you could try:
- You could create a source for each
webdirectory, you probably already know this, but that is certainly an option. - You could specify
/var/www/as your root source, then populate theincludesto have a list:
include:
- /web1.com/htdocs/
- /web2.com/htdocs/
- ...etc
or event try the excludes. I need to look at the includes logic, you may have to specify the parent directory too like:
include:
- /web1.com/
- /web1.com/htdocs/
- /web2.com/
- /web2.com/htdocs/
But I think that would include the entire web1.com directory with /web1.com/htdocs/ being redundant, which I don't think you want.
I will try again the includes and report back
I went with one source, and use of exclude to avoid the project folders I don't want
I guess I will have to live with having to open /site/htdocs to see my files.
This is one of two major annoyances in this version of FileBrowser. The other being #739
So much so that I find myself loading the og FileBrowser rather than Quantum.
Cmd+s Saving files is an easy painless fix.
Adding symbolic link support is not so easy. It's at PDFs with the index, which is essentially a full backend rewrite of the OG FileBrowser.
It takes some work to get working and as I mentioned earlier symbolic links that link to outside of the index may never be supported... I will see what makes sense when adding it for 0.8.0.
It's a fairly niche use case, but I know it's sad to have some things not work on quantum because other than a few small things it's better in every other way.
I have the same issue with the links. I have a base folder /data with lots of subfolders and in one of the /data subfolders I create user folders where I add symbolic links to paths that the user can see, so my "user management" is partly in the subfolders.
A user x can have his home folder as /data/home/x and in this folder links to /data/something1 and /data/something8 Another user y can have his home folder as /data/home/y and in this folder links to /data/something3 and /data/something4
In filebrowser this allowed me to have fine grained access control per user, without this it is not very practical.
@vtacquet sounds like all of your symbolic links would be within the same source scope? That support is planned and tracked here. But if any symlinks break out of the source scope those will be considered dead symlinks from filebrowser's perspective.
I just tried creating a symlink that points out of the current source and it surprisingly does seem to work. While I understand that some people might enjoy this "feature" I think it's a security hazard.
I can't think of any way to create a symlink through Filebrowser currently but it's an easy thing to overlook in development. As an example: imagine a feature where you can extract .tar files. This would allow to upload symlinks and thus to escape the current scope. Also, someone might use Filebrowser together with another fileserver, which would also allow injecting symlinks.
I agree that implementing symlinks within the scope is a good idea, but allowing to escape the scope using symlinks seems like a source for vulnerabilities.
Also, deleting symlinks is currently not possible and will result in the target being deleted, which is quite unexpected behavior.
That's a great point about the security concern, but I think how I was planning to implement this could avoid that.
I have not tested this at all, so I am not sure the full extent of support currently.
I would describe it more as the extent of its removal rather than the extent of support. Given that the OS supports it symlinks removing them or scoping around them or limiting them in another way seems like quite a task.
Depends of your point of view 😅
Not really, removing support for them usually just requires using lstat instead of stat for getting file information. That way, you modify the link and not the target.
Bringing back parts of the functionality would definitely be more challenging.
Yes. Non supporting symbolic link is reason i didn't turn on quantum but i do have lot of attention on it. Maybe i need to re-think about symbolic links.
Here's another use case:
Internet-in-a-Box (IIAB) (see https://wiki.iiab.io/go/Main_Page) uses an ingx web server with document root at /library/www/html/. A general purpose "local_content" subdirectory at /library/www/html/local_content/ is exported as http://box/usb. This provides an easy-to-locate browser-based resource for users to have shared access to USB keys and other arbitrary shared content. Note that IIAB does not support HTTPS "out of the box" since it's intended for use in isolated locations by non-technical users, frequently with no Internet access and no way to validate SSL certs on a regular basis...
USB keys can be inserted and removed at will into the ports of a device (typically a Raspberry Pi) running IIAB. The first key inserted will automatically be mounted in /media/usb0 and a USB0 symlink will automatically be created at /library/www/html/local_content/ (likewise for additional keys). On (typically surprise) removal any USB symlinks will automatically be deleted from that local_content directory.
My intention is/was to use FileBrowser Quantum to include the contents of any inserted USB keys in an index of the local_content directory via - path: /library/www/html/local_content. However not being able to traverse any (ephemeral) USB symlinks in that directory prevents this strategy. So I've also added - path: /media as a source, which does produce a separate index for any and all inserted keys (though there are some display issues with USB keys that are removed and reinserted after starting the filebrowser executable/service). However having a single index (and corresponding shared folder) to search would be the ideal situation for the non-technical user audience of IIAB.
The use case for IIAB makes it unlikely that any default paths or behavior would be modified in ways to circumvent the restrictions against symlink transversal that you've introduced into FileBrowser Quantum. I may reluctantly revert to OG FileBrowser for purposes of my own private instance of IIAB. However I would much rather use FileBrowser Quantum for this purpose, even with the somewhat relaxed security posture of IIAB.
I am in agreement with others here that the lack of symlink traversal in FileBrowser Quantum should be clearly mentioned in the documentation, especially in any text that compares it to OG FileBrowser. I also agree that there should be a specific option to exclude symlinks from display and indexing (and since symlink traversal is excluded as a design feature, you might as well make that option enabled by default).
In any case you've created a beautiful product here. Thanks for listening!
I'll update the docs!