CommandBox server network share and Windows user account

I’m working on an app that needs to access a network share that requires authentication. I can log into it in Windows Explorer, but even after doing that, Lucee on CommandBox can’t access it.

One possible solution is for the Lucee server to be running under my Windows user account. From my reading of the docs about UNC paths, that’s possible. All I can do is run net use at the command prompt.

That’s not ideal, for a number of reasons, the biggest of which is that it will appear as a drive letter, not \shareddrive, which is how the code refers to it. Other devs here running Lucee without CommandBox don’t seem to have this problem, so it doesn’t seem to be “a limitation of how Java accesses UNC paths” in this case, as stated in the UNC path docs link above.

Am I missing something here?

What user is your CommandBox server running under? I don’t personally use UNC shares myself so I’ve not had to debug this sort of thing before. Can you access the share directly from the CLI for starters? Also, is your CF code just using things like CFFile to access these paths? If your server process is running as the same Windows user as your coworkers’ Lucee installs I would have expected it to work the same.

Thanks for jumping in here, no doubt I’m just being ignorant.

How do I see or control what account it’s running under? Is that in the docs?

I started the server from an admin cmd prompt. Does the server inherit that? Just now I tried a non-admin prompt, no difference.

And as I said, I’m logged into that share right now in Windows Explorer, works fine.

Thanks again,
Dave

Your CLI and servers work just like any other process you run. If you just open up a command windows and run it, it simply runs under your user.

I am 98% sure windows cli does not suppose unc paths. So if your command box instance needs access to the path it will not be able to use that path. Unless CommandBox does some kind of magic but I have run into this while trying to test using my windows in a vm on my Mac.

OK, that’s what I assumed, but still stuck.

Unfortunately, I think you’re right. Running dir on that path finds nothing.

That works from a PowerShell prompt, but running box from there opens it in a new cmd prompt window, which as expected from there still can’t access that directory.

This is Not Good. I’ve been the lone canary in the coal mine of CommandBox, feeling like it was a great solution for spinning up local dev boxes. Periodically I get static from upstairs about doing this non-standard thing, but when I can switch CFML engines on the fly in about 3 seconds, it quiets back down.

This may be the nail in this particular coffin. Not quite through exploring yet though.

Dave

I see 2 options. Have any files that CommandBox needs to access use a drive letter and then still allow your code to access via the unc path if it can.

Option 2 is to try the Linux style command line and maybe it can handle unc. This is assuming you are using the windows that has power shell.

Last ditch option could be to rewrite the cf code to use drive letter. (Not my actual recommendation)

Brad should be able to answer how to get box to run in powershell. I would have assumed running box in powershell would run it in powershell.

UNC paths work just fine for me in CMD CLI (Not PowerShell):

C:\Windows\System32>dir \192.168.1.7
The specified path is invalid.

C:\Windows\System32>dir \192.168.1.7\shared
Volume in drive \192.168.1.7\shared is shared
Volume Serial Number is 12FB-DA4F

Directory of \192.168.1.7\shared

06/27/2018 10:32 PM .
06/15/2018 06:37 PM …
10/13/2016 08:44 PM applestuff

Though this is dependent on my local user account having read access to the ‘shared’ folder on 192.168.1.7

Drive letter doesn’t work, in cmd prompt or Lucee under CommandBox.

I didn’t know you could do Bash on Windows, I should check it out, thanks for the idea. A bit of tail wagging dog here, but if it works and isn’t too hard to get going or deal with, it’d be cool. Wish I wasn’t a complete Linux newb…

Brad, do you have any sense of whether CommandBox would be happy in that environment, or if that would fix my problem?

How about running CommandBox in PowerShell? I see that there have been recent fixes for that environment, but as I said earlier, it didn’t run for me.

Hey, I’m at the dentist right now so I’ll catch up with all these messages later this evening.

Well, can’t really explain this, but my initial tests of the LAN ip-style path like you suggested didn’t work, on the cmd line or in Lucee under CommandBox.

Then suddenly, it did, both places. I’m not sure what to make of that, but for the moment at least, I can do my work. I do have to have a different path than everyone else, and given how weird it was acting I’m not going to suggest that others do the same.

