I've encountered at least two frustrating issues upon trying to connect to a new SMB server with the iOS files.app (main menu (...) -> connect to server).

This is with iOS 15.3 (latest as of writing); these issues were definitely also experienced with older iOS versions.

Issue 1: "The operation couldn't be completed: Operation not supported"

This happens with a server configured to restrict itself to SMB3 and above (SMB3, after all, has "only" been around since 2012).

Server logs report smth along the lines of:

smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_NOT_SUPPORTED] || at ../../source3/smbd/smb2_negprot.c

Issue 2: "The file couldn’t be saved because a file with the same name already exists"

I've hit this issue a number of times, typically when migrating from an old SMB server to a new one.

The same issue was raised on Apple's forums with a fair number of "me too's" but no workable solution has been provided...

Question: are there any workarounds/fixes to these files.app "quirks"?

3 Answers 3


In order to fix both issues optimally, you'll need (admin) access to your SMB server configuration; although a workaround exists for Issue 2 if you don't.

Issue 1

Although files.app appears to perform most of its traffic over the SMB3 protocol, some initial connection activity only appears to work if the server accepts SMB2 requests. This requires adjusting the server's configuration (see below).

Issue 2

Solution 1: delete old/clashing "server" connection

Deleting a connection to a previous server that provides a share with the same name (files.app -> main menu (...) -> connect to server -> (i) -> Remove) solves the issue.

This may be a workaround in case you don't have access to the server config although you'll only be able to access one of the "clashing" servers/shares at a time, which could be frustrating.

Solution 2: ensure unique SMB share name across servers

A better workaround is to ensure that the name of the SMB share is unique across the connections stored/remembered in your files.app. In my case, the standard configuration of my servers was to call them smth like smbshare; attempting to access more than one server with the same share name, causes the issue, which looks like a bug in files.app IMHO (the share names should be qualified by the server name).

How to adjust a SMB server's config to solve both issues

The below procedure and example are based on Ubuntu but they should work similarly on other *NIX/*BSD derivatives (and NAS) that use Samba as the SMB server software, albeit possibly with different paths/filenames etc:

  1. Logon to your SMB server and run sudo -i to access root privileges.
  2. Edit /etc/samba/smb.conf
  3. For issue 1, you'll want to ensure server min protocol (typically found in the [global] section) is set to SMB2.
  4. For issue 2, locate the name of the share (placed between brackets; in my example [smbshare]) and change it to smth unique. For example, by including the host name, which can be stubbed as %h if you like to keep your config files standardized.
  5. systemctl restart smbd

A sample smb.conf that works for the iOS files.app

Here's an example smb.conf that works well with iOS files.app and strives to be reasonably secure (SMB is a well known attack vector!). Feedback - particularly if it improves security - is welcome.

        server string = %h
        server role = standalone server
        interfaces = lo eth0
        bind interfaces only = yes
        disable netbios = yes
        smb ports = 445
        log file = /var/log/samba/smb.log
#        log level = 3
        max log size = 1000
        map to guest = bad user
        smb encrypt = required
        server min protocol = SMB2
        client min protocol = SMB3

        valid users = MY_SMB_USER
        path = /home/MY_SMB_USER/SHARE
        available = yes
        browseable = yes
        read only = no
        force create mode = 0660
        force directory mode = 2770
  • [%h] uses the server name as the share name, which solves issue 2 single-handedly. It just needs to be smth unique to workaround file.app's rather shocking bug.
  • log level = 3 (or above) is useful to increase verbosity of logs to troubleshoot issues.
  • You'll need to adjust interfaces = and MY_SMB_USER to suit your circumstances (ip link show is your friend to discover your interfaces' names). interfaces restrictions can be left out but this is definitely not recommended on a machine directly facing the Internet.

Note on server OS

Even though the examples above refer to an Ubuntu SMB server, the same issue(s) appear to exist with Windows servers (so the bugs appear to be in the iOS files.app), as evidenced by the Apple forums question linked in the question.

  • Thank you for your answer! Downgrading server min protocol from SMB3 to SMB2 solved my problem on iOS / iPadOS 15.4.1! Please note that my original SMB3 setting worked properly on macOS Monterey, so I expected it to work on iOS, but it did not. Yucks! Commented May 22, 2022 at 18:58
  • does downgrading server min protocol impact security ?
    – demon36
    Commented Aug 1, 2022 at 20:55
  • @SiuChingPong-AsukaKenji- Please read my post below
    – Thanasis
    Commented Dec 5, 2023 at 19:51
  • 1
    @demon36 Yes it does create a strange situation. I gave an answer below
    – Thanasis
    Commented Dec 5, 2023 at 19:52
  • Thank you, resolved by "Solution 1: delete old/clashing "server" connection"
    – Rajeev
    Commented Feb 4 at 21:17

In order for the iOS "files" app to work on an encrypted Samba server, user @sxc731 suggested to downgrade the server min protocol to SMB2. He claimed that "some initial connection activity only appears to work if the server accepts SMB2 requests".

Overall he suggested the 2 lines in Linux Samba server's smb.conf file:

    server min protocol = SMB2
    client min protocol = SMB3

While the above settings seem to work, they raise the security questions of the unencrypted SMB2 protocol version.

What I figured out was that, Apple's Files app on iOS still uses an old Samba version (protocol version SMB3_02) and this can easily be identified by running the "sudo smbstatus" command on your Linux Samba server.

When you set your Samba on "server min protocol SMB3", by default SMB3 selects the SMB3_11 variant (source samba_docs). But iOS is still using the old SMB3_02 protocol version, which at least offers some security.

Therefore the problem of a not working Samba in iOS "Files" app can be more accurately nailed down with the right Samba version used by client, like:

    server min protocol = SMB3_02
    client min protocol = SMB3_02

The following line will work too.

    server min protocol = SMB3_02

I think this is a more accurate answer.

Now you can enjoy fully encrypted Samba shares on Windows, Linux, macOS and iOS.


All I did was add this line on the file smb.conf.

vfs objects = fruit streams_xattr

Under [global]

You must log in to answer this question.

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