Hello Florian,
Thank you for the update.
To answer directly, no, the DVLS Backup Manager does not expose a credential field for the backup destination.
There is no "connect as" or "run as" input for the SMB path in its UI.
Access to the share is always performed under the identity of the Windows service accounts that touch the .bak file, which in your setup are the SQL Server service account and the DVLS Scheduler service account (plus the DVLS Runner service account if you use manual "Back Up Now", and the IIS application pool identity if you use web backup).
Because you do not have Active Directory, the supported way to authenticate those services to a password-protected share is the "mirrored local account" workgroup pattern.
Concretely:
Create a dedicated local Windows account, for example DVLSBackupSvc, with the same username and the same password on three machines: the file server hosting the share, the SQL Server host, and the DVLS host.
Grant that account Modify on the SMB share, and Modify on the underlying NTFS folder.
Change the SQL Server service to log on as that account (using SQL Server Configuration Manager, so ACLs and permissions are applied correctly), instead of Network Service.
Change the DVLS Scheduler service (and the DVLS Runner service, if manual backups are in scope) to log on as that same account.
If you also perform backups through the web UI, set the DVLS application pool identity in IIS to that same account.
Once every service runs under this mirrored account, Windows can present valid credentials to the share transparently, and Backup Manager itself does not need to know anything about them.
Before re-enabling the schedule, please validate manually from each host by opening a command prompt as that service account (runas /user:.\DVLSBackupSvc cmd) and performing a copy and a delete against the UNC path. If both succeed on both hosts, the "Can't open File" error should be gone.
An alternative, if creating a dedicated account across three machines is inconvenient, is to host the share directly on the SQL Server itself and grant the DVLS service account (mirrored locally on the SQL host) Modify on that share. This removes one host from the authentication chain.
Please note that pre-caching credentials with cmdkey under a service account profile is not recommended and not supported for Backup Manager, as the credential store is per-user and brittle across password rotations.
Best regards,
