I made a big mistake while trying to secure some folders on our Windows Server 2016 by disabling ACL inheritance for numerous folders on D:, which are owned by the administrators group. This included the D:SHARE folder, a network share that contains our QuickBooks database (.QBW), along with several crucial files used for accounting tasks. Since making this change, our accounting team has reported they can't upload PDFs or other files directly into D:SHARE.
I'm trying to re-establish proper permissions, and I plan to regain ownership of D:SHARE as the administrators group and propagate that ownership. I want to ensure that all the necessary users and groups, including the 'QBDataServiceUserXX,' have appropriate access. With yearly audits approaching, it's critical to resolve these issues related to QuickBooks services. I need guidance on how to restore functionality for tasks like PDF attachments, multi-user mode, transaction saving, printing, emailing invoices, and backups. Am I completely lost in this situation?
6 Answers
Take ownership of the D:SHARE folder first. Grant yourself full control, and then restore the permissions that should belong to the domain users. That could help get things back on track.
Consider moving the QuickBooks files to a separate share. The QuickBooks database server will create its own share for the folder housing the database and will provide it with full permissions for 'Everyone.' This setup might work better for you.
I get where you're coming from, but if you're thinking of moving the .QBW file to a new directory, make sure to have inheritance enabled from the root for proper access.
In a similar case, someone overlooked permissions and it resulted in a massive data mess. My recommendation is to stick to your backup and restore it instead of messing with permissions manually; it will save you from a headache. Start by taking ownership at the root and re-enable inheritance wherever needed.
I found a guide that mentions adding the 'QBDataServiceUserXX' group to the directory housing the .QBW files. It might give you a clearer direction on how to set everything back up properly.
You might want to check who currently has permissions outside of the admin group. If all your accounting users share similar permission levels, try to replicate those permissions back to D:SHARE for a simple fix.
Hopefully, you have a backup in place! If you can access shadow copies or previous versions of D:, that could save you a lot of trouble. Just browse them to see if you can recover earlier permissions.
We do nightly backups to Carbonite, but I’m worried about whether I should restore just D:SHARE or do a full server restore instead.
Honestly, considering your situation, restoring from Carbonite might be the quickest fix.
Sounds like a solid plan! You really should consider doing that right away.