mv: cannot move, Permission denied in WSL
I’m getting mv: cannot move, Permission denied error, but before claiming this is a dupe, please see what I’ve tried first:
First of all, it has nothing to do with file or directory mode:
$ mv -f .emacs.d .emacs.d.old mv: cannot move '.emacs.d' to '.emacs.d.old': Permission denied $ ls -Al . | grep emacs drwx------ 1 me me 4096 2021-06-11 23:04 .emacs.d ls -ld . drwxr-xr-x 1 me me 4096 2021-06-12 00:17 . $ sudo mv -f .emacs.d .emacs.d.old mv: cannot move '.emacs.d' to '.emacs.d.old': Permission denied $ mv -f .emacs.d ./.emacs.d.old mv: cannot move '.emacs.d' to './.emacs.d.old': Permission denied $ df . Filesystem 1K-blocks Used Available Use% Mounted on rootfs 307276796 200040828 107235968 66% /
Second, I tried with every file-open checking tools that I know:
$ jobs | wc
0 0 0
$ lsof | grep .emacs.d | wc
0 0 0
$ fuser .emacs.d | wc
0 0 0
and I’ve tried to close whatever that might or might-not related to the .emacs.d directory, including closing vs code that has nothing to do with the .emacs.d directory.
Full disclosure: I am using Windows Subsystem for Linux, but I don’t think I have the directory open in any other bash instances. Moreover, as seen in first output, my home dir is within WSL, not under any windows folder (i.e., should have nothing to do with any Windows programs).
I have ran out of ideas what could possibly be holding me back to rename this newly created directory.
Answer
This is a bug in older WSL implementation which keeps pinning all the opened files but forgets to track them when they’re closed. This is fixed in most recent versions of WSL and WSL2.
As a temporary hack, one can cp to target and rm the old source