Revisiting - System.IO.IOException: The specified server cannot perform the requested operation

Hi all…

My regular local backup (2.0.4.5_beta) runs 7-days a week / every 2 hours.
This error has occurred twice over the last week or so and just happened again but other than that, my backups run just fine.
This is going to a local NAS for which I use this url:

\\NASname\ShareName/MyFolder/MySubFolder

When the error happens, if I simply go into the settings for that backup and “Test Connection” and then go back to the Home page and run the backup, it proceeds with no issues and will continue auto-running for days as its supposed to.

The other odd thing I just noticed is that my log file was not updated with this error or a warning.
The log-file-log-level setting is “Warning”.

This is the error message I received by email:

Failed: The specified server cannot perform the requested operation.
  Details: System.IO.IOException: The specified server cannot perform the requested operation.
    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
    at System.IO.FileSystemInfo.get_Attributes()
    at Duplicati.Library.Main.Controller.ExpandInputSources(String[] inputsources, IFilter filter)
    at Duplicati.Library.Main.Controller.<>c__DisplayClass13_0.<Backup>b__0(BackupResults result)
    at Duplicati.Library.Main.Controller.RunAction[T](T result, String[]& paths, IFilter& filter, Action`1 method)

Thanks…

What’s odd is that even though ExpandInputSources is on the sources side, this message appears to be NAS-related (glancing through Google of “The specified server cannot perform the requested operation.”).

Might there be any way e.g. via mklink that something in the “Source Data” config got sent to a NAS area? Possibly you could try different subsets of your current sources (easily done via Commandline or Export).

Is Duplicati running as a user at login, or as Windows service? Services have SMB authentication issues.

You could try setting up –log-file at –log-file-log-level=verbose or higher. Even though ExpandInputSources doesn’t announce every expanded result, it does issue some of them. Maybe it will give clues about failure.

If you think it might be related to your NAS somehow, maybe there’s an error log there, or you could add its brand name to the Google query at top to see if anybody has seen a similar problem there in some way…

What confounds me is that it is so intermittent but that said, (I’m an idiot) about a month ago I did indeed add a few source files that live on another share on my NAS. They are part of a new workflow and I delayed adding them to my other backup profile, which of course has had no errors so I would say it’s 99.9% sure that they are the culprit. And I did read the positing noted above however I am positive my backups ran normally for at least a week or so before this error first appeared and I still find it bizarre that the backups run properly most of the time.

The details:
It is a OMV (open media vault)
The client is indeed Win-10 so the shares are indeed SMB
Duplicati is running as a service to leverage VSS
The service is running as “Local System Account”

And that all said. I didn’t notice but while I do get the lovely red Error dialog in the UI saying “Server cannot perform bla bla bla”, if I click on “Show”, there is no log information for the time period in question.

I did change the log-file to Verbose but it only includes 2-lines; that the operation backup has started and that the email was sent.

And to confirm, if I open the suspect profile in the GUI and “Test Connection”, then click home and run the backup, it runs and completes normally. Not sure of the connection but that might cause things to work because my Windows user name and password are the creds needed to access the NAS shares.

Services, LocalSystem, and shares are a troublesome mix. Active Directory can sometimes help, but most home users won’t have it, and I wouldn’t be able to help you with that anyway. Here’s an example of trouble:

Service Install Backup to UNC Paths

When running from a service, you do not have the “user context”.

LocalSystem Account

The account is not associated with any logged-on user account.
The service presents the computer’s credentials to remote servers.

Services and Redirected Drives

A service (or any process running in a different security context) that must access a remote resource should use the Universal Naming Convention (UNC) name to access the resource.

UNC source with credentials?

So I’m not sure quite what path would steer around all the impediments, but my past attempts at getting shares working have been quite erratic, possibly due to various setups that are cached awhile then end.

If your own account is an “Administrator” as opposed to “Standard User”, you can change the service to run as you. I think there’s a way to tell it to elevate (like UAC can do) which VSS might insist on having…

If a service still won’t get access, you could start Duplicati via a shortcut with Properties → Shortcut → Advanced → Run as administrator checked, and there’s also a trick involving starting a task to do that, basically saving you the trouble of having to manually go through the UAC prompt to get the program up.

As always Ts678, your help is appreciated!

Indeed my daily login is as a standard user, not as admin (and definitely no Active Directory here), and I guess I’m lucky “knock on wood” that I have no issues running Duplicati as a service for VSS and writing the backups directly to my OMV NAS. I just removed the two NAS based source folders and everything seems to be running smoothly again.

I put in place a workaround using Xcopy, a .BAT file and Task Scheduler to regularly check the specified NAS based folders for new files and copy/replace them to a local holding folder so Duplicati can grab them but the above noted thread (that I had not come across) “UNC source w credentials” is very interesting. On an initial read it seems “Windows Credential Manager” or perhaps ‘cmdkey’ commands and a pre / post script would do the trick. I will give them a whirl…
And you also noted that mounting the folder as CIFs worked for you. I can designate the shares to provide access via several protocols so that might be an option as well…

Well, I couldn’t leave it so decided to try “Windows Credential Manager” now and, by all appearances it works.
Added the new creds
Added the NAS-based source folders back into the list
Shut down and restarted the Duplicati service (It was always the first backup run that had the error)
Ran the backup
No errors…

If you’re referring to this it was to me not from me, however regardless of who said what, CIFS and SMB are loosely referring to the same thing (version difference exist, but might not be relevant to your usage). The Difference between CIFS and SMB discusses it. Regardless, it sounds like you had some success using your second-generation solution without having to change your service user. I hope that it holds up.

Well… That success was short lived. After a restart the same error occurred.
Interesting that instead of just killing and restarting the service to see the result, it took a system restart.

I decided to try “run-script-before” and created a simple batch file to mount the source share on an available letter. This time I restarted the system before trying the backup and it seems to be OK with it.
Wrong… Not sure why It worked after the above restart but after another restart it did not work. :slightly_frowning_face:

More tinkering needed…

Seems like it would be possible for Duplicati to check in with Credentials Manager for doing this kind of stuff so the passwords do not need to be in plain text but…

The first three bullet points at the Services and Redirected Drives link hints at how boundaries between services may not exist, e.g. if they use the same context. I’m sure something else was in LocalSystem. Perhaps this is similar to the idea that a drive mapping (or lack thereof) exists outside the user process.

If you’re talking about net use you might be able to use /persistent or /savecred to save the passwords.
Net Use Command discusses this, but also keep in mind all the Microsoft caveats about drive letters…

So as a follow-up. I decided to sort of start over and tackle two things at one time.

I rather liked the idea of having the database etc in a more practical location and noted the potential issue with Windows updates trashing the service database location so using johnvk’s updated procedure at Migrating from User to Service install on Windows, I moved things and then also changed the service to run as me instead of as the Local System account.
It occurred to me that there really was/is nothing under any other accounts that is important. Or better said, being able to backup those files from the NAS is more important than backing up data from any other accounts.
Everything seems to be running normally…

1 Like