File Manager is hard to understand

[birdie]

User Name/Password? Where can I set those? There's nothing in the VM options.

Maybe you've left something out?

This thing needs to be more intelligible.

[klaus]

The file manager is based on "guest control" functionality, which (for most things) needs to authenticate on the guest OS. So the username/password is simply the one in the guest which you want to use.

[scottgus1]

"Guest User Name" and "Guest Password" could make the idea clear with little fuss, maybe.

[mpack]

It's hard to see what other username and password could possibly be relevant. I mean it could hardly be asking for the host login!

[klaus]

Yes, it's the reason why the fields are on the "guest side"... we'll see what's possible to make this more obvious. Putting "Guest" everywhere tends to be a waste of space, adding more clutter than actually useful hints.

[birdie]

"Guest User Name" and "Guest Password" could make the idea clear with little fuss, maybe.

You mean Windows login and password? Really? Why are they needed at all if a Windows guest has a VirtualBox driver which allows pretty much full access to hardware?

This makes literally zero sense. The host OS after all can read all the bits and bytes for the guest disk image.

[scottgus1]

You mean Windows login and password? Really? Why are they needed at all

Probably from this:

The file manager is based on "guest control" functionality, which (for most things) needs to authenticate on the guest OS.

If Klaus's words are taken as is, then this from the manual may indicate why a guest username and password:

8.32 VBoxManage guestcontrol
The guestcontrol commands enable control of the guest from the host.
...
VBoxManage guestcontrol <uuid|vmname> <sub-command>
[--username <name> ]
[--passwordfile <file> | --password <password>]
[--domain <domain> ]
[-v|--verbose] [-q|quiet] ...

Modern OS's don't like getting told what to do from outside. Even PsExec from MS Sysinternals requires username & password to get the remote computer to do something. When copying a file to another computer's shared folder, the sharing computer requires username & password. Guest Additions Shared Folders doesn't require username & password because the 'sharing' is enabled on the host OS by the already-logged-on user who has authenticated with a password.

[birdie]

You mean Windows login and password? Really? Why are they needed at all

Probably from this:

The file manager is based on "guest control" functionality, which (for most things) needs to authenticate on the guest OS.

If Klaus's words are taken as is, then this from the manual may indicate why a guest username and password:

8.32 VBoxManage guestcontrol
The guestcontrol commands enable control of the guest from the host.
...
VBoxManage guestcontrol <uuid|vmname> <sub-command>
[--username <name> ]
[--passwordfile <file> | --password <password>]
[--domain <domain> ]
[-v|--verbose] [-q|quiet] ...

Modern OS's don't like getting told what to do from outside. Even PsExec from MS Sysinternals requires username & password to get the remote computer to do something. When copying a file to another computer's shared folder, the sharing computer requires username & password. Guest Additions Shared Folders doesn't require username & password because the 'sharing' is enabled on the host OS by the already-logged-on user who has authenticated with a password.

VirtualBox additions running inside the Guest can do whatever the host OS tells them to do. And this is actually the case. I'm still not convinced.

Anyways this feature needs to have UI or a link to a Help Topic. Please.

[scottgus1]

VirtualBox additions running inside the Guest can do whatever the host OS tells them to do.

Can we get a few examples of this, please?

[mpack]

I'm not even sure what is being discussed. Convinced about what? That PCs need passwords?

[klaus]

Guest Additions can do a limited amount of "miracles", but certainly nothing close to what birdie is hinting. Access to hardware doesn't really help when the goal is to access filesystems available inside a guest OS. They tend to be (especially on Windows) extremely user specific, in particular network shares and the like. But even for disks it would be asking for disaster if Guest Additions would bypass the running guest OS, and pretend it could safely read and write to the filesystem which is concurrently accessed by the guest OS.

Virtualizers can only do very limited miracles, so please adjust your mental picture to be more in line with reality.

[birdie]

Guest Additions can do a limited amount of "miracles", but certainly nothing close to what birdie is hinting. Access to hardware doesn't really help when the goal is to access filesystems available inside a guest OS. They tend to be (especially on Windows) extremely user specific, in particular network shares and the like. But even for disks it would be asking for disaster if Guest Additions would bypass the running guest OS, and pretend it could safely read and write to the filesystem which is concurrently accessed by the guest OS.

Virtualizers can only do very limited miracles, so please adjust your mental picture to be more in line with reality.

VirtualBox additions is a Win32 application. It can read and write files using normal Windows API. It can talk to the host OS. After all as a user you can drag-n-drop files from the host OS to the guest OS - it does not require username/password, so you already have this feature in place.

I wonder why File Manager is different.

[Whiskeyjack]

VirtualBox additions is a Win32 application. It can read and write files using normal Windows API. It can talk to the host OS. After all as a user you can drag-n-drop files from the host OS to the guest OS - it does not require username/password, so you already have this feature in place.

I wonder why File Manager is different.

Yes but for that to work you will have to login to guest desktop first. Guest control (what file manager uses underneath requires username/password). If you have specific suggestions that might make file manager a bit more user friendly then we are all ears.