I have a volume with several directories in the root. One of those is a Restic repository, for example:
D:\>dir
Volume in drive D has no label.
Volume Serial Number is C04B-C796
Directory of D:\
10/14/2022 03:01 PM <DIR> admin
06/26/2022 03:44 PM <DIR> archive
10/14/2022 12:27 PM <DIR> data
10/16/2022 06:23 PM <DIR> restic
10/17/2022 04:38 AM <DIR> tmp
0 File(s) 0 bytes
5 Dir(s) 207,147,569,152 bytes free
The permissions on the root are only SYSTEM and Administrators: FULL CONTROL. All the child directories have inheritance and any additional permissions as required. All but the Restic repository are shared.
I run a scheduled task for Restic on this server with a service account that has the required permissions to the d:\restic directory, However, without read permissions on the root, some (but not all operations fail):
restic.exe backup ...
...
Fatal: unable to save snapshot: Lstat: CreateFile \\?\D:\: Access is denied.
I can forget and prune, I just can’t backup. This forces me to break inheritance on all the root child directories so I can add read permissions for the service account.
The lstat call to the root would only be possible with a local filesystem, and I don’t see what purpose it serves.
It could be that D: needs to allow your service account to be granted Traverse and perhaps List Folder permissions. This permits the account or group to pass through the directory, but not perform any reads upon it’s children or files.
These permissions can be added via the CLI but test first (use with care if you are inexperienced) or by the GUI via Folder Properties->Security tab->Advanced button->Permissions tab->Add->User or Group->“Show Advanced Permissions” link in main pane.
Set “Applies to” to “This Folder Only”, enable “Traverse folder”, OK out of all. It’s possible you may need to repeat for “List folder”.
If it’s definitely a bug it may be worth searching the existing issues, and submitting a new one if none of those fit. Restic usually has a long release cycle so working around the existing behaviour is something you’ll have to do for a while.
Why do you even have only SYSTEM and Administrators in your permissions for D:\ ? Normally there is also the Users group, which is able to traverse and such. Your configuration seems wrong to me.
Wrong is subjective, the discrepancy in the convention was due to me trying to repurpose the volume for use with a non-shared Restic repo. This would not have been a problem if I accessed it over UNC using a share, but I understand there are problems with that.
With the permissions set the way they are, new child directories created for new shares will inherit the minimally correct permissions and need only their share-specific permissions added.
All of these shares must not allow read access to BUILTIN\Users.