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

9 hours ago, grayraven said:

Example file on my Mac:

 

-rw-r--r--@ 1 gray  staff   1751 Apr  9 15:58 TextIO.mod

 

What does the '@ 'at the end of the permissions indicate about any modifications to the normal permissions?  (It almost looks like what is seen when Windows applies ACL on a file/folders.  In the Windows case, it is a '+' sign in the same location.)

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

 

@grayraven

I did replicate this on 7.1.2 using a private share. But, after I added

[GLOBAL]

map archive = no

to smb extras in the WebUI, this behaviour did disappear. (I didn't test adding it as a via a [SHARE] section in smb-extras, but the attribute is usable within a share according to the man page)

How did you test and find that map archive (or store dos attributes) didn't fix for you? (I haven't as of yet tried store dos attributes)

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!

This appears to be more a Samba limitation, since SMB was designed for Windows:

https://unix.stackexchange.com/questions/103415/why-are-files-in-a-smbfs-mounted-share-created-with-executable-bit-set

More info below, scroll down to the File Permissions and Attributes on MS-DOS and Unix section:

https://www.samba.org/samba/docs/using_samba/ch08.html

TL;DR maybe be better to use an NFS share in your case.

I decided to have a look at my File system (because in the back of my mind was this feeling that I had seen something vaguely familiar). Here is what I found:

Notice that the Execute bit is set for the Owner an many of these files. Notice that they are mostly newer files.

Let me further state that my Networking environment is strictly a Windows one. The principle involved in transferring these files to my Unraid server are running Windows 11 Pro (23H2 and 24H2 for the time involved for the execute bit being set). Here is portion of my testparm output:

Notice the parameter I have marked. Here is the description of what it does:

Observe that the default is 'no' but for some reason Limetech has chosen to set it to 'yes'. (The short testparm output shows only those parameters which have been changed from the default.)

The point I am making is that is not only Mac OS problem but it exists in the Windows-only environment, too. I know that I would ignored it when I first noticed because Windows uses the file extension to determine if a file is executable or not.

Here is the link to the Samba document for the above screenshot:

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html

Quick test.

Set acl allow execute always = no in SMB extras. Verified that it was off.

Copied file using Windows File Manager (Win 11 Pro 24H2) to server. Execute bit still set.

Created file in an application (EditPAd Lite) on this computer and saved it directly to Unraid Share. Execute bit still set

Got out an old Win10 laptop. Created file in WordPad and saved it directly to Unraid server. Execute bit still set.

Conclusion: It appears that the problem is Samba.

It does not appear to be a problem in Windows. At least in a peer-to-peer configuration which is what most Unraid users employ.

It would be nice if someone who is running Samba on one of the standard Linux distributions (Ubuntu, SUSE, etc) and see if the problem exists there. Ideally, the test should be both ways--- (1) saving a file to Unraid using SMB and (2) saving a file to that Linux PC.

May have found the Solution: The default create mask is 0777

I changed this by adding the following setting in the SMB Extras:

create mask = 0666

This is a before-and-after test. The 'X''s are the before and the lines are the after:

I also created a Directory and it had the proper permissions on it.

Ran some tests and everything seems to be working fine.

2 hours ago, Frank1940 said:

I changed this by adding the following setting in the SMB Extras:

create mask = 0666

@grayraven , please give this a try and let me know the results. If it solves your problem, I will submit a Bug report. It should be a simple fix but I would not expect it before the next minor release. (No bug fix release for just this as it has existed for well over 18 months...)

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.mod

To 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.mod

On 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.mod

On 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.mod

The 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.mod

I 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?)

Edited May 24, 20251 yr by grayraven

This discussion about Mac is going well beyond my background. I have never used an Apple in my life. (and I am in my 80's!) I am surprised that the permissions for the 'group' and 'other' are not be created correctly when the file is copied back to the Mac. Twenty years ago I played around with Linux on a trial basis. I installed and setup Samba on that system and it was a chore. (No cookbook instructions at the time as I remember.) So I don't remember if there are settings on the client for setting the proper permissions for new files. I would also imagine that there would be settings for handling any extended attributes.

You might want to goggle @ in linux file permissions From MacOS and see if you find anything that might be of help.

I would also expect that the Archive bit would be set on the copy back from the Unraid server by your Mac. After all, it has not been backed up yet as your Mac should consider it to be a 'new' file.

About Windows. I am certain that the setting of the execute bit for the 'owner' was the result of the Create Mask setting that Unraid has chosen (0777). When it is set to 0666, things are behaving on the Windows side as they should.

EDIT: you might want to see what happens when you copy files to and from a flash drive plugged into a USB port. The old sneaker net..)

Edited May 24, 20251 yr by Frank1940

41 minutes ago, Frank1940 said:

I would also expect that the Archive bit would be set on the copy back from the Unraid server by your Mac. After all, it has not been backed up yet as your Mac should consider it to be a 'new' file.

The Mac does not have an Archive flag. The copy back just brings along the x bit meaning executable.

41 minutes ago, Frank1940 said:

About Windows. I am certain that the setting of the execute bit for the 'owner' was the result of the Create Mask setting that Unraid has chosen (0777). When it is set to 0666, things are behaving on the Windows side as they should.

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.

10 hours ago, grayraven said:

I 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.

Double check the SMB settings on your Mac. The file permissions should be control by the system writing the file not by the permissions on the source. I am not sure about the extended attributes as I have never had any occasion to use them. As I understand, they are only used with the Active Directory (AD) environment.

A quick google on my part indicates that MacOS not longer uses Samba but now uses its own SMB client. (Quick point--- SMB is both a protocol and a software suite for Windows. Both the protocol and the Software are controlled by Microsoft. Samba is a reversed engineered software for the SMB protocol.)

What happens if you setup a peer-to-peer direct connection between your Mac and your Windows computers? IF you want to see how to setup a Windows peer-to-peer, see here:

https://forums.unraid.net/topic/115125-windows-10-peer%E2%80%93to%E2%80%93peer-file-sharing-guide/

Found this:

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#STOREDOSATTRIBUTES

You might want to try it if you are still having issues.

There are four other settings that could be useful. The first is here:

https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#MAPARCHIVE

The other three are listed directly below this one.

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.

@grayraven

I could replicate this no problems originally. But, after I added

[GLOBAL]

map archive = no

to smb extras, stopped / started the array, and also disconnected the server from the Mac, the executable bit isn't being set on the server when copying a file from the Mac, and when copying it back to the Mac, the executable bit remains off

I replicated your issue on a private share, and it's fixed on the same private share. (I haven't tried on a public, but I don't see that it would make any difference)