Hacker News Reader

Comment by int_19h | Hacker News Reader

I'm curious whether anyone had ever tried implementing a pure userspace solution (without a kernel driver) by basically exposing the underlying FS as a CIFS share on some random local port. Obviously, that would be slower, but for many applications that doesn't matter much - while the ability to install and run without administrator privileges would be valuable.

View on HN

This is how CDRom worked under DOS(MSCDEX).

from wiki:

>The driver uses the Microsoft Networks interface in MS-DOS. This is the reason that at least version 3.1 of MS-DOS is required. The driver essentially looks like a network drive from the system perspective. It's implemented as a TSR program[3] and an extension to the redirector interface (CDEX).

OpenAFS used to do this if I remember right. They moved to an IFS.

How do I connect to CIFS on non-default port?

The only way I found was to use (cygwin ssh) port forwarding to map that port to the standard one, kill the default network SMB process (which restarts), and hope my process wins the race. Then you could access the remote shares at \\127.0.0.1 .

I think I also managed to create a loopback device, put it into its own subnet, and map the port to that device, and then it was possible to do e.g. \\192.168.100.56, but it was a pain to set up.

The reason I needed this was, I wanted to run samba as non-root on a remote host (on a non-privileged port), and forwarded that with ssh though a firewall. This way I could access my files on the remote Linux server from my windows desktop. One problem is that windows does not tolerate hanging connections much, and a bad or lost connecting can freeze your program or require a reboot. I'm not sure how much is the kernels fault and how much you can code around this.

Dirty hacking as it is. In similar situations I just use SFTP.

I've seen UNC paths with port number before, so I assumed that it's possible; but apparently those are for WebDAV.

Of course, this means that it should be doable with WebDAV instead of CIFS. Which would probably mean even worse perf, but still potentially acceptable...

Can WebDAV paths be used without mounting them to a drive letter first, though?

I've done this, it works.

On Windows? I didn't think Windows would connect to SMB/CIFS on any other ports other than 139/445.

Can you share any other details?

Not sure you can do it easily with SMB/CIFS (maybe some NAT tricks) but depending on the level of FS support you want it's pretty easy to do it with WebDav. You can mount a webdav share pointing to localhost on an arbitrary port (I believe it's of the work \\localhost@portno\DAVWWWRoot). From there I'm sure you could proxy out to any other FS implementation you liked. It also probably isn't great for large files etc due to the way WebDAV works of course :-)

For this particular client we had Administrator access. SMB was used since we did not trust Dokan and did not want to pay for CBFS.

Reply on news.ycombinator.com