Custom Query (16363 matches)
Results (598 - 600 of 16363)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #15674 | fixed | Shared Folders Inaccessible in Guest Windows 10 Insider Previews (post-10586) | ||
| Description |
I know that pre-release versions cannot be considered supported, but consider this simply a heads-up that I've not been able to access shared folders in guest Windows 10 insider versions sometime after 10586, including: 14372 14388 14393 (attached) |
|||
| #15338 | fixed | unable to log into guest after installing guest additions 5.0.18 | ||
| Description |
After upgrading to 5.1.8 (host is OSX 10.11.4) and upgrading guest additions on guest (Ubuntu Desktop 14.04 LTS - 64 bit) from 5.0.16 to 5.0.18, I could no longer log in to any of the accounts on the guest machine. I reverted to snapshot of the VM with the previous guest tools (5.0.16) installed and I was able to log in OK (still using VBox 5.0.18) |
|||
| #11583 | obsolete | Can't force overwrite/delete from Linux Guest when R/O set in Win Host | ||
| Description |
Normally GNU programs on Linux such as cp, rm, etc can use the "-f" option to force the operation on a file that doesn't have write permissions. However, if the underlying file is set to "read-only" on the Windows Host, the operation will still fail and return "operation not permitted". A little bit of testing shows the following:
I believe that the correct behavior should be to allow the Linux Filesystem to decide whether or not an operation is permitted based on its permissions and access rights (ex. Root can do whatever it wants). To summarize this issue in one statement: "Linux permissions should be synchronized with Windows Attributes; therefore, if the Linux Filesystem consents to allow an operation in spite of that, the Windows Host filesystem should not be able to override it." |
|||

