"Permission denied (os error 13)" by running Function on Docker local-dev

[Pictor13]

Discussed in https://github.com/orgs/supabase/discussions/14996

^{Originally posted by Pictor13 June 13, 2023}
On local-development I seem to have an issue with filesystem permissions, over the deno Docker container.

When trying to access an Edge Function file, Deno fails with error: Permission denied (os error 13).

I docker-exec -it $deno_container bash into docker ps | grep deno and can see that:

• id returns the user deno, having UID & GID equal to 1993
• ls -la /home/deno/functions/my-function/index.ts shows onwer UID and group GID as equal to 1000
  • uid/gid 1000 is usually corresponding to the docker user; when it appears in a container usually is the sign of some volume mount of some sort.

Is this the case?
I saw the /app/Dockerfile simply copies the files, from localhost to the container, but I don't see why they should have this mismatching file permissions.

Can somebody check in their working docker local-dev if the 2 commands above return the same results as me?

At the moment I am unable to test functions locally.
What could be causing the error?
What can I try to restore the correct functionality?
Could this be a bug?

---

More info

I run:

• supabase start
• supabase functions serve my-function --debug

it outputs:

Download https://esm.sh/v125/@supabase/storage-js@2.5.1/dist/module/packages/StorageBucketApi.d.ts
Download https://esm.sh/v125/@supabase/storage-js@2.5.1/dist/module/packages/StorageFileApi.d.ts
Download https://deno.land/std@0.150.0/media_types/mod.ts
Download https://esm.sh/v125/@supabase/realtime-js@2.7.2/deno/dist/module/lib/version.js
Download https://esm.sh/v125/node.ns.d.ts
Download https://deno.land/std@0.150.0/media_types/_util.ts
Download https://deno.land/std@0.150.0/media_types/vendor/mime-db.v1.52.0.ts
2023/06/13 03:17:16 Sent Header: Host [docker]
2023/06/13 03:17:16 Sent Header: User-Agent [Go-http-client/1.1]
2023/06/13 03:17:16 Send Done
2023/06/13 03:17:16 Recv First Byte
Serving supabase/functions/my-function
2023/06/13 03:17:16 Sent Header: Host [docker]
2023/06/13 03:17:16 Sent Header: User-Agent [Go-http-client/1.1]
2023/06/13 03:17:16 Sent Header: Content-Length [805]
2023/06/13 03:17:16 Sent Header: Content-Type [application/json]
2023/06/13 03:17:16 Send Done
2023/06/13 03:17:16 Recv First Byte
Watcher Process started.
Check file:///home/deno/functions/my-function/index.ts
error: Permission denied (os error 13)
Watcher Process finished. Restarting on file change...

Additionally

• I also tried supabase stop and start again to see if it would reset the image & containers, but nothing changed
• I tried to chmod 777 the index.ts file inside the container but user deno has no rights to do so and sudo is not available.

[gregnr]

@Pictor13 thanks for the issue. When you say you are using the deno Docker container, are you referring to this image?

Also are you developing from inside the container, or just using the container to run your edge functions? Might be helpful to know which OS host you are using.

Some more details on how you are developing (vs. the standard flow) and what you are trying to build (code snippets may be useful) would help! cc @supabase/edge-functions

[laktek]

@Pictor13 Edge Functions don't have permissions to access the filesystem. If you want to read a file, I'd suggest uploading it to Supabase Storage and read from there. Check this example on how to read files from Supabase Storage.

[Pictor13]

@gregnr

@Pictor13 thanks for the issue. When you say you are using the deno Docker container, are you referring to this image?

No, I'm not self-hosted, I'm using the one that is pulled and run out-of-the-box by supabase start (automatic dev-environment)

$ docker ps
CONTAINER ID   IMAGE                                             COMMAND                  CREATED          STATUS                 PORTS                                                                                                                                   NAMES
3c1c999a9e1f   public.ecr.aws/supabase/deno-relay:v1.6.0         "/bin/deno run --all…"   21 minutes ago   Up 21 minutes          8081/tcp                                                                                                                                supabase_deno_relay_myproject-be
eddfaf4ee399   public.ecr.aws/supabase/studio:20230512-ad596d8   "docker-entrypoint.s…"   2 hours ago      Up 2 hours (healthy)   0.0.0.0:54323->3000/tcp, :::54323->3000/tcp                                                                                             supabase_studio_myproject-be
...continues

hence I suppose public.ecr.aws/supabase/deno-relay:v1.6.0.

Also are you developing from inside the container, or just using the container to run your edge functions? Might be helpful to know which OS host you are using.

