Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to access Documents/Downloads/Desktop folders on MacOS when running brew services start code-server #2794

Closed
uajqq opened this issue Feb 28, 2021 · 12 comments
Milestone

Comments

@uajqq
Copy link

uajqq commented Feb 28, 2021

  • Web Browser: Safari
  • Local OS: iPadOS/MacOS/iOS
  • Remote OS: MacOS 11 Big Sur
  • Remote Architecture: intel
  • code-server --version: 3.9.2

code-server cannot view or edit any files in the Desktop, Documents, or Downloads folders, even after granting Terminal full disk privileges. There's no error, the folders just appear as empty. I can create files/folders through code-server in those locations, but any new file created there instantly disappears from code-server, while still being visible in Finder.

@bpmct
Copy link
Member

bpmct commented Feb 28, 2021

even after granting Terminal full disk privileges

For debugging purposes, what happens when you run code-server as root/sudo?

@uajqq

This comment has been minimized.

@uajqq
Copy link
Author

uajqq commented Feb 28, 2021

Okay, so doing more experimentation:

Running code-server as root resolves the issue
Running code-server as myself also resolves the issue

Looks like this only happens when running code-server using brew services start code-server. I checked with brew services list and code-server is running with myself as the user.

@jsjoeio jsjoeio added the needs-investigation This issue needs to be further investigated label Mar 1, 2021
@jsjoeio
Copy link
Contributor

jsjoeio commented Mar 1, 2021

Glad to hear @bpmct's suggestion resolved the issue! Thanks for the extra info. We'll investigate further.

@jsjoeio
Copy link
Contributor

jsjoeio commented Mar 1, 2021

Wait, the issue is not resolved

Sorry for the confusion on my part! You said Running code-server as root resolves the issue and Running code-server as myself also resolves the issue. When I say "resolved", I really meant it sounds like you're unblocked using these workarounds.

We'll definitely look more into this when we have time!

@jsjoeio jsjoeio changed the title Unable to access Documents/Downloads/Desktop folders on MacOS Unable to access Documents/Downloads/Desktop folders on MacOS when running brew services start code-server Mar 1, 2021
@noahsbwilliams
Copy link

Newer versions of macOS require permission through a non-UNIX mechanism for access to the Desktop, Documents, Pictures, Downloads, and other folders.

You may have to give Node "full disk access" since it doesn't implement any of the macOS permission request stuff natively.

  1. Find where Node is installed on your machine
~ which node
/usr/local/bin/node
  1. Grant Node Full Disk Access

Open System Preferences > Security & Privacy > Privacy (horizontal) tab > Full Disk Access (vertical) tab > Click the 🔒 to unlock > Click + and select the Node binary you located.

@bpmct
Copy link
Member

bpmct commented Apr 28, 2021

I created a PR that documents this in our FAQ. Should we leave this issue open or is this something beyond code-server's control that should be closed?

@wakewon
Copy link

wakewon commented Apr 28, 2021

Newer versions of macOS require permission through a non-UNIX mechanism for access to the Desktop, Documents, Pictures, Downloads, and other folders.

You may have to give Node "full disk access" since it doesn't implement any of the macOS permission request stuff natively.

  1. Find where Node is installed on your machine
~ which node
/usr/local/bin/node
  1. Grant Node Full Disk Access

Open System Preferences > Security & Privacy > Privacy (horizontal) tab > Full Disk Access (vertical) tab > Click the 🔒 to unlock > Click + and select the Node binary you located.

Well, it seems doesn't work for me...
After grant Full Disk Access permission for node binary, and restarted vs-code, the folders mentioned in this issue still cannot be accessed. Maybe some other binary file are also required to be granted Full Disk Access permision?

