firebase-tools: Could not read source directory. Remove links and shortcuts and try again.

Version info

firebase-tools: 3.17.4

Platform Information

OS X

Steps to reproduce

Deploy a firebase function as normal firebase deploy --only functions:myFunction

Expected behavior

Function is deployed or a descriptive error is displayed

Actual behavior

I received:

✔  functions: Finished running predeploy script.
i  functions: ensuring necessary APIs are enabled...

Error: Server Error. getaddrinfo ENOTFOUND servicemanagement.googleapis.com servicemanagement.googleapis.com:443

However, I kept re-attempting a few times without making changes and also received the following about ~5 times:

Error: Could not read source directory. Remove links and shortcuts and try again.

The “Could not read source directory” error also sometimes took up to 2 minutes to appear after executing the command, which leads me to believe its network related and nothing to do with my local setup, especially as the function eventually deployed after a few re-attempts.

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 25 (5 by maintainers)

Most upvoted comments

In case anyone else runs into this, I had a temporary Emacs file in the functions directory that was causing this error. The --debug flag helped me find it. 😃

ajpocus on May 8, 2019

For any future weary Google searchers, I get this issue when connected to my VPN (TunnelBear). If I turn the VPN off, the deploy works just fine.

imjared on Jan 18, 2019

I m getting the same issue , the debug keeps same error either while preparing functions folder to deploy or while deploy the only function I m trying to deploy . The debug log is not even telling me the file in which it is getting the mentioned error. Tried everything. Please help me resolve this issue , it is blocking my release for 2 days.

I found the problem (a temp emacs file, which is a dead symlink) using --debug after finding this issue. It would be really helpful to just print the name of the offending file in the error message!

garyo on Aug 21, 2020

I had the same issue, so I re-ran my deploy with --debug and discovered that my deploy user was getting a 403 on the GET https://runtimeconfig.googleapis.com/v1beta1/projects/myproject/configs call.

I added the Cloud RuntimeConfig Admin role, and a handful of permissions including these, and that resolved it:

iam.serviceAccounts.actAs
iam.serviceAccounts.get
iam.serviceAccounts.list

(I’m not sure which of these are necessary but it might provide someone in the future some pointers!)

alexlouden on Sep 18, 2019

@divyesm please open a new issue with the appropriate information and we can try to help debug it. Include as much of the --debug output or firebase-debug.log file as possible. Thanks.

bkendall on Jul 1, 2019

I think it might be the tsc watch that’s interferring with deployment, since it scans all the files. I would stop tsc watch while you are deploying

laurenzlong on Aug 21, 2018

Deleting node_modules and package-lock.json and rerunning npm install fixed the problem for me.

Blackbaud-SteveBrush on Dec 11, 2020

I was able to use this thread to solve my issues with Cloud Build when deploying, if anyone is looking for this later.

The Cloud Build Service Account was the account I added permissions to, which altogether included these to end up with a successful build and deploy:

Cloud Build Service Account
Cloud Functions Admin
Service Account User
Cloud RuntimeConfig Admin (pre-release state)
Storage Admin

dylangolow on May 11, 2020

This error message is almost definitely a red herring - I get it intermittently whenever there are network issues talking to the firebase servers (which seems to be ALL THE TIME recently).

kiril on Oct 4, 2018

Thanks for clarifying. I think that error message is unrelated to the network issues, since it comes from this line: https://github.com/firebase/firebase-tools/blob/master/lib/prepareFunctionsUpload.js#L64. So it happens when the zipping process encounters an issue. Can you run the deploy command again with the --debug flag? That’ll give us more info, and tell us if the error message is wrong.

laurenzlong on Mar 7, 2018