This is one of the common problems you may face if you are using Visual Studio Code in Linux and that is, VS Code asking about the root permission every time for saving a file.
What is the Problem?
Yesterday I was working on one of my web projects and the problem was, whenever I tried to save my file I was getting an Insufficient permissions error.
Honestly, this is not an error, it's just VS Code needs sudo privilege to save the file and you can easily give it by clicking on the Retry as Sudo... button. But, here is a catch, it's not going to ask about the sudo privileges for the first or one time, every time when you have to save the file, it will ask the sudo password. And believe me, it's frustrating as hell especially, if you are working on some kind of web project where you have to save the file frequently in order to track your changes or if you habituated in saving the file after the few lines of typing.
Solutions :
After spending a few hours and doing a couple of Google search, I have found some solutions which I am going to discuss. If you Google this topic, you will find the same solutions as well but, I would not recommend every solution which you find in the first place and you have to know why it's not.
Solution 1 :
Running VS Code with the root privileges ( not recommended )
sudo code --user-data-dir="~/.vscode-root"
If you run this command from the terminal, then it will forcefully start the VS Code with the root privileges, but running a user-level application, with root privileges is potentially dangerous because if some vulnerability found in VS Code, that might affect your system. VS Code also warns you about this.
And even more dangerous thing is, the user gets the full ability to modify any system file from VS Code without verifying the root password and if the user doesn't know what he/she is actually doing, then there is a high chance that they might bring some serious problem, even they can break the system.
Solution 2 :
Using the chmod -R 777 command ( It depends )
sudo chmod -R 777 your_project_directory_location
Example
sudo chmod -R 777 /var/opt/MY_PROJECT
If you use this command, then not only you, other users on the machine ( If you have more than one user account ) also able to see, modify your project. Because the chmod 777 command gives full control over the file/directory to everyone. So, only use this command if you want to share your project with others. Otherwise, it makes no sense to give full control of your personal project to everyone.
Solution 3 :
Using chown command ( Recommended)
cd location
sudo chown your_username your_project_directory
Example
let's say I have a directory called project1 in my /var/opt location and my user name is mir
cd /var/opt
sudo chown mir project1
However, if you already created some file before applying chown, don't forget to change their permission also
sudo chown your_username your_project_directory/your_file_name
Example
sudo chown mir project1/file1.txt
It's recommended because it neither creates any security issue nor gives unnecessary access to your projects to the others. It solves your problem by keeping your's project up to you. Because using the chown command you have limited the full access of your project directory within your user account.
And for this reason, this is the best solution so far
Thanks for reading & I would like to know what's your opinion on this...
Top comments (16)
I would argue your projects should never be outside of your user directory if you're actively developing them. What might I ask is the scenario in which this is actually necessary? Maybe I've just never run into it.
Yes, most of the time your project directory should be located inside the user directory. That's normal. In that case, you are not going to face any kind of sudo or permission related problem but sometimes you have to deal with those directories which do not come under the user's ownership. As an example, if you do some kind of PHP project in Linux then you have to access the htdocs folder which is located in /opt/lampp/ , and this location directly not comes under any user's ownership. In this situation, if you open any file/directory which is located inside htdocs, from the VS Code then, you will get exactly the same problem that I am talking about in this article.
And people had already faced this problem way before than me. See this Stackoverflow discussion thread
stackoverflow.com/questions/510042...
Hey Mir,
Just a quick clarification that Apache technically allows you to serve files from any directory so you do not need to always use
/opt/lampp/.The key you are looking for in the site configuration file is
DocumentRoot "/path/", after which the system administrator can enable that site with Apache.This has been answered on StackOverflow and here's Apache docs.
Thank You
I see. Well in that case I think that the problem that you and the questioner on SO have is that you're trying to fight the way the system works a bit. Directories outside of your home have permissions set the way they are for a reason.
I probably don't have to explain it to you, but for others who find this: there are potential security issues with, for example, giving some directory or file full user/group/other permissions (777) because that could grant far more access to a service than it might need (and if there's the potential for executing malicious code, it might be able to do serious damage). If you're running or developing some service, you might want to isolate the sort of damage it might do by creating a new user just for that service, and the directory with all of its files will be owned by that user.
In fact, the answer I like best on that post is this one: stackoverflow.com/a/61939446/876844. In that answer, the solution is simply to add your own user to a group which already has access to the directory. So, if the directory in question had read/write access for the
www-datagroup (common for most web services), just add your user to that group, log out/log in, and work as usual.In the past I've used a few other alternatives, including using a symbolic link in the outside directory which pointed to the project directory in my home dir, or a slightly more complicated setup where I used git on both sides. In the latter case, I would develop on a local directory, test things as needed, and then commit. When I had something that I felt could go out to the privileged directory, I would switch to a user that had write access there and do a git pull.
I'm not saying either solution is perfect (and maybe other users have better suggestions), but neither of these involve messing with the permissions in a directory like
/optor/var/wwwin a potentially dangerous manner.Edit: formatting, spelling.
Well, this is also a helpful explanation indeed. Thank you
Your problem here is a lack of a CI/CD pipeline.
You should be editing these files somewhere locally, not directly on the server you're using. When on local you can setup your environment within your userspace, then commit and have your pipeline make the changes.
I can see how this might not be easy first time around, but I would stress that its an important thing to learn.
If you must edit a single file, and you're on linux. Why not just
sudo nano file.ext? Generally won't be spending a lot of time in config files, so you don't need a full code editor.I know I can do it locally, This article is not about whether I can do it locally or on a server. This article more about how you can tackle this problem for a specific text/code editor. And, here in our case which is VS Code editor. (As I mentioned in the article's title)
There's two ways to solve a problem:
In this case, the problem can be easily avoided and usually is as when you're on a server you're also likely ssh-ed into it and off chance you're using vscode-ssh you'll likely know how to sudo vscode.
I don't care what the original topic was, this got brought up (by you) and I shared my thoughts on it.
TBH I didn't read the post nor the comment section but if VS (or another IDE) asks you for permission is because you're doing something bad.
Moreover on dev time you should use 755 for directories and 644 for files and being your user the owner of the files so you have the same recommended config you can find on the server.
You saved my life :-D Thanks
Whenever I face this issuse I solve it by running this command: sudo chown $USER:$SUSER .
Yep! that's also works
I suggest utilizing additional user permissions to prevent altering the original permissions.
On Linux:
setfacl -m u:<user>:rw /path/to/fileI don't like any of those options. I'm dealing with system files so I can't really
chownorchmodthank you, its work for me.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.