Some more details on how you are developing (vs. the standard flow) and what you are trying to build (code snippets may be useful) would help! cc @supabase/edge-functions

I'm Ubuntu 20.04, running Docker containers natively.
I'm developing according to supabase.com guides & documentation:
from outside the container, and then using functions serve --debug to test Edge Functions (before doing functions deploy to Supabase hosting).

Also note that I've run functions before on the same setup; it seem to me something related to the code under supabase/functions.
Most probably related to import statements. I frequently hit in problems when trying to import .js files from relative paths.
The function broke once I started to move around things (try to fix a mismatching between the detected imports from Deno and those detected by VSCode).

But the error is pretty generic and I get no clue of what I am doing wrong and, most importantly, what's the line number triggering the error.

[Pictor13]

@Pictor13 Edge Functions don't have permissions to access the filesystem. If you want to read a file, I'd suggest uploading it to Supabase Storage and read from there. Check this example on how to read files from Supabase Storage.

Thank you @laktek.
Although wouldn't that make the whole DX workflow an hassle? Having to upload my local dependencies to storage, just to be able to test my edge functions via function serve..

Also, shelling into the deno-relay container, where the functions are persisted, I can actually see that Deno is run with --allow-all & --allow-read flags.
See below:

deno@deno-relay:/app$ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
deno           1  0.3  0.1 6172604 45312 ?       Ssl  01:49   0:00 /bin/deno run --allow-read --allow-net --allow-env src/index.ts
deno          29  4.0  0.3 5481428 103032 ?      Ssl  01:49   0:02 deno run --no-check=remote --allow-all --watch --no-clear-screen --no-npm /home/deno/functions/hello-world/index.
deno          51  0.1  0.0   4116  3496 pts/0    Ss   01:50   0:00 bash

hence I should have access to the filesystem.
And indeed I did have; as I mentioned in the answer to @gregnr

[laktek]

@Pictor13 Sorry I misunderstood the issue, thought you are referring to reading local files in your function code which isn't supported. Importing local dependencies should work though. Are you on the latest version of CLI? After upgrading the CLI, if you do supabase function serve it should work.

[Pictor13]

@laktek aah yes, no problem, I misunderstand stuff all the time :)

However....I figured out a solution: ensure to not make a single mistake during imports 😓

Once fixed, ensuring that every single import using relative paths is correct, everything started to work again!

---

Pretty often, using wrong local URIs for import-from (e.g. relative paths like ../../bla/bla.js or absolute paths like /bla/bla.js <---from linux-root-dir) can lead outside of the /home/deno/functions scope and cause different errors, depending on the filesystem permissions.

Most of the time is Module not found, but in some situation it probably crashes early on and we get an OS error instead of an handled error, leaving the Dev with no info on what to fix.
What's worse is that the log at the previous line made me thing that the edge-function file itself was the problem (wrong permissions?), rather than an import somewhere (and might be in a nested import...).

I've made a list of different errors I've met by messing out with imports are:

• Module not found when simply the direct relative filesystem path is wrong (aka File not found)
• error: Blocked by null entry for ""environment"" when trying to import by name an item defined in import_map.json but that has a wrong/broken value/path.
• Relative import path "foobar not prefixed with / or ./ or ../ and not in import map from "file:///home/deno/functions/app/index.js" when using an unqualified identifier (anything that is not defined inside import_map.json) — import foobar from "foobar"

Still I'm not sure what triggered my initial error. I get rid of it by fixing 2 different problems from the list above.
So:

• Permission denied (os error 13) happens PROBABLY when there is a combination of the previous errors.

Supabase team (@supabase-automated-user ?) could you confirm my last hypothesis?
And would it be possible to provide more helpful error messages?
Or is that purely depending on Deno?

[Pictor13]

I incurred again the terrible "Permission denied (os error 13)" error.

My edge-function stopped being served correctly once I added a deno.jsonc (or deno.json) in the same folder as the import_map.json (that lies in supabase/functions/ folder).

Deleting it, the serve works correctly.
Adding it, the serve will fail with the absolutely cryptic message "os error 13".

This happens regardless the content of the Deno config file (I tried with {"importMap": "./import_map.jsonc"} and with {}; same broken behaviour).

Hopefully reporting it here might save some lives & headaches to somebody.... 🙄

[laktek]

@Pictor13 Have you upgraded the CLI? Check if you are running a version above 1.68.0+.

In the newer versions of the CLI, serve command should be using Edge Runtime instead of deno run and it should ignore deno.json.

[sweatybridge]

Closing as no longer relevant. Feel free to reopen if there's any issue related to edge runtime.