[Solved] Databases on vms go read only; hyper-v likewise, but not vmware

[hangerglide]

This is a real puzzle. I have been using virtualbox on a windows 7 pro host, domain environment, with windows 7 pro and 10 pro vms, with various editions of Microsoft Office installed. I develop MS Access databases, and each version of Office/Access works best if there are no other Office installations on the same OS.

After years of working without a hitch on vbox vms with Access, a year or so ago I noticed that Access databases that link to tables in another Access database started to go read-only, sometimes after being read-write in the same session. IOW, the db opens, the data should be edit enabled and sometimes starts that way, and then the linked tables go read only so that the data is viewable but no longer editable. The only thing that will temporarily solve this is to reboot the vm. I found this behavior for Access versions 2010 2013 and 2016. I then tried hyper-v on windows server 2012 r2, and was surprised to find the same problem in effect. What is also completely consistent is that the same databases never exhibit this behavior if they're running on hardware, ie not in a vm. Also consistent is that any Access front end that links to a sql server db backend (tables etc) via odbc never shows this issue

A database engine like Access evaluates the linked data source and decides if it's safe to allow edits. There mundane circumstances where the db engine will decide to disallow edits. None of these oddball read only linked tables fit into those normal causes; but the behavior is exactly the same.

This has been a big deal for me and I was about to give up on vms for this need when I remembered vmware, my first exposure to virtualization, and which I haven't used much for a long time. I installed vmware workstation pro 15 and to my great surprise found that the databases run normally.

Does anyone have a suggestion as to why vmware doesn't trigger this issue? Might there be a memory setting that has an impact?

[hangerglide]

I sure hope I don't draw a blank here. I like virtualbox a lot; I would by far prefer to resolve this issue so that I can continue to use it for these tasks.

[socratis]

Where are the database files located? In a VirtualBox Shared Folder perhaps?

[hangerglide]

They're on a folder that is located inside the vm. I hadn't even heard of a vbox shared folder before now. The folders are not shared in the normal windows sense.

I'm so glad you responded...I am pressed to fix this issue and prefer the work environment that virtualbox offers vs vmware. But I have to move to vmware unless I can resolve this issue.

[socratis]

So, this is a self contained VM that accesses files "locally", within the VM? How did you get these files there, networking SMB folders? If you were to send my just the VM files, I would be able to reproduce it in another computer for example? Any signs of your host's hard drive acting?

We need to see a complete VBox.log, from a complete VM run, when the problem happens:

• Start the VM from cold-boot (not from a paused or saved state) / Observe problem / Shutdown the VM (force close it if you have to).
• With the VM completely shut down (not paused or saved), right-click on the VM in the VirtualBox Manager and select "Show Log".
• Save only the first "VBox.log", ZIP it and attach it to your response. See the "Upload attachment" tab below the reply form.

[hangerglide]

Yes self contained vm that access the files which are at issue internally. The files get to the vm via a sync system called syncthing. The sync system is the same for all three vm systems (vbox vmware workstation and hyper-v).

Yes if I send you the vm it'd work for you, no outside dependencies. You made me want to perform a test - do the files go read only if they are on a shared drive which is NOT on the vm. I will test that. I should also install another copy of virtualbox and see if the issue happens there.

Hard drives are ok on both rhe virtualbox pc and the hyper-v pc. vmware is on the same pc as virtualbox. As a reminder I have no issues with vmware.

If I send the log will it expose "private" data? I'm not sure I can have a log like that in a public space.

It is something subtle, and issue with memory or something of that order. The databases act exactly like they do when the db engine decides that conditions are not certain enough to allow write access to the data. The only difference is that a table can open and show as editable for a short time before the editability is turned off. Never seen this before.

And I just tried vbox 6, hoping to get lucky, but no change.

[socratis]

If I send the log will it expose "private" data? I'm not sure I can have a log like that in a public space.

Let's start with that. Besides the location of your VM on your host, and potentially your host's serial number (I don't think it's included, look at the beginning of the log), there's nothing private in the log. See my signature...

This is one of the few times that I'm going to say this, but if you don't feel like your "username" being included, you could replace all instances of it. But ONLY if your username is plain ASCII, no ü, ø, é, or αβγ, or any other funky characters. Just to give you an indication, my username in host/all_guests is 'socratis'. I have no problem with making that public...

What I want to look at is for any messages that the hard drive is "loosing" it. If there are any timeouts, any warnings, any failed attempts, whether you have the cache on/off, and things of that nature. I've seen VMs going read-only (the whole thing) just because the kernel wasn't getting the expected times in read/write operations. In order to prevent what the kernel sees as a problematic, starting to fail hard drive, it takes it into read-only mode to prevent further damage. But that was with Linux...

[hangerglide]

I'm pretty sure it's not a disk issue - it's not like the file itself is turning read only. The database engine decides to turn off the ability to edit data. I can still edit other aspects of the db, like create a new form or report.

But what is really interesting is that at least as of this AM something may have changed - I am having much more success with these vms than I have ever had. I kind of can't believe my eyes - I've spent days on this issue because it's been such an obstacle. But right now I'm seeing none of the misbehavior. Both virtualbox and hyper-v both seem to have shed the problem. This would have to be from a windows update, I'd think. But if I recall at some points the issue didn't show up right away, so I can't really be sure it's resolved for a while yet.,

[hangerglide]

The issue did happen again; I'm very surprised though that it seems to be occurring far less than it has been in the last year.

I am uploading the log file, with login modified. Thank you for having a look at this issue.

[Martin]

How many VMs are you running at the same time?
Did you already try configuring the VM with 2 virtual CPUs?

[hangerglide]

Often just one vm. 6 gb ram allocated. I'll try 2 cpus, that's a new setting for me.

[hangerglide]

Well, dang, with 2 cpus, my most reliably problematic vm worked normally. I can imagine that somehow having 2 cpus might help with this issue. I'll keep testing and report back if the issue repeats (and there is a good chance that it will, I've seen good days when things worked for a short time). Thank you.

[hangerglide]

To show how important this issue is to me, two weeks ago I started planning on buying 5 small pcs to run these databases on, each with a distinct copy of office/Access. When I discovered that vmware worked, that plan got put on hold (fortunately). If virtualbox will work out that's by far the best solution.

[hangerglide]

The change to two cpus seems to be a solid fix for this issue. No issues so far, and it's been a week. Thank you!

[socratis]

Great call from Martin there...
Marking as [Solved].