Another thing is that while executing which node in system terminal, it will echo node not found. But terminal in code-server can echo the correct path /usr/local/opt/node@14/bin/node (this path is not included in system's environment variable). Is it possible to make code-server share the same environment variable with system terminal (zsh)? The default $PATH value in code server doesn't consist MacTex's path /Library/TeX/texbin, which caused an error while building tex file.

To solve the permission issue, I edited the code-server's plist file created by brew services manually:

  <key>ProgramArguments</key>
  <array>
      <string>/usr/local/bin/fdautil</string>
      <string>exec</string>
      <string>/bin/zsh</string>
      <string>-c</string>
      <string>code-server</string>
  </array>
  <key>EnvironmentVariables</key>
  <dict>
      <key>PATH</key>
      <string>/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/TeX/texbin</string>
  </dict>

the 'fdautil' file is provided by an app called 'LaunchControl', which is also needed to granted with Full Disk Access permission previosly. I've also added the path for Tex in this plist file, and launch code-server by zsh. This one does work but not elegant at all, hopefully there could be a solution for original service management by homebrew.

@noahsbwilliams
Copy link

There is - hurrah!! The file you'd want to change is located here. I'm running short on time at the moment or I'd submit a PR myself.

@wakewon
Copy link

wakewon commented Apr 29, 2021

There is - hurrah!! The file you'd want to change is located here. I'm running short on time at the moment or I'd submit a PR myself.

Aha! It looks exactly the config file to generate plist file which should be edited (although I have no idea how to edit it permanently).

In my previous trying, I duplicated the plist file made by homebrew (then stop using homebrew to manage this service) and edit it directly with the content above.

Well, I still have some trouble dealing with the environment varible. To solve the absence of path to TeX directory, I added the EnvironmentVariables part in plist file. But the $PATH value set in plist file seems have no effect if running code-server by launchctl directly (the way which homebrew's original plist used), but launching code-server by zsh or bash will be fine. I have no idea how to add an environment variable which would work when starting code-server by launchctl directly. (Without extra operation, the path is already avaliable in zsh and VScode, but not in code-server.) Maybe another issue should be open...

And ... sadly grant Full Disk Access permission for Node can't solve the problem accessing Document folder. I don't know if this is my own problem or some other files should alse be granted permission?

@wakewon
Copy link

wakewon commented Apr 29, 2021

Newer versions of macOS require permission through a non-UNIX mechanism for access to the Desktop, Documents, Pictures, Downloads, and other folders.

You may have to give Node "full disk access" since it doesn't implement any of the macOS permission request stuff natively.

  1. Find where Node is installed on your machine
~ which node
/usr/local/bin/node
  1. Grant Node Full Disk Access

Open System Preferences > Security & Privacy > Privacy (horizontal) tab > Full Disk Access (vertical) tab > Click the 🔒 to unlock > Click + and select the Node binary you located.

I found an answer said:

If you specifically need to access it in your Node application, you will need to enable full disk access for the application you're using to run this script (e.g, Terminal.app, iTerm, or an IDE) in System Preferences.

It seems that the application itself (code-server) but not node should be granted access to full disk. If code-server is launched in Terminal, the folder access permission is fine since most people have already granted terminal's access to Document/Desktop etc. But brew services use launchctl to start /usr/local/bin/code-server directly, but code-server has not been granted permission.

I took a look to the binary file /usr/local/Cellar/code-server/3.9.3/bin/code-server, then found that it launch entry.js by /bin/bash. After granted Full Disk Access for /bin/bash and restarted code-server, the folder access issue is solved. I think this is also the reason why some environment variables are different in code-server. The default shell is zsh now in macOS and most user defiened environment variables are set in ~/.zshrc, which cannot be used in bash. Maybe there could be a better code-server launcher for macOS.

Conclution:

  1. For macOS user: Grant /bin/bash Full Disk Access permission.

(1) System Preferences -> Security & Privacy -> Privacy -> Full Disk Access
(2) Click the lock in the lower left corner to allow changes
(3) Separately, Open a finder window
(4) Select Go -> Go to Folder... from the menu bar
(5) Type /bin and click Go.
(6) Drag /bin/bash to the Full Disk Access (right hand side)

  1. For MacTeX user: Edit /usr/local/bin/code-server and add the path /Library/TeX/texbin to line 2:
#!/bin/bash
PATH="/Library/TeX/texbin:/usr/local/opt/node@14/bin:$PATH" exec "/usr/local/Cellar/code-server/3.9.3/libexec/out/node/entry.js"  "$@"

(I tried to add PATH="/Library/TeX/texbin:$PATH" in ~/.bash_profile, but not work. I have no idea why it doesn't work)

  1. Restart code-server: Open the Terminal app and run the following command:
brew services restart code-server

@jsjoeio jsjoeio added this to the On Deck milestone Apr 29, 2021
@stale
Copy link

stale bot commented Oct 27, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days.

@stale stale bot added the stale label Oct 27, 2021
@stale stale bot closed this as completed Nov 2, 2021
@code-asher code-asher removed the needs-investigation This issue needs to be further investigated label Jul 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants