Should I give up on SMB ... ?

1st Official Post
    • New

    When I mount a SMB share on macOS Sequoia, I see garbage filenames for some folders, e.g., _Z78J5~C. This is apparently due to SMB falling back into some DOS 8.3 compatibility mode.


    I gather this is happening because some directory names end with a "." character. However, the naming of the directories is done by an app, so I can't rename them myself without breaking it.


    I tried adding "mangled names = no" as an SMB config option, and the correct directory names do appear, but I cannot see any of the files inside the directory. ?(


    EDIT: I have searched the Net and found dozens of posts asking the same question, but with no resolution. It seems there was some very arcane solution that involved creating a custom "mangled map" but that was deprecated by Samba over a decade back.


    Is it possible to fix this, or do I need to give up on SMB and figure out NFS instead ?


    TIA

  • Borbio

    Added the Label OMV 7.x

  • Borbio

    Changed the title of the thread from “Mangled Filenames on macOS” to “Should I give up on SMB ... ?”.
    • New

    There is a configuration option on if and how to deal with 8.3 DOS file names in the SMB share configuration page. Maybe you could test different settings there.


    Other than this: is "." allowed in dir names on smb? I thought not.


    And as a wild guess: Could it be the name you see actually doesn't have to do with 8.3 per se but is a temp filename during transfer which smb would rename to the correct file name when writing the file to the fs but then fails to write the correct filename because it's containing an invalid character? If so, I would guess there is nothing you can do on the samba side as then it would be working as expected.

    • New

    Thanks for your message. I just looked again, and I don't see any such setting on the SMB share config page. What is it called, specifically?


    W.r.t. the wild guess, I would say no. This is a well-known issue with SMB. E.g.:

    https://superuser.com/question…es-from-linux-samba-share

    https://forums.raspberrypi.com/viewtopic.php?t=226647
    https://superuser.com/question…accessible-on-samba-share
    https://forums.truenas.com/t/s…why-have-i-fixed-it/10784
    ...and a dozen more similar threads.

    It sounds like some people have managed to get this to work, but I need a solution for OMV.


    I would really prefer not to go through setting up NFS — SMB is simpler — but dealing with DOS sh*te in 2025 is a deal-breaker.

    • New
    Quote from votdev

    Knowing how they solved the issue should help to solve the issue for OMV.

    Yes, I wish I knew. From reading several dozen threads on this (e.g., above), I find some people say that adding "mangled names = no" as a SMB config option worked for them, but some others say that all it does it show the directory names properly, and the files inside the directories don't appear.


    I tried this on OMV and my experience was the latter. So, I haven't found any solution that works with OMV.


    There are a dozens of config settings for SMB. One of the main reasons I started with OMV in the first place was so that I wouldn't have to d*ck around with them.


    If I have to get into trial-and-error fiddling with SMB config settings... what's the point of using OMV?


    I might as well just go back to using SMB with Webmin like before, except that was a nasty experience — performance was bad, connections were janky, etc. — and thus my original question:

    Should I bail on SMB, because it's always going to hobbled with DOS-era limitations, or is there a solution?

    • New
    • Official Post

    Maybe you should ask the question if the problem isn't MacOS Sequoia. I have no problems with Samba from my Linux and Windows clients.

    Quote from Borbio

    If I have to get into trial-and-error fiddling with SMB config settings... what's the point of using OMV?

    You're right, it should work out-of-the-box for most scenarios. But this cannot happen if the community does not actively participate in the discovery and elimination of bugs. I don't have a Mac, so I can't do anything in that direction to fix problems.

    • New
    Quote from Borbio

    Thanks for your message. I just looked again, and I don't see any such setting on the SMB share config page. What is it called, specifically?

    My bad. I know i have seen a related conf option recently since I'm also dealing with a samba issue atm. But obv. i mixed it up, it must have been somewhere else than OMV as I also can't find it in OMV where I thought I have seen it. Sorry for the wrong direction.

    That said, it might have been in a smb.conf file as i also was setting up samba ootb on the different host to do my tests and bebugging on my smb issue. I'll keep it in mind in case i should see it again.

    • New
    Quote from votdev

    Maybe you should ask the question if the problem isn't MacOS Sequoia. I have no problems with Samba from my Linux and Windows clients.

    You're right, it should work out-of-the-box for most scenarios. But this cannot happen if the community does not actively participate in the discovery and elimination of bugs. I don't have a Mac, so I can't do anything in that direction to fix problems.

    Many ppl do say the macOS client has problems. All the discussions I've seen, though, suggest the work-around happens on the SMB side, because it's sending mangled DOS filenames to the client.


    Point taken about community participation. If I learn anything I will definitely share it here.

    • New

    My experience with samba is, the problem often lies in not fully compatible implementations on client- and server-side.

    Which was quite common 20+ years back (samba is quite old and a lot of libaries out there in there core seem to origin from way back). Just think about the mess with html and css handling in the early web browser days - same site, different browser, very different layout. That was the same back with the first digital telephony protocols - each vendor implemented his very individual interpreation of the standard.

    • New
    Quote from eightbit

    My experience with samba is, the problem often lies in not fully compatible implementations on client- and server-side.

    That could be the issue with macOS, tho the question remains: is there a work-around?

    Some further data points:


    (1) If I add mangled names = no as a SMB config option and then reboot, now SMB appears to work from macOS, showing me expected directory names instead of mangled ones, tho if I create a folder named Test. on the SMB share, it looks correct from the mac side, but on the Linux SMB server the file is named Test, with unprintable 0xEF 0x80 at the end.


    Having differently-encoded filenames on macOS and Linux, and unprintable filenames on the Linux side — this is a deal-breaker for me.


    (2) I also tried dos charset = UTF-8 as a SMB config option, but then testparm -v | grep "dos charset" reports an error:

    ERROR: invalid DOS charset: 'dos charset' must not be UTF8, using (default value) CP850 instead.


    It seems that CP850 was later replaced by Windows-1252, then UCS-2, and finally UTF-8.


    So, my only guess the mangled filenames are being sent in the legacy CP850, and then it is somehow the client's responsibility to ask for its non-legacy representation, but the macOS SMB client isn't doing this.

    • New

    I work in the film and tv post production industry as the IT tech in a post production facility. As such I have to deal with several versions each of macOS, Linux, and Windows.


    From my experience, samba works as expected between any combination of linux and windows systems. Mac on the other hand is a different beast. In comparison to the others, Apple allows macOS to use any character in a file or directory name, even when they are illegal characters on every other OS. As I'm sure you are aware by now, as a general rule of thumb, you should never use any kind of punctuation or strange characters in a file or directory name if you want the files to be represented correctly by any OS.


    This can cause all kinds of problems from the unprintable characters you mentiond to files or directories being completely invisible. We quite ofte get files from mac users that will not even be visible on our linux and windows systems and have even had some that will crash a program until we find them and rename them.


    Even the apple samba implementation is not compliant with the rest of the OS versions, offering much slower and unstable performance from my experience. This has resulted in the addition of some samba vfs_fruit options to try to make it more compatible with macOS. It might be worth your while to look into those to see if they help. Some can be set via omv environment variables so they get automatically applied to all shares.

    • New

    Thanks. I tried enabling vfs_fruit, but it doesn't seem to behave any different than mangled names = no.


    More specifically, adding this to the SMB settings for OMV:


    fruit:aapl = yes

    ea support = yes

    vfs objects = catia fruit streams_xattr

    fruit:resource = file

    fruit:encoding = native


    Restarting the SMB server via OMV, and rebooting the mac client. No change.


    FWIW, I'm not asking for full macOS filename support (see above), only Linux filename support on a mac share (the OMV instance is running on a Debian box). SMB is running on a Linux machine, but it is scrambling legal Linux filenames into something weird.


    That is, unless I enable mangled names = no or add these options for vfs_fruit, the Linux filenames with trailing dots — a legal filename on Linux and macOS — won't be displayed correctly for the Linux share. And then, even when mangled names = no, there is still some weird mangling happening. I.e., a trailing . is fine on both Linux and macOS, but SMB is nevertheless doing something strange to the filename, mapping . to 0xEF 0x80. AFAIK, both macOS and Linux use UTF-8 internally, and a filename with a trailing dot is legal on both of them.


    Why does this matter?


    Let's say you have a media or music player app and it organizes albums in directories under the name of the band. The player app uses OMV to store the music. So, it expects a directory R.E.M. for the band named R.E.M. This is a legal filename on both Linux and macOS, but SMB scrambles it, as described above, such that one name is presented to the mac and another appears on the Linux volume.


    Needless to say, this is a problem for the music player app, which then fails to find a band named R.E.M0xEF 0x80.


    EDIT: Looks like I spoke too soon about "no change". Enabling vfs_fruit has changed the creation and modification dates of every folder on my SMB shares, and they are now mostly all the same. I have no idea what the logic is behind this but it's undesirable. So, I've disabled vfs_fruit.

    • New

    The vfs_fruit options are supposed to make samba more mac compatible. There is more than just the vfs_fruit option you enabled.

    Here are some recommendations from a samba wiki

    Configure Samba to Work Better with Mac OS X - SambaWiki


    That said, it is also governed by the samba versions being used and and stuff apple has modified.


    I can confirm that folders with a trailing dot made on OMV/Debian (Samba 4.17.12) linux are garbled on a mac, but ones without the trailing dot are fine. Ones made without a trailing dot on a mac also show fine on linux, but when a trailing is used it is misinterpereted on linux. I would assume that this is related to a trailing dot made by a mac is expecting something after it as an extension.


    Rocky Linux 8 (rehat based) using samba 4.19.4 behaves the same way, so it is consistent across more than one samba version.


    In both cases I have all the appropriate vfs_fruit options enabled.


    I don't have a samba solution for you if you have software that is making folders like this and it is out of your control. It is something that would have to be hashed out with the samba project that makes it's way into the various os versions, and would only likely be fixed in newer linux os versions as Apple puts their own twist on samba.


    You could try setting up your shares using netatalk ( https://netatalk.io ). It is an opensource variant of the apple AFP protocol. Apple has pushed everyone to use samba, but they still support the old afp protocol the last I checked. It may get you around the problem and it performs faster than apple samba. There are also docker containers for it if i recall correctly so it can be implemented directly on OMV (OMV used to have a plugin for it, but you would now have to use the docker or chance that a direct install wouldn't break your OMV.

  • Borbio

    Added the Label resolved

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login