Old Macos cannot see SMB/CIFS content in OMV7

How is the smb Protocoll setting in OMV?

I don't know exactly but I think its smb 2 or 3 as default minimum

Have a look at Services -> SMB -> Settings in the omv gui

I think this ha to be answered by an omv/smb expert.

And I just know, that smb1 is depreciated for security reasons.

Maybe you could invest on upgrading your iMac to a newer macOS release supporting smb 2/3.

If there is no higher release supported by Apple for your iMac then invest in getting knowledge about OCLP

Supported Models | OpenCore Legacy Patcher

I would have to have a look at some Mac tuned SMB settings I have done on a remote server, but if I recall correctly, it is not just the SMB level you have to account for. It’s also the password encryption versus plain text passwords.

Samba level allows it to see the server. Password encryption allows it to log in.

Those options can be specified in the extra settings field of the samba share. You can find all the samba settings by clicking the link to the samba manual just below the extra settings option.

Quote from aldobranti

Only by setting it to SMB1 ( highly deprecated) can I get the Mac to see the OMV host

This is (probably) the only solution. Mac OS 10.6 (Snow Leopard) came out in 2009 - 15 years ago. SMB2 was introduced, by Microsoft in 2006 but it wasn't widely adopted, outside of the Windows circle, for a few years. In essence, Mac OS 10.6 probably shipped with SMB1. It's possible that SMB2 might have been a package upgrade for OS 10.6 but that would assume that your Mac was kept fully up-to-date until support was suspended roughly 12 years ago.

If you find the use of SMB1 to be disturbing, it might be best to upgrade the Mac.

as far as I know smb1 was depreciated by Apple some point in time - it could be that this is the reason why Finder will not show any content.

Another reason could be the smb-server/share parameters. W/o setting the right parameters (even with smb3) I can observe somehow similar behaviour as you -> connection (or even not) and no content.

Have a look here for some more information: https://lisanet.de/openmediava…mb-fuer-macos-optimieren/

Maybe you'll have to use google-translate - and don't hesitate to get in touch with the author - she's an smb/mac expert

Quote from aldobranti

Upgrading the Mac would be the last thing on my mind, but I find that I can get AFP running here with Docker on the OMV hardware -- as you can see I get a recent NetaTalk image

Code

docker run -d --rm --network host --cap-add=NET_ADMIN --volume /srv/dev-disk-by-label-SomeDisk/aDirectory:/mnt/afpshare --volume "/var/run/dbus:/var/run/dbus" --env AFP_USER=xxxx --env AFP_PASS=xxxx --name netatalk netatalk/netatalk3:latest

You can probably also get nettalk working natively by manually installing and configuring it. Older OMV versions before OMV6 used to have it available as a plugin. I manually installed it on OMV6 to test performance, so if it is still in the debian 12 repo it should still work.

Thanks to those who shared ideas here.

FWIW here is a knowledge capture of my experience with this topic.

I had an old physical MacBook Pro laptop running OSX 10.6.8 Snow Leopard that I dusted off to check some OS X sparse bundle volumes, and tried to connect to an omv 7 instance. The authentication was successful but Finder did not list any files. The same issue OP reported. I tried turning on all versions of the SMB protocol on the omv instance but that didn't seem to help.

SMB workaround: using the cli (Terminal App) smbclient --user theuser //omv.domain.lan/sharename to connect to the share did work and I was able to list files.

NFS workaround: via Finder using the "Connect to Server" option nfs://omv.domain.lan/export/sharename and this worked on the old OSX 10.6.8. 👍 A new Finder windows opens and the share contents is listed as expected.
Note the importance of including export path component.
Note 🔐 NFS doesn't use user/pass credentials and instead limits the networks/hosts than can connect to the share, so this is somewhat less secure than smb/cifs.

Related research

I did a quick look at the tcpdump from the OSX client to the omv instance when trying to establish the smb/cifs connection and saw it was using NT LM 0.12 dialect which is related to SMB1. In the omv diagnostics for SMB/CIFS the OSX client was listed as being protocol version NT1

I did a bit of research online to see if there are some fruit specific settings for OSX to fix this issue but didn't yet find a solution.I'd be happy to hear from anyone who might have insights on smb/cifs compatibility options for legacy OSX clients.

As a side note, I was able to create an OSX 13.7.3 (Ventura) kvm instance on a proxmox hypervisor. As expected, this version of OSX worked fine with omv 7 and reported to use SMB3_11. I followed this guide: https://computingforgeeks.com/…-run-macos-on-proxmox-ve/

---

A note on netatalk package on Debian. It looks like it fell out of Bookworm because of lack of maintenance but its now back in the next release (Trixie) which is currently the testing release.

related: https://github.com/Netatalk/ne…iscussioncomment-10982398

I looked at adding Debian testing to an omv7 instance and installing netatalk but I wasn't ready to upgrade glibc. So I've paused that approach. Another negative with using AFP is that omv doesn't have a native module for managing AFP/netatalk service+shares. Maybe that comes back in omv 8 with Trixie?

Quote from kyle0r

A note on netatalk package on Debian. It looks like it fell out of Bookworm because of lack of maintenance but its now back in the next release (Trixie) which is currently the testing release.

related: https://github.com/Netatalk/ne…iscussioncomment-10982398

I looked at adding Debian testing to an omv7 instance and installing netatalk but I wasn't ready to upgrade glibc. So I've paused that approach. Another negative with using AFP is that omv doesn't have a native module for managing AFP/netatalk service+shares. Maybe that comes back in omv 8 with Trixie?

With nettalk out of the mix for now as a native option, you could run it as a docker. It will mean a little more configuration but it should be doable.

https://hub.docker.com/r/netatalk/netatalk