Mounted filesystem issue on Debian WSL when running CMake

[sfreed141]

• Your Windows build number: Microsoft Windows [Version 10.0.18362.175]

• WSL kernel info (uname -a): Linux SAFREED-DESKTOP 4.4.0-18362-Microsoft Will this be Open Source? #1-Microsoft Mon Mar 18 12:02:00 PST 2019 x86_64 GNU/Linux

• What you're doing and what's happening: I have a simple CMake project on the mounted fileystem (under /mnt) which fails to configure when run the first time with this error message:

Cannot copy output executable
  '/mnt/c/users/safreed/source/repos/wslbug/build/CMakeFiles/CMakeTmp/cmTC_06b98'
to destination specified by COPY_FILE:
  '/mnt/c/users/safreed/source/repos/wslbug/build/CMakeFiles/3.7.2/CMakeDetermineCompilerABI_CXX.bin'

• What's wrong / what should be happening instead: The file copy should carry out successfully without errors.

The strange part is the files that 'fail' to copy are actually being copied, so the next time CMake is run it completes without errors. Also, if I copy the project to the root filesystem instead (under $HOME) there are no issues. I verified this only repros when using Debian under WSL (Ubuntu is fine and Debian running under HyperV is fine).

Repro steps:

1. Create directory somewhere under /mnt on Debian WSL.
2. Create project files and run cmake

cat > CMakeLists.txt << EOM
cmake_minimum_required(VERSION 3.7)
add_executable(main "main.cpp")
EOM
cat > main.cpp << EOM
#include <iostream>
int main() {
    std::cout << "hello world" << std::endl;
    return 0;
}
EOM
cmake .

Expected output:

-- The C compiler identification is GNU 6.3.0
-- The CXX compiler identification is GNU 6.3.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/sam/wslbug

Actual output:

CMake Error at /usr/share/cmake-3.7/Modules/CMakeDetermineSystem.cmake:180 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt


-- The C compiler identification is GNU 6.3.0
CMake Error at /usr/share/cmake-3.7/Modules/CMakeDetermineCCompiler.cmake:175 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt


-- The CXX compiler identification is GNU 6.3.0
CMake Error at /usr/share/cmake-3.7/Modules/CMakeDetermineCXXCompiler.cmake:170 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt


-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Detecting C compile features
-- Detecting C compile features - failed
CMake Error at /usr/share/cmake-3.7/Modules/CMakeTestCCompiler.cmake:71 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt


-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Detecting CXX compile features
-- Detecting CXX compile features - failed
CMake Error at /usr/share/cmake-3.7/Modules/CMakeTestCXXCompiler.cmake:64 (configure_file):
  configure_file Problem configuring file
Call Stack (most recent call first):
  CMakeLists.txt


-- Configuring incomplete, errors occurred!
See also "/mnt/c/users/safreed/source/repos/wslbug/build/CMakeFiles/CMakeOutput.log".
See also "/mnt/c/users/safreed/source/repos/wslbug/build/CMakeFiles/CMakeError.log".

[therealkenc]

+1 thanks for CLI repro steps.

If you link a gist to the strace(1) log we can probably see the fail. strace -f -o cmake.strace cmake . (on the first run, natch).

I wasn't actually able to reproduce the problem here (no errors on first run) on my /mnt/c/users/ken/source/repos, but the only WSL1 I have handy is 16.04 with cmake 3.5.1. That difference very probably isn't going to be game changing tho. Just giving full disclosure caveat on the "can't repro here".

The strange part is the files that 'fail' to copy are actually being copied, so the next time CMake is run it completes without errors.

The "Actual output" part of your OP doesn't have a "Cannot copy output executable" cited earlier. Those kinds of copy fails are often acute #1529, but the failure pattern doesn't match very well here. There is no indication the reason the copy failed was EACCES. The fact that /home works suggest that isn't the problem. But it is the canonical reason for a failed copy on WSL1.

One thing to try first if you've got a win32 (Windows) cmake, gcc, etc installed is to launder your $PATH and see if that helps.

$ export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
$ # [create project files]
$ cmake .

But that's a WAG.

(under $HOME) there are no issues

That's how I'd roll.

[sfreed141]

Thanks for the quick reply!

I made the gist with strace and CMake logs if you'd like to take a look. Also, the CMakeError.log contains the "Cannot copy output executable" message I mentioned, apologies for not making that clear.

I don't see any EACCES, but I do see an EPERM on the file that "failed" to copy:

10702 chmod("/mnt/c/users/safreed/source/repos/wslbug/build/CMakeFiles/3.7.2/CMakeDetermineCompilerABI_C.bin", 0100777) = -1 EPERM (Operation not permitted)

Perhaps this is causing CMake to think the file copy failed? It's strange though because I don't see this error on my Ubuntu instance of WSL. I only see the issue when running Debian (I have Debian 9.9 installed).

Laundering the path doesn't seem to work for me unfortunately.

In general I'd agree the easiest solution is to just move the project under the root filesystem. However, for Visual Studio integration with WSL we need to have access from the Windows side so the project files have to be on the mounted filesystem.

[therealkenc]

[mass edit: do-over post to check something before making possibly false assumptions]

That chmod line suggests this might be because metadata isn't enabled on /mnt/c. I didn't have metadata enabled on my run either, so I didn't think of it. But then it working could be explained by my cmake version difference. Perhaps cmake 3.5.1 doesn't do the (largely superfluous) chmod.

To enable metadata on your /mnt/c add this to /etc/wsl.conf.

[automount]
enabled = true
options = "metadata"

Note that change doesn't take right away. wsl --terminate or a reboot to be sure. Your mount should look like:

$ mount | grep /mnt/c
C:\ on /mnt/c type drvfs (rw,noatime,uid=1000,gid=1000,metadata,case=off)

[sfreed141]

Enabling metadata seems to have fixed it, thanks!

[nmoreaud]

This happened to me when I moved WSL from disk C to disk D.
@therealkenc answer successfully fixed it