I'm trying to figure out why a specific behavior is exibited when perms change on a file being saved from a Windows editor on a SAMBA-mounted Unix partition.


  • We have a file on Unix, with 777 permissions:

    -rwxrwxrwx 1 testuser users 4859 Jan 23 15:09 fbparser.pl*

  • The directory where the file is located is mounted from a Windows 7 PC, via Samba.

  • We open the file for editing in either "Notepad++" or "Sublime" editors.

  • When the file is changed and saved, on the unix side the permissions change to:

    -rw-rwxrwx 1 testuser users 4859 Jan 23 15:09 fbparser.pl*

Now, I suspected that it may NOT be due to Samba mount, because the same problem DOES NOT occur when opening and saving the file in regular Windows Notepad!

Therefore, my initial thinking was that this was because the programming editors mentioned above may be set up to - instead of simply saving the file - to rename the original file to $orig_filename.bak and then save the new content as NEW file with the original filename. This is based with my own prior experience of the same problem using UltraEdit editor.

However, if that is the reason for perms changes, I am at a loss to explain two OTHER symptoms I observed:

  • First off, there is no backup file being created in the first place.

  • Second, when creating NEW files (using touch) in the same directory in Unix Shell, the perms for the new file are NOT -rw-rwxrwx at all.

  • Third, if it matters, the inode # for the file remains the same after the edit.

What else could be the problem and what steps can I take to investigate it?

My own UltraEdit problem went away when I told UE to NOT back up the file by renaming; however Notepad++ doesn't have such an option.

2 Answers 2


I found this question while trying to resolve a very similar problem. The solution in my case was to add map archive = no to smb.conf's global section.

The underlying problem is the way that Samba maps permissions across from Dos to Linux.

It seems that when notepad++ saves a file it is setting/resetting the dos file "archive" attribute. By default Samba uses this to manage the execute attribute for user permissions on a file.

So, if you set the Samba parameter:

map archive = no

The attribute is not mapped and user execute permissions are retained as per what they were set to previously.

  • thank you so much. This saved me from being crushed via infuriation.
    – Krista K
    Commented Sep 30, 2014 at 19:41

I had the same situation. For me helped changing create mask parameter in smb.conf file.

create mask = 0600 ->  create mask = 0700

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .