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.
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)
Figure out why the problem occurred and see if it can be avoided.
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.
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-data group (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 /opt or /var/www in a potentially dangerous manner.
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.
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...
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.
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
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