Brad, I’d love it if you could point me to info on how ot run CommandBox under PowerShell. If it inheritd the ability to resolve \servername\share\ paths, that’d be great.

Thanks for your ideas everyone.

Dave

Hi Dave, back at home I had a look at this and I guess I’m a little puzzled at what you’re asking for or why it isn’t working for you. UNC paths work for me everywhere I’ve tried.

I was able to "cd’ into a UNC path in CommandBox like so (note, the backslashes need escaped)

cd \\ortushq-lb1\shared-data

Next, I was able to use the “ls” command in CommandBox to list the contents of a UNC path even if it wasn’t the current directory. (again note th escaped backslashes)

ls \\ortushq-lb1\shared-data

And finally, I started up a Lucee 5 sever and ran this code from a .cfm file to list out the contents of a UNC path:

The credential for this path are stored in Windows for my user and it worked flawlessly in all 3 cases. I guess I’d need more information about what’s not working correctly or what error you receive.

Regarding Powershell, I’m not sure what you’re asking there. To run CommandBox in powershell, you just run the binary like you would in cmd. Just open PS, type “box” and hit enter. I’m not sure how else to describe that :slight_smile: I think you may be confused in thinking that CommandBox or a server started by CommandBox would somehow run differently based on how you run it. Whether you double click the .exe or run it in cmd, powershell, conemu, or WSL bash, it all does the same thing. The only thing that changes that would affect you is the terminal which controls fonts, ANSI formatting, and mouse interactions.

Thanks for getting back Brad, I appreciate it. Responses interleaved.

Hi Dave, back at home I had a look at this and I guess I’m a little puzzled at what you’re asking for or why it isn’t working for you. UNC paths work for me everywhere I’ve tried.

I was able to "cd’ into a UNC path in CommandBox like so (note, the backslashes need escaped)

cd \\ortushq-lb1\shared-data

That doesn’t work for me in CommandBox, “No such file or directory”

Next, I was able to use the “ls” command in CommandBox to list the contents of a UNC path even if it wasn’t the current directory. (again note th escaped backslashes)

ls \\ortushq-lb1\shared-data

Also doesn’t work for me, “No files/directories found.”

And finally, I started up a Lucee 5 sever and ran this code from a .cfm file to list out the contents of a UNC path:

Also finds nothing.

The credential for this path are stored in Windows for my user and it worked flawlessly in all 3 cases. I guess I’d need more information about what’s not working correctly or what error you receive.

Regarding Powershell, I’m not sure what you’re asking there. To run CommandBox in powershell, you just run the binary like you would in cmd. Just open PS, type “box” and hit enter. I’m not sure how else to describe that :slight_smile: I think you may be confused in thinking that CommandBox or a server started by CommandBox would somehow run differently based on how you run it. Whether you double click the .exe or run it in cmd, powershell, conemu, or WSL bash, it all does the same thing. The only thing that changes that would affect you is the terminal which controls fonts, ANSI formatting, and mouse interactions.

When I first tried running CommandBox from PowerShell, it opened in a new cmd window, but that was because I needed to run PowerShell as admin.

If I do that, it runs in the same window, but cd and ls still don’t work there.

Tested them again in that admin PowerShell window itself, also not working.

I’m logged into that server in Windows Explorer, viewing the files.

Using the LAN /IP adr works, so I can do that locally, but nobody else has to do that. I’m not on this domain, unlike everyone else, which might be the issue, but it works in Windows Explorer, so, dunno.

Thanks again for investigating. I’m stumped, will use the IP for now.

Dave

After logging into that dir in Explorer, I can do dir of it from a NON-admin cmd window.

From an Admin cmd prompt, it says the user name or password is incorrect.

When I type box and hit enter in a NON-admin cmd window, CommandBox opens in a new window, which can’t access that directory.

Is there something built into CommandBox that requires admin access? I don’t see the file having any special permissions.

Thoughts?

Dave

Hi Dave,

I happened to see this and wanted to point you to this thread. I know this works with CF server as we did
this on a big job about 4 years ago with 4 different UNC paths. Our network guy made it all work so I don’t know details.

https://forums.adobe.com/thread/243571

