Thanks to everyone who pointed me in the right direction on this problem, I have been able to find a work around that allows me to push to an archive on a network file share. After some digging, I discovered the root of the problem. Briefly, Darcs uses the standard library System.Directory to perform file manipulations. This library make use of compiler pragmas to conditionally compile either the Windows or Linux specific functions based on the host operating system. This approach assumes that when your operating system is a Linux variant, all your mounted volumes will natively support POSIX. When you have mounted CIFS volumes, this will result in errors when calling those library functions to create, rename, copy and delete files or folders! Given the flexibility of the Linux operating system, A more versatile implementation for System.Directory might be able to detect the file system of each volume at runtime and choose the appropriate functions to call. But I digress... To workaround the inability to push to a CIFS volume in darcs, I modified the workaround.hs module to shell out to the OS's rename function rather than using the Haskell library's rename function. Specifically: I added the following code after the #else near line 80: renameFile :: FilePath -> FilePath -> IO () renameFile old new = do ecode <- System.Cmd.rawSystem "mv" [old,new] case ecode of ExitSuccess -> return () ExitFailure n -> putStrLn ("renameFile failed with exit code" ++ show n) which ensures that when the operating system is not WIN32, that renaming of files will be performed by the OS shell. I then added the System.Cmd module to the list of imports by inserting the following code near line 21 import qualified System.Cmd(rawSystem) after a recompile I could push to a CIFS volume, for example: sudo darcs push /mnt/cifsvol this is an obvious hack, and does not address the inability to put to a CIFS share (put depends upon copyFile and would need to be hacked to shell-out as well). Archives on the CIFS share have to be created by navigating to that folder and initializing. Shelling out is clearly a poor long term solution; a longer term solution would ideally introduce into the Haskell System.Directory library the ability to apply the correct functions transparently in accordance with the file system of the volume. Cheers -Darrell Lewis-Sandy