Folder upload fails with 500 error on filebrowser container

[Osvaldo-Net]

I’m facing an issue that I haven’t been able to identify. Currently, I have Filebrowser running without root privileges, using user and group 1000:1000.

When I create folders or upload individual files, the process completes successfully; however, when I try to upload a folder that contains multiple files or subfolders, I get a 500 error.

I’ve checked the container logs but couldn’t find a clear reason for the failure. I suspect it might be related to permissions or perhaps some server configuration I’m overlooking, but I haven’t yet been able to determine the exact cause.

I’m attaching the logs in case you could help me identify what I might be missing.

Nginx

[bionickatana]

I also am having this issue. At first I thought that it was because I was running an old version (0.8.1) However when I pulled the newest version from docker and used that container I saw the same behavior. I am also running a rootless Docker setup, however I do not believe that I have changed the user and group to 1000:1000. Here is the compose file I am using:

services:
  filebrowser:
    environment:
      FILEBROWSER_CONFIG: "data/config.yaml"
      FILEBROWSER_ADMIN_PASSWORD: {REDACTED}
      #TZ: "America/Denver" # optionally set your local timezone https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
    volumes:
      - '/storage/data/fileshare_q:/folder' # Never mount root "/" directory to docker, always choose a sub-folder with your data.
      - './data:/home/filebrowser/data' # mount the data folder you created with the config file.
      # (and if unraid) If you plan to run with a different user besides root or filebrowser, you will need to mount a tmp directory.
      #- './tmp/:/home/filebrowser/tmp/'
    ports:
      - '8082:80' # the left 8082 is the port **you will use** to access. The right 80 is the container port that **must match the config.yaml**
    image: gtstef/filebrowser
    # Optionally run as non-root filebrowser user
    #user: filebrowser
    restart: unless-stopped

My instance is behind an openbsd relayd proxy instead of nginx so I am not sure what configuration you would like to see however I have never had issues uploading anything before now so I do not think that is the issue.

[gtsteffaniak]

This is a common issue that I mention on the getting started about the cacheDir

There's two options:

1. you can use the filebrowser user which is 1000:1000 by uncommenting user: filebrowser above to use the built in user, the cacheDir works just fine with that user.
2. If you use another user like whats common with unraid, you'll need to mount a temp directory

BTW its all explained in the comments you posted:

# (and if unraid) If you plan to run with a different user besides root or filebrowser, you will need to mount a tmp directory.
#- './tmp/:/home/filebrowser/tmp/'

[Osvaldo-Net]

God! Without a doubt, thank you so much for your help. I solved it by adding the following line inside my server block:

server: cacheDir: /home/filebrowser/tmp

Thanks again for your support!

[gtsteffaniak]

I'm adding a documentation label, because I still think this could be mentioned more clearly on the docs. It's still a common problem, I think I haven't pointed it out in the docs well.

Which guide did you follow when setting up? The docker getting started?

[iamdangry]

Just jumping in here to add a +1 to experiencing this issue. I have setup a cachedir as per docs (tested running rootless and as root) and it worked fine for one folder upload but subsequent folder uploads fail. Obviously creating the folder manually and uploading files (not folders) into here, works, but any folder upload fails.

HTTP 500 <folder name> is not a folder

Refreshing the UI, the folder has uploaded/created as an empty file of the same name.

[gtsteffaniak]

Thanks for the additional info, that doesn't sound like a cache issue -- will check

[Kurami32]

I think that #1497 is related too? For me this two issues are very similar (if not the same).

[gtsteffaniak]

I believe this is solved in v1.1.1 beta, can anyone confirm?

[FabLabRacing]

I was having the same issue on 1.0.1-stable What I found was:

Fresh system, /opt/filebrowser/ is empty Try to upload a folder → fails Manually create a folder in FBQ GUI → now folder uploads work After that, you can even delete the GUI-created folder and uploads still work until you nuke everything and start over:

The first time, with a completely empty root, the folder upload path seems to fail to create intermediate directories, or handle the leading / / URL-encoded path properly.

Once any directory exists, some internal state/logic takes a different path and everything works as expected.

[gtsteffaniak]

Thanks for that info let me try to test this myself and see if I can fix it so it works fresh too

[xMarkos]

I am having this issue on 1.0.3-stable.

I would like to add my observation:

1) Instead of a folder, an empty file is created If we upload test/file1, instead of moving directory test, first a file test is created, and then file file1 is attempted to move. That fails for obvious reasons (directory test is expected, but file test is present).

2) I am convinced this has worked for me before I know for sure that this has worked for me before on versions <=1.0.0.

I have, however, made 1 change to my directory structure:

Previous setup: Cache dir and data dir was on the same partition.

New setup: Cache dir and data dir are mounted from different disks.

As moving files between filesystems is significantly more effort than within a filesystem (e.g. mv command internally copies, and hardlinks can't be used for copies), I suspect this might be the culprit.

Additional info:

• I am running filebrowser as a process directly without docker (= the issue is not docker related or related to docker volume mounts).
• I am running it as root (= there is no possibility of permission errors).

I will try to do some testing with cache and data on the same filesystem to disprive my theory when I get some free time.

[xMarkos]

Okay, the theory with the mount points is incorrect and has no impact at all.

My new observation is that if we are uploading a directory to a directory that is empty, it creates a file instead of the target directoy. If there is anything at all in the directory (be it an empty file of a different name), then it creates the target directory correctly.

[Kurami32]

@xMarkos I think that what you are describing is fixed in beta but it wasn't patched to stable. (#1571)

[alexander-denev]

Guys, just see the Developer tools network requests! On there I immediately saw the problem in the Frontend calling the API. When uploading a folder, instead of the first request being a POST request for creating /somefolder/, it is '/somefolder'. This should be easy peasy to fix. Just add the leading slash ❤️

[alexander-denev]

I am extremely tired but I talked some nonsense to the AI Agent and I believe he added the missing slash. #1696 Feel free to correct me if I'm wrong. Good night 🌙