Hi everyone, for the last couple of weeks (months?) I've been trying to solve this weird problem I'm having with one of my iOS apps I'm using, Cryptomator, to access encrypted vaults on the server.

 

All details are in this GitHub issue: https://github.com/cryptomator/ios/issues/265 But the TL;DR is the app cannot identify a vault on unRAID's SMB implementation only. (Or it's a configuration issue with one of the SMB config options in unRAID, but I can't figure out what.)

 

Basically, the bug occurs when adding an existing vault – the Cryptomator app requests the directory listing from the iOS File Provider, which returns a list of files within the directory that the user chose, indicating that it is a vault. The problem is that when choosing a vault on unRAID, the file provider returns nothing, and the app bugs out because it wasn't returned anything. This is in spite of the fact that the user has access and the necessary permissions to read/write to the share, and also in spite of the fact that I can actually see the vault files listed inside the iOS Files app.

 

To verify that this was a unRAID specific issue, I spun up a Debian VM and installed Samba on it and tried to reproduce the problem on that but it worked without a problem.

 

So something on my unRAID server is causing the incompatibility with Cryptomator, but I can't figure out what. My SMB extras configuration is empty. This is what my SMB config page is set to:

 

 

The only change I have regarding SMB is the recycle bin plugin.

 

I've tried transplanting the configuration options from unRAID to the Debian server to try and break compatibility there, but have so far been unsuccessful.

 

What is the difference between unRAID's Samba config and a vanilla Debian install's Samba config? Can anyone try out the Cryptomator app to see if they have a similar problem adding an existing share on an unRAID vault?

Is the User Share set to Public access in SMB Security?

10 minutes ago, trurl said:

Is the User Share set to Public access in SMB Security?

All the shares I tested with were set to Private access, but I just tried with a dummy share set to Public and it still didn't work.

Figured out the problem: the "Enhanced macOS Interoperability" setting was causing the issue. Turning it off fixed it. What Samba configurations does this option add?

Hi,

 

I still have the issue with the files app on iOS 17.x and I just wanted to disable the "Enhanced macOS interoperability" setting. But since I am running a virtual pfSense on the unRAID server I a have a dead-lock situation: I cannot stop the array to change the corresponding setting within the Web UI without loosing the connection to my server. So I tried to disable this setting via the command line by modifing the /etc/samba/smb.conf and reboot the server. Unfortunately the configuration file is generated somewhere else during boot process and I just cannot find out where.

 

Can someone give me a hint please? Or is there another workaround to disable the "Enhanced macOS interoperability" setting for testing in my situation?

4 hours ago, cup089 said:

Enhanced macOS interoperability

 

Can't tell you how to get around shutting down the array, but I can tell you with good certainty that setting isn't going to fix nor solve any issues for you. Pretty sure it's not the same issue the OP had. And generally speaking that setting hasn't made much difference for my testing.

 

If you want great (not simply good or decent) SMB performance with MacOS, iOS and generally all clients, you need to make sure your shares have exclusive access enabled and are on a Pool, not the Array.

With regards to pfSense, I also virtualize on Unraid, but I keep that on its own system so it's never affected by shares nor containers I use/test. Just food for thought. A nice N100 works well for that.

19 hours ago, Espressomatic said:

 

Can't tell you how to get around shutting down the array, but I can tell you with good certainty that setting isn't going to fix nor solve any issues for you. Pretty sure it's not the same issue the OP had. And generally speaking that setting hasn't made much difference for my testing.

 

If you want great (not simply good or decent) SMB performance with MacOS, iOS and generally all clients, you need to make sure your shares have exclusive access enabled and are on a Pool, not the Array.

With regards to pfSense, I also virtualize on Unraid, but I keep that on its own system so it's never affected by shares nor containers I use/test. Just food for thought. A nice N100 works well for that.

 

Thanks for your comment. Then I will give the exclusive access a try.

 

What do you mean with "keep that on its own system" regarding the virtualized pfSense? I also use the pfSense with a passthrough Quad NIC on unRaid and the VM is sitting on the cache drive and not the array. So It should also not affected by such settings which requires to stop the array. But probably the cache drive also belongs to the array...

I mean a completely different computer. I have a small mini PC powered by i5-1235U running Unraid for Edge Router use. It takes care of my pfSense VM, plus Nginx Proxy Manager, AdGuard Home, Tailscale local Exit node, etc. I also have another mini system on N100 with Unraid running all my Home Automation stuff. That means I can play with other Unraid systems without ever taking down those critical services (internet access and home automation).

Ok thanks for the clarification.

 

However I do not think that the exclusive share option is the right one I need. According the explanation:

 

Quote

 

If set to Yes, share directories under /mnt/user are actually symlinks to the share directory on a storage volume provided the following conditions are met:

The Primary storage for a share is set to a pool.

The Secondary storage for a share is set to none.

The share exists on a single volume.

The share is not exported over NFS.

The advantage of exclusive shares is that transfers bypass the FUSE layer which may significantly increase I/O performance.

 

 

This is not what I want to achieve.

Short Update:

 

Tried to disable the "enhanced MacOS compatibility" after that you have only read only access to the SMB shares. Then I tried several other things like described here: https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X

Unfortunately this also does not have any effect. In the meanwhile I updated to iOS 18.1.1 and the files app is still not able to communicate correctly with the SMB shares.

 

So I give up and stick to GoodReader, a PDF editor and files management app, which I have bought several years ago at a time where the files app was not even released. GoodReader has no issues at all no matter which MacOS specific setting is set.