curl: (23) Failed writing received data to disk/application

[Zeioth]

Got this error running the plugin leetcode.nvim on android (termux). It happen here. It seems to actually be a plenary, or a curl error.

It says: "curl: (23) Failed writing received data to disk/application"

Error executing luv callback:
local/share/nvim/lazy/plenary.nvim/lua/plenary/curl.lua:274: post https://leetcode.com/graphql - curl error exit_code=23 stderr={ "curl: (23) Failed writing received data to disk/application" }

stack traceback:
[C]: in function 'error'
local/share/nvim/lazy/plenary.nvim/lua/plenary/curl.lua:274: in function '_user_on_exit'
local/share/nvim/lazy/plenary.nvim/lua/plenary/job.lua:240: in function '_shutdown'                                                                                      
.../.local/share/nvim/lazy/plenary.nvim/lua/plenary/job.lua:47: in function <.../.local/share/nvim/lazy/plenary.nvim/lua/plenary/job.lua:38>

[ac-z]

I've got a similar issue running lazy.nvim on Termux.

Error executing luv callback:
....local/share/nvim/lazy/plenary.nvim/lua/plenary/curl.lua:274: get https://github.com/Exafunction/codeium/releases/download/language-server-v1.2.90/la
nguage_server_linux_arm.gz - curl error exit_code=23 stderr={ "curl: (23) Failed writing received data to disk/application" }
stack traceback:
        [C]: in function 'error'
        ....local/share/nvim/lazy/plenary.nvim/lua/plenary/curl.lua:274: in function '_user_on_exit'
        .../.local/share/nvim/lazy/plenary.nvim/lua/plenary/job.lua:240: in function '_shutdown'
        .../.local/share/nvim/lazy/plenary.nvim/lua/plenary/job.lua:47: in function <.../.local/share/nvim/lazy/plenary.nvim/lua/plenary/job.lua:38>
        [C]: in function 'nvim_exec2'
        vim/_editor.lua:341: in function 'cmd'
        ...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:481: in function <...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:480>
        [C]: in function 'xpcall'
        .../.local/share/nvim/lazy/lazy.nvim/lua/lazy/core/util.lua:113: in function 'try'
        ...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:480: in function 'source'
        ...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:439: in function 'source_runtime'
        ...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:407: in function 'packadd'
        ...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:131: in function 'startup'
        .../home/.local/share/nvim/lazy/lazy.nvim/lua/lazy/init.lua:110: in function 'setup'
        /data/data/com.termux/files/home/.config/nvim/init.lua:16: in main chunk

My guess is that it's trying to write to somewhere that isn't accessible in Termux.

Termux doesn't have permission to access Android's /tmp/ directory, so that could be it. This is dealt with in Termux packages by using $PREFIX/tmp/ instead.

[ac-z]

@Zeioth I'm pretty sure I just fixed this on my install by setting $XDG_RUNTIME_DIR to "$PREFIX/tmp/" before running neovim. A quick grep revealed that plenary checks if $XDG_RUNTIME_DIR exists, only defaulting to /tmp/ if it doesn't.

[fcancelinha]

The fix proposed by @amb3r-dev worked in my case, this error is affecting some neovim plugins.

[tanc]

Thanks @amb3r-dev this also worked for me! I was having an issue installing a neovim plugin too. In my case XDG_RUNTIME_DIR was set to /run/user/1000/ but that directory didn't exist. I created it and set the ownership to my user and all is well.

[rosshadden]

Just in case people see this, see that there are workarounds and :+1: emojis floating around, I want to say that I think this should be worked around / fixed in this project rather than in user-land.

On my computers, it seems like the /run/user/<uid> directory doesn't exist until you log in to a graphical session as that user. Which means if you turn on a computer and ssh to it through another, neovim repeatedly has the above error. The workarounds work of course, but I don't think a random neovim plugin should prevent neovim from being used over ssh or mandate its own workaround.

I don't mean this to be hostile by any means, and I'm sorry if it sounds obvious to other people more knowledgeable than I was/am about this! I just ran into this today and want to make sure it's not overlooked because we have found some ways to get passed the error.

[gabeklavans]

I'm actually getting this error over at https://github.com/luckasRanarison/nvim-devdocs/issues/78 and it doesn't seem to have anything to do with the -D output fixes mentioned in this thread. The -D output seems to be writing just fine to my default XDG_RUNTIME_DIR, which is /run/user/1000/ and exists and is writeable for my user already. Changing my XDG_RUNTIME_DIR results in the -D output getting written to the new dir, also seemingly successfully, but I still get the error 23 when trying to run any commands in nvim-devdocs that invoke plenary.curl's get. It's specifically with the urls "https://devdocs.io/docs.json" and its current redirect "https://devdocs.io/assets/docs-a3fb1903db449c5e84dea94359b6be804abd505005baeccb160ed01af2a75a55.json", if I use a test url such as "https://postman-echo.com/get", then the download succeeds without error.

[ac-z]

It's specifically with the urls "https://devdocs.io/docs.json" and its current redirect "https://devdocs.io/assets/docs-a3fb1903db449c5e84dea94359b6be804abd505005baeccb160ed01af2a75a55.json", if I use a test url such as "https://postman-echo.com/get", then the download succeeds without error.

Try opening those URLs in browser. The URLs that are failing only show "forbidden", while the postman-echo link shows valid json. Is it possible that your error is being caused by curl receiving code 403 (forbidden) from devdocs.io?

[gabeklavans]

The URLs that are failing only show "forbidden",

They open fine for me, and both https://devdocs.io/docs.json and https://devdocs.io/assets/docs-a3fb1903db449c5e84dea94359b6be804abd505005baeccb160ed01af2a75a55.json download valid JSON in my browser. I should mention that running curl -L and wget on my command line myself with these links properly downloads the JSON. I don't think it's a problem with the URLs themselves.

To be more specific, I get a 302 and then a 200 from https://devdocs.io/docs.json

[ac-z]

The URLs that are failing only show "forbidden",

They open fine for me, and both https://devdocs.io/docs.json and https://devdocs.io/assets/docs-a3fb1903db449c5e84dea94359b6be804abd505005baeccb160ed01af2a75a55.json download valid JSON in my browser.

I guess it was just a problem on my end.