I think it’s safe to say here that CommandBox/Java/Lucee full supports UNC paths but there is an issue with the configuration on your computer. I’m not sure how much we can help you there since I think you need to debug your network configuration, what permissions are required to access the share, and what user is being used by your Java processes. I think CommandBox is more/less an innocent bystander here.

Can you confirm any saved credentials you have on your PC for that share?
https://www.faqforge.com/windows/how-delete-saved-passwords-for-network-drives-in-windows/

After logging into that dir in Explorer, I can do dir of it from a NON-admin cmd window. From an Admin cmd prompt, it says the user name or password is incorrect.

I would recommend looking for resources that will allow you to confirm what username the Java process is using when connecting to the file shares. I think that’s really what you need to determine. I know that running processes with “sudo” on *nix actually changes the user name in use, but I’m not aware of any similar behavior in Windows. That said, I don’t know what version of Windows you’re on, how your domain is setup, or anything so only you can really dig into those details.

When I type box and hit enter in a NON-admin cmd window, CommandBox opens in a new window,

I’ve never heard of this behavior nor can I reproduce it on my Windows 7 and Windows 10 PCs. I would check with your system administrator to see what sort of special policies may be applied to your computers.

Is there something built into CommandBox that requires admin access?

Not at all. In fact, I don’t even think that’s possible It sounds like your computer has a setting that is forcing this.

Question: How exactly do your other coworkers have ColdFusion running? Is it starting as a Windows service? if so, what username is being used? Have you done a comparison of the exact CF process on their machines with the CF process on your machine. (Note, you can add additional columns to the Windows Process Explorer, or use a 3rd party tool like ProcExplorer from SysInternals to give you deeper information). I really think this boils down to the user in use and the permissions required for the share, but all of that is something you will need to debug from a Windows/domain/network level. I have a feeling you need to configure your server to run as a service under a specific user or you need to employ “NET USE” to set the user of your process before starting the server.

And if you want to pretty much completely remove from the equation anything CommandBox does, open the REPL and run this direct Java code swapping out the server name and share for your own. We know for certain that Java itself supports UNC paths so if this fails, then we know the issue is outside the JVM on your PC, domain, network, etc.

createObject( ‘java’, ‘java.io.File’ ).init( ‘\ortushq-lb1\shared-data’ ).list()

That Java code is as close to the JVM as you can get. In fact, it even eliminates Lucee from the picture! When I run that, I see an array of folder and file names. Also note, you can’t list the contents of a server directly like \serverName, it has to be a share like \serverName\Share

I know this is an old thread, but I had jumped through a bunch of hoops to run a local CommandBox (with Lucee) in conjunction with a non-CommandBox Lucee for production. All my files on my prod server are in the F: drive, F:\Radio. A true Windows partition, attached drive to the VPS. On my local, I tried a bunch of stuff, like SUBST, etc. But in the end, where all my files are on the network, and had to use \share\mapping\Radio and that meant all my database entries are wrong.

I run CommandBox in a cmder gizmo, Quake style. When I fire up cmder the first time, it opens three tabs. One each for two Adobe Coldfusion instances (for my main job) and a Commandbox tab for running my local (personal, etc.) stuff.

Now, I run the Commandbox tab as admin. Not my local user. This was part of the problem. I decided to copy all the production files from my network share (well, the “mirrored copy”) to my local machine. I created C:\F-Drive\Radio. Then, before Commandbox starts, with the cmder script, I simply did:

net use f: \\localhost\c$\F-Drive

Now the CommandBox instance and running Lucee are able to see an F: drive, just like my production box. Now all my database entries are good and I can just restore the prod db locally. (Keeping all the music files, artwork, etc. synced is a different concern. If I were still mapping to my NAS, I’d have had to add the user/pass, too, but that could certainly be done. (All the file work I do is much faster locally, anyway, than it would be on the NAS over the Wifi.)

I hope anyone finding this thread might be able to use that information.

I assume that just boils down to the user CommandBox was running under not having the same mapped drives. You shouldn’t have needed to create a local copy of the files unless you just wanted to. I assume mapping f: directly to the actual network location would have worked all the same.

If you ever need to debug what drive letters Java’s user ‘see’ on the OS, you can dump out this code:

createObject( 'java', 'java.io.File' ).listRoots()