Fly.io backend does not see /uploads

My backend uses multer to save to some files from the frontend on a local disk directory and then uploads them to S3. After that, it removes all the images from the directory.

This works in development, but when I deploy to fly.io, it doesn’t work. The obvious logging error is

Error: ENOENT: no such file or directory, open ‘uploads/birthCert1’

After reading for some time, I believe the solution is fly.io`` volumes. This is what I believe to be because it is persistent storage attached to a machine (basically a disk).

Since there is a one-to-one relationship between machines and volumes, the following is displayed:

Error: machine MACHINE_ID [app] can’t update the attached volume VOLUME_A with name VOLUME_A by VOLUME_B

Thing is, I deleted VOLUME_B and it shows that it is deleted.

When I write the following in my fly.toml:

[[mounts]]
  source = "VOLUME_FOR_MACHINE_1"
  destination = "/uploads"
[[mounts]]
  source = "VOLUME_FOR_MACHINE_2"
  destination = "/uploads"

the following is displayed on the deploy logs in fly.io:

Error: machine MACHINE_ID_1 [app] can’t update the attached volume VOLUME_FOR_MACHINE_1 with name VOLUME_FOR_MACHINE_2 by VOLUME_THAT_I_DELETED

I mean all I want is that there is a directory on both machines called `/uploads` that my node server can easily read and write to.

Hi… Volumes are one-to-one with Machines but the [[mounts]] stanzas are not. The above configuration is actually trying to assign two volumes to each Machine.

Assuming that you have just a single process group (most people do only have one), what you would want would be the single:

[[mounts]]
  source = "data"  # does *not* name an individual volume.
  destination = "/app/uploads"  # adjust to match app's cwd.

The cwd (current working directory) is usually the same as the final WORKDIR in your Dockerfile, but sometimes people have more complicated setups.

Alternatively, you can check multer’s docs to see whether there’s a way to explicitly set the destination directory. If so, I’d recommend specifying that as an absolute path (i.e., one that begins with /), to avoid having to guess about where it really is, whether it has the right filesystem permissions, etc.

flyctl can be super-stubborn about volumes, and the messages around them aren’t always easy to interpret. There were a lot of redactions, so I won’t try to guess in detail what happened with this one. Generally speaking, flyctl can’t remove an existing volume from a Machine, nor can a single Machine have multiple. If you see more of these errors while fixing things, I would destroy all existing Machines and redeploy. It’s non-intuitive, but Machines are considered (mostly) disposable on the Fly.io platform.

(Also, just to reiterate, volume names are not unique identifiers. Instead, each name marks a class of volumes. It’s the IDs, the vol_4qo50011abcd9876 strings, that specify unique ones.)

Hope this helps!

1 Like

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.