I am running PhpStorm on Linux Mint installed in /opt. PhpStorm is notifying me that there is an update available (8.0.3), but then it tells me it doesn't have write permission to apply the update, and that I should run it as a privileged user to update it.
If I run phpstorm.sh as root/sudo it asks for license info and looks as though it's running the installer rather than the program. PhpStorm is licensed when I run it from the desktop.
So how can I run updates?
I had the same issue and was able to change ownership of the PhpStorm folder to get it to work. Assuming your username is newownername and PhpStorm installation is located in /opt/phpstorm, the command should look like this:
chown -R newownername /opt/phpstorm
Note that you should change username and path to appropriate values.
No need (and not recommended) to change the ownership or the permissions of the opt/phpstorm directory. In fact, the error message returned says exactly what you should do: run it as a privileged user to update it.
After exiting PHPStorm, you can run it as a privileged user using the following instructions
sudo updatedb && sudo locate phpstorm.sh
sudo /path/to/phpstorm.sh
The first instruction updates the locate database and returns the location of the phpstorm executable in your computer.
Use the returned location as the path in the second instruction.
When starting PHPStorm as root, it will start with the default settings. It might even ask you if you want to apply your license... No need to change any of this: the default settings and running PHPStorm in evaluation mode will work just fine. After it starts, check for updates in the menu Help and apply them normally. PHPStorm might restart once again as root. Just close it once more and restart normally. When restarting as your user, you'll be given the ability to select your normal settings (usually stored in your user's directory: the path will be suggested). Accept and continue. PHPStorm will start with all your preferences and settings restored and properly upgraded.
If plugin updates are required, you can update them normally. No need to do it using root.
This solution is recommended by JetBrains. Changing the ownership or the permissions of the opt/phpstorm directory is not recommended and in fact pointed as incorrect by Jet Brains, as you can verify on their answer regarding the process of upgrading a similar product: Fixed: PyCharm automatic update fails on Linux due to permissions.
sudo chown -R $USER:$USER /opt/PhpStorm* , worked for me.
JetBrains are publishing their entire IDE portfolio as snaps, including PHPStorm. Snaps work on all supported versions of Ubuntu, including 14.04 and on Linux Mint 17.x and 18.x.
Some of the advantages of the JetBrains snaps are that they are always up to date, will automatically stay updated and are very easy to install.
To install PHPStorm in Ubuntu or Linux Mint:
sudo apt install snapd
sudo snap install phpstorm --classic
Related
I have an issue with VS Code and WSL remote extension. On my machine, Windows Defender Firewall blocked node. I do not have sufficient rights to unblock it, but admins created excluded folder, where based on what they said "I can copy everything that I will need and it is excluded from Windows Defender Firewall check". So I copied VS Code there but I need to also copy the package with Debian Linux there and link it to the new path.
But I was not able to find where this path to Debian is stored, and how it can be changed. For me, the folder is now in
C:\Users\{username}\AppData\Local\Packages\TheDebianProject.DebianGNULinux_... and need to be moved to C:\ExcludedFolder
Is this possible? Thank you very much for your response.
First up, you might be able to solve your firewall problem a slightly different way. I can't say for certain (and things are always changing), but it's been my experience that Firewall/Defender only detect and block for WSL1 applications. This is at least true for the malware/antivirus detection, but I believe it would extend to the firewall functionality as well. On the other hand, if it doesn't, then moving the instance to a different directory may not help with your issue.
You can double-check the version of your Debian instance using wsl -l -v. If it's version 1, then let's try converting it to 2 (if you have that permission on your system).
The first steps here are going to be the same regardless of whether you just convert the instance or move it:
First, exit your WSL/Debian instance and then issue wsl --shutdown. You can do this from PowerShell, CMD, or the Start Menu; but I'm going to assume for the rest of the instructions that you are in PowerShell.
Run the following in PowerShell:
cd <your exclusion directory>
mkdir wsl\images
cd wsl\images
wsl --export Debian 2021-11-02_Debian_backup.tar
Assuming that your instance is WSL1 and you want to try to convert to WSL2, you at least now have a backup. Run wsl --set-version Debian 2 to convert it to WSL2. Then start it up and see if there are any differences in how node behaves. You can always convert it back with wsl --set-version Debian 1, of course.
If you still need to try moving it:
cd <your exclusion directory>\wsl
mkdir instances\debian_exclude
wsl --import debian_exclude instances\debian_exclude images\2021-11-02_Debian_backup.tar --version 2
wsl -d debian_exclude
Note that you can, of course, call the filenames and directories whatever you want. Also note that you can change the version number when you import it. Select whichever WSL version you need there.
You should now be in a new instance of Debian, but you'll be running as root by default. You need to set the default user of the imported instance by creating /etc/wsl.conf with the following:
[user]
default=<your_wsl_username>
Exit the instance, run another wsl --shutdown, and restart. You should now be running as your normal user. Try node again there to see if new location allows it to be excluded from the firewall rules.
If everything is working as intended, you can wsl --unregister Debian to remove the old instance. Please note that this will remove all files in the instance, so please make sure that your backup and new instance have everything you need first.
Unregistering the old instance should set the new one as your default, but if not, you can use wsl --set-default debian_exclude.
The code inspection is not working properly on my Pop!_OS 21.04 x86_64, so I checked updates and realized that my PyCharm is actually out of date, but to update it I need to run PyCharm as root.
But, when I go to where PyCharm is located and run sudo ./pycharm.sh, It's like it is a fresh install and wants me to login.
I have come across this issue in other apps too, where if I run it as root, it uses a different directory for config etc.
How do I get around this? Thanks in advance.
I started using Linux lite 5.0 on my laptop last month. (I am fairly new to the Linux enviroment, just migrated from Windows 10).
So I installed Visual studio Code using snap and everytime I start it up, it asks to authenticate 'Default Keyring' until next reboot.
Is there anyway I can authorize it so I don't have to authenticate it everytime i reboot my pc?
(p.s the reason i moved from windows to linux is because my pc got hacked some weeks prior, so please consider security a major concern here)
Thanks in advance :)
In GDM+GNOME, when you login, GNOME Keyring is automatically unlocked. However, it doesn't do so in SDDM+KDE. When you start some GNOME or Electron application like VS Code, they ask you to type the login password again.
The solution is to edit /etc/pam.d/sddm and add pam_gnome_keyring.so like this (the second line and last line):
#%PAM-1.0
auth include common-auth
auth optional pam_gnome_keyring.so
account include common-account
password include common-password
session required pam_loginuid.so
session include common-session
session optional pam_gnome_keyring.so auto_start
This is a solution that I found here that should work for you. For me, the lines were already there, but I simply had to remove the - at the beginning of the lines.
EDIT: To edit the file, you'll need root privileges, so I did sudo -e /etc/pam.d/sddm in terminal, edited the lines, hit CTRL+X, and Y to save.
For anyone using VSCode on Windows / WSL - this is the solution https://github.com/MicrosoftDocs/live-share/issues/1782#issuecomment-1053563079
Go to your wsl terminal and install seahorse if you don't have it.
sudo apt-get update && sudo apt-get install seahorse
Run seahorse
seahorse
You should see a popup for GnuPG keys.
Click on the back button, then right-click on default keyring, and click delete.
After entering your keyring password, your default keyring should be gone.
But now vscode asks you to create one every time. To fix this remove gnome-keyring:
sudo apt-get remove gnome-keyring
Credits go to Austin Jerry (upsurge0)
This has nothing to do with visual studio, keyrings is a package in your system used to store your passwords read more about keyrings here
to solve your problem open gnome-shell and search: "seahorse"
open it and you will find all your keyrings setup, the default one is what you want,
select it right-click to edit or delete it if you are not remembering the password
But NOTE before you delete it any configurations with this keyring "default keyring" will be deleted with it too
I was using Chrome OS.
The Linux Terminal (AKA. crostini).
The "keep asking keyring" problem was caused by the keyring directory does not exist. So VS Code cannot save the keyring there.
The solution is simply create the directory.
You may use the following command.
mkdir ~/.local/share/keyrings
I'm using the Atom editor. Yesterday, if I typed:
sudo atom . it opened the current directory as root
sudo atom it opened Atom with whatever I last had open as root
Today if I run either of those commands nothing happens. The editor doesn't open and there are no error messages.
These terminal commands worked yesterday on these exact same files, today they do not.
How can I fix this?
Why is this happening?
If I have not provided enough information it's because I don't know what info one would need to have a fuller explanation of my circumstance. Let me know what I should add I'll happily edit this question to provide it.
Atom : 1.13.0
Electron: 1.3.13
Chrome : 52.0.2743.82
Node : 6.5.0
Ubuntu 14.04 LTS
Elementary OS Freya (64-bit)
After updating Atom text editor it seems I require to run --no-sandbox flag but after a while it becomes boring so I wrote a simple BASH script to be doing this for me:
eval "atom --no-sandbox flag"
just save this in a common directory that you frequently use and type ./atom_text_editor.sh in the terminal to deploy(Depending on the name you choose for your script)
A recommendation, when working on linux avoid using sudo or su instrucctions, they are intended to execute privileged instructions like system configurations. It might be related to permissions, execute ls -al and verify that the owner/group of yor files is root, if not, then check if "others" have read permission, if not, then thats is the problem.
Be aware running atom with sudo is not recommended.
I've had this problem for a few days, I installed atom using snap (on ubuntu 18.04) a few weeks ago, back then it worked perfectly, but the last few days if i ran 'sudo atom' nothing would happen at all, reinstalled it using snap, still didn't work, removed settings, still didn't work.
I ended up installing atom using the apt packagage manager and now it works. I used this guide: https://codeforgeek.com/install-atom-editor-ubuntu-14-04/
Furthermore when running atom with sudo it should be ran with the --no-sandbox flag.
Conclusion: seems to be a problem with atom when installed using snap.
I installed the ubuntu(14.04 VirtualBox) version of megasync along with the nautilus extension. I typed "megasync" in my console, logged into my account, enabled autostart. But upon closing the console megasync just closes and when I restart the OS megasync does not start itself up.
Megasync is included in the startup options with command "megasync".
Note, I just installed Ubuntu and have no previous experience with Linux so this might be just a misunderstanding from my side, but I am helpless right now.
I also had problems with autostart. In my case it was a prolem with permissions (megasync was not marked as executale), but I don't think yours is the same.
You can give it a try: sudo chmod +x /usr/bin/megasync
Or just run a script I've created to run multiple instances.
1) Log out from the session
2) Download and run my script MEGA-Instances and follow the guide.