For PS 7.2.1, the same call on Windows and Linux returned different results,

New-PSSessionOption -OperationTimeout 360000

On Windows it returned a list of params and values, with the OperationTimeout set correctly, 00:06:00.

But on Linux it failed, showing the following error:

New-PSSessionOption: A parameter cannot be found that matches parameter name 'OperationTimeout'.

What's wrong?

On Linux if I issued just "New-PSSessionOption", w/o any param, it'd return a list of params with default values, including ":OperationTimeout: 00:03:00". So, it's there in the implementation, but why can't I set it?

BTW, I was trying to copy many files, small and big in sizes, from Linux to Windows. But after the Copy-Item ran for a few minutes, it started failing with "Internal error parsing Wsman fault message...". That's why I wanted to set this timeout longer.

CodePudding user response：

Perhaps you don't need to solve your problem, considering that OperationTimeout doesn't do what its name suggests:

OperationTimeout does not impose a time limit on commands or processes running in a remote session and does not affect other remoting protocols like SSH.

In short:

• This comment on GitHub details what this setting actually controls: it is related to how long a remote machine may take to respond to a receive request, but PowerShell simply quietly retries in the event of a timeout. The tl;dr is: -OperationTimeout affects "mostly nothing". Arguably, it should never have been exposed to end users.

• Implementing an actual operation-duration timeout is the subject of GitHub proposal #5434, which suggest adding a -Timeout parameter to Invoke-Command.

As for your symptom:

• It may be a bug, because even though OperationTimeout is specific to WS-Man/WinRM, the remoting protocol used on Windows, you could still be trying to remote into a Windows machine, and the New-PSSessionOption doesn't require you to commit to a protocol - only when you call New-PSSession do you commit to a protocol, such as opting for SSH-based remoting via -SSHTransport.

• That said, since it sounds like the setting applies on the caller side, conceivably the Linux and macOS implementations of WS-Man may lack it. Generally, this implementation appears to have its problems and may not have a future - see this blog post.