Midnight commander fails copying more than one file to remote directory.

[mikedpitt420]

Midnight commander fails on remote transfer of multiple files. If I open a remote ssh directory, and then tick off several files to copy, the first one completes. Subsequent files fail with an error that the disk is out of space, which it is not. The same files work individually but every second transfer throws this error. I have read that this is a midnight commander error and it is running out of space in /tmp as it leaves all files it plans on transferring and runs out of room. Is there a way to fix this so I don't have to upload manually one file at a time?

[mikedpitt420]

FINALLY got it figured out. I created two directories on my cache drive called: /mnt/cache/appdata/mctmp and /mnt/cache/appdata/mctmp/mc-root/

then type the following in command line:

alias mc="/usr/bin/env TMPDIR=/mnt/cache/appdata/mctmp mc" 

you can add that last line to the go script for persistence. Now MC / fish uses a directory on the SSD cache drive. This should also theoretically increase life of the flash drive as there are less read / writes to it. I wonder why this isn't something already configured this way for unRAID as it runs from a flash drive. Oh well

[BetaQuasi]

/tmp is in RAM, perhaps you are running out of the allocated ram disk space, in which case I suspect adding more RAM would resolve this for you.  I haven't experienced this particular issue myself, I regularly use mc to move a large amount of folders around on drives.

[mikedpitt420]

Not to a remote directory you don't  The post clearly says this happens only when using fish, and has nothing to do with normal MC operations. But thanks anyway.

[BetaQuasi]

Regardless, my point is that you're targetting the flash disk as the source of the problem, when it's actually RAM... which is why your workaround resolves the issue.  Agreed, I'm not using a remote destination, and I daresay most use cases, people don't use a remote destination.. which is why this wouldn't have come up before.

 

If you look through the forums, most people use rsync for remote destinations.

[mikedpitt420]

I was aware that it wasn't an actual disk space issue. I've moved 50GB files using MC locally from drive to drive. This was not that issue, as MC doesn't make a copy of the file in /tmp first when moving locally.

[trurl]

I was aware that it wasn't an actual disk space issue. I've moved 50GB files using MC locally from drive to drive. This was not that issue, as MC doesn't make a copy of the file in /tmp first when moving locally.

The point BetaQuasi is making is that /tmp in unRAID is actually a location in RAMfs, not a location on the flash. Most of the "normal" linux folders are in RAM. Only /boot and things mounted in /mnt are actual physical, persistent storage. The RAMfs is unpacked from bzroot and bzimage on the flash when you boot up.

 

So, storing things in /tmp does not impact the flash drive at all.

[mikedpitt420]

I got it. Maybe I didn't explain myself correctly. At no point did I think this had anything to do with the size of the usb stick. In fact I thought I had stated that fairly clearly, though I guess not. I am aware the /tmp runs in memory, and I am aware of the process in which unRAID loads from bzroot and bzimage. I appreciate the help though. Next time I will try to make myself more clear.