You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is probably some silly misconfiguration on my part, but I've searched fairly extensively and haven't come up with a solution.
I've been using nvr for years to toggle settings across all instances of nvim.
Suddenly after years of working fine, I've noticed nvr --serverlist returns:
❯ nvr --serverlist
Access denied for nvim (5761)
Also strange enough, /proc/5761/environ is actually owned by 0:0 (root:root) instead of 1000:1000 as I would expect, even though PID 5761 itself is running as UID 1000. Zsh has the regular UID I would expect.
❯ ls -l /proc/5761/environ
-r-------- 1 root root 0 Jul 2 16:53 /proc/5761/environ
❯ ls -l /proc/$$/environ
-r-------- 1 me me 0 Jul 2 16:53 /proc/5407/environ
I'm running on Kubuntu 22.04.2 LTS x86_64.
NeoVim: NVIM v0.9.1
And if I check the permissions on that file, it seems fine:
❯ ll /run/user/1000/nvim.15178.0
srwxrwxr-x 1 me me 0 Jul 2 17:09 /run/user/1000/nvim.15178.0=
I saw an article mentioning cap_ipc_lock could impact permissions in /proc/$PID, but I tried both setting and clearing the ipc_lock capability and I did not notice any change.
This is probably some silly misconfiguration on my part, but I've searched fairly extensively and haven't come up with a solution.
I've been using nvr for years to toggle settings across all instances of nvim.
Suddenly after years of working fine, I've noticed
nvr --serverlist
returns:Also strange enough,
/proc/5761/environ
is actually owned by0:0
(root:root) instead of 1000:1000 as I would expect, even though PID 5761 itself is running as UID 1000. Zsh has the regular UID I would expect.I'm running on Kubuntu 22.04.2 LTS x86_64.
NeoVim: NVIM v0.9.1
When inside of
nvim
I run:I get something like:
/run/user/1000/nvim.15178.0
And if I check the permissions on that file, it seems fine:
I saw an article mentioning
cap_ipc_lock
could impact permissions in /proc/$PID, but I tried both setting and clearing the ipc_lock capability and I did not notice any change.The text was updated successfully, but these errors were encountered: