Using a SSHFS filesystem to mount a remote location (Steam Deck) to a Windows drive letter.
In Dopus 12, it worked perfectly to copy files and folders over. Now? It creates the folder, says ACCESS DENIED, but the folder IS inevitably created.
You can see the video here: https://youtu.be/O57Vab6odbY
Let me know what else I can provide. Thank you!
Try setting Preferences / Miscellaneous / Advanced: [Filesystem] copy_allow_delegation = False.
That will make Opus copy files the way it did in version 12, instead of using the method File Explorer uses. Quite strange if Opus's old method works when File Explorer's doesn't, but it's possible.
If that works, you can leave it that way, or you can set it back to True for normal file copies and make a special button for copying to SSHFS:
Copy DELEGATE=no
The DELEGATE argument lets you override the global setting for individual commands/buttons/hotkeys/etc.
Strange, not sure what else would have changed, unless the target filesystem doesn't like being asked to copy attributes/metadata/security. (Check Preferences / File Operations / Copying Files and the pages under it.)
A Process Monitor log might reveal the operation that's failing.
None of those settings helped.
Here is the applicable Process Monitor ... anything?
sshfslogfile.zip (2.4 KB)
So PURE SSH (via FTP) works fine. SSHFS is the issue - but again, doesn't make much sense since it works with File Manager too.
I guess I need to bit the bullet and uninstall 13 and go back to 12 just to make damn sure it is 13 and not something related to the Steam Deck.
Welp we can close this up. I rolled back to 12 and no change.
So the issue must be SSHFS and/or OS3.5 on the deck. Bummer.
Weird it only affects DIRECTORIES. Files are fine.
From the ProcMon log, SSH-FS is returning Access Denied when the destination directory is created.
The folder IS created, though. "Access Denied", but still worked (if you F5 after you cancel, the folder shows up).
It's ONLY folders. Files work fine. Once you refresh, and try again, anything in the folder WILL copy over.
Almost like ... a timing issue. It sends the CREATE DIRECTORY command, but the directory isn't created "yet" before the next command or "ready" or something.
Retested File Explorer and it continues to work fine (I had to wash my hands with industrial cleanser after using it though).
I found this thread that has a command (fsptool-x64.exe) you can run on the Windows side to list the permissions the SSH-FS side is giving:
Might shed a light on something.
Random thought: If Opus is running elevated and Explorer isn't, that could also be an explanation.
For anyone else who runs into this in the future - I too had the same issue when updating to Opus V13.
I noticed it with the beta version, rolled back to 12 as it was working.
I just updated to 13 full release, and the issue came right back. I too am on a FUSE mounted remote share.
Changing the copy_allow_delegation = False sorted out my issue.
Are there any other considerations I should be aware of? Any increased risk for a file copy operation not completing correctly, etc? Just want to cover my bases now, as this is a mission critical share.
Thanks! -Ian
Do you get the same error when copying in File Explorer?
When delegation is on, Opus and File Explorer copy in the same way.
Turning off delegation reverts things back to Opus’s own copy code. It’s very odd if that works when the more common method used by File Explorer doesn’t.
Turning off delegation will lose server-side offloading and sometimes be slower with some networks/devices.
No, there are no issues with native file explorer, or v12 - both worked flawlessly.
I have been troubleshooting some file transfer rate issues. I used to push nearly 900MB/sec to my TrueNAS share, but around the same time I fought the v13 beta "Access Denied" issues, I noted that it had dropped down to roughly 200MB/sec. Testing with these current changes results in the same, 200MB/s maximum.
Hey, I have tried this and it still doesn't solve my issues. Is there anything else you may have done?
I'm desperate to get this working. I tried remounting the remote drives, fully exiting and restarting Dopus.
How are you mounting the drive in FUSE?
Command line:
net use X: \\sshfs\user@machine /user:user password /persistent:Yes
That seems.. very vanilla. I'm not seeing anything that would cause concern.
My setup is more complex, with a Rclone config file, NSSM, and WinFSP.
Perhaps try having Rclone handle the mount? I'm not a pro with it, but I'm impressed by how powerful it is.
Were your problems the same? Files would write but NOT folders? With an ACCESS DENIED error?
Just a little follow up.
The issue doesn't appear to be copying; the issue literally is whatever Dopus is doing to create folders.
Forget the copy job - just asking Dopus to make a folder on the destination SSHFS mounted drive renders the ACCESS DENIED error - but oddly the folder itself IS made.
What possible difference could there be from v12->v13 and/or File Explorer->Dopus in the creation of a folder?
I tried RCLONE and it doesn't have the same issues as SSHFS. It is also about 20% faster too.
Nice ..
However, I started seeing "parameter not correct" at various times during the copy process. A RETRY cleared it right now, but doesn't seem super ... reliable ... You see anything like this?