grayraven

Thanks, @Frank1940 as I wrote in my original post, I had tried store dos attributes = yes as well as map archive = no, to no avail. I still have to test with other SMB servers, such as a Windows shared folder, a Mac shared folder, and I have OpenMediaVault running on a Raspberry Pi.

The Mac does not have an Archive flag. The copy back just brings along the x bit meaning executable. Unfortunately not. As described, even with create mask = 0666, if I unset the Archive flag for a file on WIndows, then copy it to the share, and list the share from Windows, the Archive bit is "seen" as set there, even though when listed on the server, the x bit is not set, just as with the Mac. Apart from the potential security risks with arbitrary files being executable, this behaviour renders Unraid SMB shares as they work out of the box practically unusable for software development work, since git will perceive the x bit as change. I assume it's the same on Linux? There must be a solution for this problem, I am pretty sure I am not the first to encounter this with Unraid. :-) I have searched for possible solutions, and the suggestions found have not worked. But then again, Samba has soooo many config parameters, with dependencies among them, it's impossible for me to figure this out, since I lack the corresponding experience and knowledge.

Thanks, @Frank1940 . I have now run the following sequence of steps. The test files on my Mac: -rw-r--r--@ 1 gray staff 9497 May 1 10:03 Memory.mod -rw-r--r--@ 1 gray staff 4513 May 1 10:03 Watchdog.modTo get a baseline, with all SMB extras removed, I have copied Memory.mod to the test share (public). When viewed from the Mac shell, I see: gray@alphonse ~ % ls -l /Volumes/test -rwx------ 1 gray staff 9497 May 1 10:03 Memory.modOn the server: root@aldabra:~# ls -l /mnt/main/test -rwxrw-rw- 1 gray users 9497 May 1 10:03 Memory.mod*Now, setting SMD extras to create mask = 0666, then copying Watchdog.mod to the share. From my Mac shell: gray@alphonse ~ % ls -l /Volumes/test total 78 -rwx------ 1 gray staff 9497 May 1 10:03 Memory.mod -rwx------ 1 gray staff 4513 May 1 10:03 Watchdog.modOn the server (v7.1.2): root@aldabra:~# ls -l /mnt/main/test -rwxrw-rw- 1 gray users 9497 May 1 10:03 Memory.mod* -rw-rw-rw- 1 gray users 4513 May 1 10:03 Watchdog.modThe ultimate test, ie. copying the files back to the Mac: gray@alphonse [~:115]> ls -l /Users/gray/Check total 64 -rwx------@ 1 gray staff 9497 May 1 10:03 Memory.mod -rwx------@ 1 gray staff 4513 May 1 10:03 Watchdog.modI have done the same tests from Windows 11, with the equivalent results, ie. the Archive flag behaving exactly as the x permission bit on the Mac: cleared the Archive flag on Windows before copying to the share, but it's always "there" when listed on the share from Windows and when copied back, but apparently correct when viewed on the server, ie. the Xbit not set when listed on the server. I have also tried with the macOS compatibility setting off, with no change. (How do I get rid of the "Plain Text" thingie in the code box?)

I just repeated the test again with your proposed configuration, to no avail. My "test" is to copy a source text file on my Mac, which does not have the x permission set, to an SMB share (both public and private tested), and list the file on the share from my Mac terminal shell, where I see the x bit set. Then I copy the file back to my Mac, and now the x bit is set there as well, as listed in the terminal shell. FWIW, the equivalent happens on the Windows side: I remove the Archive bit on the local disk, copy the file to the share, and there the Archive bit gets set (checked via Explorer > Properties), again visible as x bit on the Mac. Here's the [global] output from 'testparm' run in the root terminal shell in the Unraid WebUI: [global] bind interfaces only = Yes disable netbios = Yes disable spoolss = Yes interfaces = 192.168.68.102/24 127.0.0.1 load printers = No logging = syslog@0 map to guest = Bad User max open files = 40960 multicast dns register = No ntlm auth = ntlmv1-permitted null passwords = Yes passdb backend = smbpasswd printcap name = /dev/null security = USER server min protocol = SMB2 server signing = if_required server string = NAS show add printer wizard = No smb1 unix extensions = No fruit:nfs_aces = No idmap config * : range = 3000-7999 idmap config * : backend = tdb acl allow execute always = Yes aio read size = 0 aio write size = 0 create mask = 0777 directory mask = 0777 hide dot files = No include = /etc/samba/smb-shares.conf invalid users = root map archive = No use sendfile = Yes wide links = Yes Thanks!

The '@' indicates the presence of extended attributes; % xattr TextIO.mod com.apple.provenance Removing the attribute... % xattr -d com.apple.provenance TextIO.mod ... results in (on the Mac): -rw-r--r-- 1 gray staff 1751 Apr 9 15:58 TextIO.mod Which does not change the behaviour described. Copied anew to the share, as listed from my Mac: -rwx------ 1 gray staff 1751 Apr 9 15:58 TextIO.mod

I use macOS as well as Windows for software development. Unfortunately, copying a source text file from macOS to a public share adds the executable bit, and copying back then leaves the file executable. The executable bit is tracked by git, so this is a no-no. I am aware of the DOS attributes mapping mechanics in SMB. However, setting either store dos attributes = yes which should disable the mapping (and is the default), or map archive = no does not make a difference. Basically, I don't want any mapping of DOS attributes to Unix permissions (and reverse), to and from macOS and Windows. Unfortunately the sheer number of config parameters for SMB/Samba is dauntingly overwhelming... What settings on the server and/or client side would give me the required behaviour? Thanks! Example file on my Mac: -rw-r--r--@ 1 gray staff 1751 Apr 9 15:58 TextIO.mod When copied to the share, as listed from my Mac: -rwx------@ 1 gray staff 1751 Apr 27 15:28 TextIO.mod Copied back to my Mac: -rwx------@ 1 gray staff 1751 Apr 27 15:29 TextIO.mod On the share, via the graphical admin console UI (browser): TextIO.mod gray rwxrw-rw 1.75 KB 2025-04-27 On the share, via the console terminal (browser): -rwxrw-rw- 1 gray users 1751 Apr 27 15:28 TextIO.mod* The SMB share: [test] path = /mnt/user/test comment = browseable = yes # Public public = yes writeable = yes case sensitive = auto preserve case = yes short preserve case = yes vfs objects = catia fruit streams_xattr fruit:encoding = native All SMB/Samba configs are unchanged as initially installed. Unraid v7.0.1, macOS 15.4.1, Windows 11