1

An odd issue here after an upgrade from High Sierra to Catalina. When I try to copy files from an SMB network share in the Terminal (bash and zsh), I get:

$ cp /Volumes/share_name/path/file.ext  ~/Documents 
cp: /Volumes/share_name/path/file.ext: Operation not supported

When I try to copy the same file via Finder, I get "The operation can't be completed because it isn't supported":

screenshot

I've tried to execute this with sudo and I've tried to repair user permissions (user ID is501, so: sudo diskutil resetUserPermissions / 501) and the same results.

Important to note: Other systems with Catalina work just fine with the same SMB share.

Improve this question
6
  • That type of error is usually a file permission (user) error on the SMB share. What SMB version is that server running? Is there a valid user account on the server? Are the permissions set correctly?
    – Allan
    Sep 3, 2020 at 18:04
  • Does this answer your question? ls: : Operation not permitted - Mojave security?
    – anki
    Sep 3, 2020 at 18:11
  • @Allan as noted in the body, this does work fine on other systems - that means that this same user account with the same auth info works 100% fine on other macOS Catalina (and Mojave) installs. It's a Windows 2019 Server.
    – ylluminate
    Sep 3, 2020 at 19:43
  • @anki unfortunately no: SIP was (is) already off. Additionally with Terminal.app added to Full Disk Access it behaves the same way, ie: with failure.
    – ylluminate
    Sep 3, 2020 at 19:44
  • @Allan let me qualify this further after doing some more testing: it appears as though while other systems are able to copy just fine on the same share, I AM able to mount macOS SMB shares and copy to and from those fine. It does appear that this is some strange interaction between Windows 2019 Server and Catalina - but it doesn't really make sense since other macOS Catalina systems DO interact without issue. Maybe some kind of an SMB client setting that's wonky for this specific machine?
    – ylluminate
    Sep 3, 2020 at 20:04

1 Answer 1

Reset to default
4

It turned out that the problem was actually an existing /etc/nsmb.conf. When this was removed the SMB client behavior returned to normal in this regard. Within it, the previous user had defined:

[default]
signing_required=no
protocol_vers_map=1
Improve this answer
1
  • 2
    Glad you got it all sorted out!
    – Allan
    Sep 3, 2020 at 20:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .