How to create a Samba share that is writable from Windows without 777 permissions?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
17
down vote

favorite
7












I have a path on a Linux machine (Debian 8) which I want to share with Samba 4 to Windows computers (Win7 and 8 in a domain). In my smb.conf I did the following:



[myshare]
path = /path/to/share
writeable = yes
browseable = yes
guest ok = yes
public = yes


I have perfect read access from Windows. But in order to have write access, I need to do chmod -R 777 /path/to/share in order to be able to write to it from Windows.



What I want is write access from Windows after I provide the Linux credentials of the Linux owner of /path/to/share.



I already tried:



[myshare]
path = /path/to/share
writeable = yes
browseable = yes


Then Windows asks for credentials, but no matter what I enter, it's always denied.



What is the correct way to gain write access to Samba shares from a Windows domain computer without granting 777?










share|improve this question

























    up vote
    17
    down vote

    favorite
    7












    I have a path on a Linux machine (Debian 8) which I want to share with Samba 4 to Windows computers (Win7 and 8 in a domain). In my smb.conf I did the following:



    [myshare]
    path = /path/to/share
    writeable = yes
    browseable = yes
    guest ok = yes
    public = yes


    I have perfect read access from Windows. But in order to have write access, I need to do chmod -R 777 /path/to/share in order to be able to write to it from Windows.



    What I want is write access from Windows after I provide the Linux credentials of the Linux owner of /path/to/share.



    I already tried:



    [myshare]
    path = /path/to/share
    writeable = yes
    browseable = yes


    Then Windows asks for credentials, but no matter what I enter, it's always denied.



    What is the correct way to gain write access to Samba shares from a Windows domain computer without granting 777?










    share|improve this question























      up vote
      17
      down vote

      favorite
      7









      up vote
      17
      down vote

      favorite
      7






      7





      I have a path on a Linux machine (Debian 8) which I want to share with Samba 4 to Windows computers (Win7 and 8 in a domain). In my smb.conf I did the following:



      [myshare]
      path = /path/to/share
      writeable = yes
      browseable = yes
      guest ok = yes
      public = yes


      I have perfect read access from Windows. But in order to have write access, I need to do chmod -R 777 /path/to/share in order to be able to write to it from Windows.



      What I want is write access from Windows after I provide the Linux credentials of the Linux owner of /path/to/share.



      I already tried:



      [myshare]
      path = /path/to/share
      writeable = yes
      browseable = yes


      Then Windows asks for credentials, but no matter what I enter, it's always denied.



      What is the correct way to gain write access to Samba shares from a Windows domain computer without granting 777?










      share|improve this question













      I have a path on a Linux machine (Debian 8) which I want to share with Samba 4 to Windows computers (Win7 and 8 in a domain). In my smb.conf I did the following:



      [myshare]
      path = /path/to/share
      writeable = yes
      browseable = yes
      guest ok = yes
      public = yes


      I have perfect read access from Windows. But in order to have write access, I need to do chmod -R 777 /path/to/share in order to be able to write to it from Windows.



      What I want is write access from Windows after I provide the Linux credentials of the Linux owner of /path/to/share.



      I already tried:



      [myshare]
      path = /path/to/share
      writeable = yes
      browseable = yes


      Then Windows asks for credentials, but no matter what I enter, it's always denied.



      What is the correct way to gain write access to Samba shares from a Windows domain computer without granting 777?







      permissions windows samba chmod shared-folders






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked May 29 '15 at 12:42









      Foo Bar

      1,10751325




      1,10751325




















          2 Answers
          2






          active

          oldest

          votes

















          up vote
          31
          down vote



          accepted










          I recommend to create a dedicated user for that share and specify it in force user.



          Create a user (shareuser for example) and set the owner of everything in the share folder to that user:



          adduser --system shareuser
          chown -R shareuser /path/to/share


          Then add force user and permission mask settings in smb.conf:



          [myshare]
          path = /path/to/share
          writeable = yes
          browseable = yes
          public = yes
          create mask = 0644
          directory mask = 0755
          force user = shareuser


          Note that guest ok is a synonym for public.






          share|improve this answer
















          • 1




            I had a similar problem and all google searches showed the dirty way to simply use 777. I wanted 775 for my shared folder and I wanted files to be created using my linux "defaultUser", I used also public = yes. Folder was 775, create and dir mask was 775 but in Windows it was not writable and I could not get why. Adding force user = defaultUser did the job for me.
            – firepol
            Jan 7 '17 at 11:03











          • I can't get this to work, any time I try to share the directory, I just get a window telling me I need to give "others" write permission in order to share the directory.
            – Mark Kramer
            Jun 22 '17 at 3:49










          • I got it, the problem was the location of smb.conf. Google and even sambas documentation said the file should be at /usr/local/samba/lib but actually it is in /etc/samba
            – Mark Kramer
            Jun 22 '17 at 15:37


















          up vote
          0
          down vote













          In the share settings in smb.conf, you'll need to specify the names of users and/or groups that are allowed to write to the share, using a write list = ... line.



          Example:



          [myshare]
          ...
          write list = my_linux_username



          Then you'll need to use the smbpasswd command to set up a password to authenticate my_linux_username for Samba:



          sudo smbpasswd -a my_linux_username


          This step is necessary because the standard system passwords in /etc/shadow are hashed in algorithms that are incompatible with the password hash algorithms used in the SMB protocol. When a client sends a SMB authentication packet, it includes a hashed password. It can only be compared to another password hash that uses the same algorithm.



          (Very, very old instructions from the previous millennium may recommend disabling password encryption in Samba, and using certain registry hacks to allow Windows to emit unencrypted passwords to the network. This advice is obsolete: those registry hacks may no longer work in current versions of Windows, and allow anyone who can monitor your network traffic to trivially capture your password.)




          There's one more thing you may have to do client-side. When your Windows client system is joined to an Active Directory domain and you're logged in with an AD account, it automatically prefixes all unqualified usernames with the name of the AD domain of the user, i.e. you will be authenticating as AD_DOMAINyour_username, not just your_username.



          If you are logged in with a local account (or your client system is not joined to an AD domain), Windows may automatically prefix the username with the client hostname unless you specify another domain name.



          To successfully log in to a stand-alone Samba server from a stand-alone Windows client, you may have to specify your username as SAMBA_SERVER_HOSTNAMEyour_username.



          Otherwise Samba will see the username as WINDOWS_CLIENT_HOSTNAMEyour_username, conclude that it has no way to verify any users belonging to domain named WINDOWS_CLIENT_HOSTNAME, and will reject the login.



          (Newer versions of Samba may have a built-in check for this specific situation, and they might allow you access nevertheless. But this is basically how SMB authentication works "under the hood", and if you need to deal with old versions of Samba, it might be useful still.)






          share|improve this answer




















            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "106"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f206309%2fhow-to-create-a-samba-share-that-is-writable-from-windows-without-777-permission%23new-answer', 'question_page');

            );

            Post as a guest






























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            31
            down vote



            accepted










            I recommend to create a dedicated user for that share and specify it in force user.



            Create a user (shareuser for example) and set the owner of everything in the share folder to that user:



            adduser --system shareuser
            chown -R shareuser /path/to/share


            Then add force user and permission mask settings in smb.conf:



            [myshare]
            path = /path/to/share
            writeable = yes
            browseable = yes
            public = yes
            create mask = 0644
            directory mask = 0755
            force user = shareuser


            Note that guest ok is a synonym for public.






            share|improve this answer
















            • 1




              I had a similar problem and all google searches showed the dirty way to simply use 777. I wanted 775 for my shared folder and I wanted files to be created using my linux "defaultUser", I used also public = yes. Folder was 775, create and dir mask was 775 but in Windows it was not writable and I could not get why. Adding force user = defaultUser did the job for me.
              – firepol
              Jan 7 '17 at 11:03











            • I can't get this to work, any time I try to share the directory, I just get a window telling me I need to give "others" write permission in order to share the directory.
              – Mark Kramer
              Jun 22 '17 at 3:49










            • I got it, the problem was the location of smb.conf. Google and even sambas documentation said the file should be at /usr/local/samba/lib but actually it is in /etc/samba
              – Mark Kramer
              Jun 22 '17 at 15:37















            up vote
            31
            down vote



            accepted










            I recommend to create a dedicated user for that share and specify it in force user.



            Create a user (shareuser for example) and set the owner of everything in the share folder to that user:



            adduser --system shareuser
            chown -R shareuser /path/to/share


            Then add force user and permission mask settings in smb.conf:



            [myshare]
            path = /path/to/share
            writeable = yes
            browseable = yes
            public = yes
            create mask = 0644
            directory mask = 0755
            force user = shareuser


            Note that guest ok is a synonym for public.






            share|improve this answer
















            • 1




              I had a similar problem and all google searches showed the dirty way to simply use 777. I wanted 775 for my shared folder and I wanted files to be created using my linux "defaultUser", I used also public = yes. Folder was 775, create and dir mask was 775 but in Windows it was not writable and I could not get why. Adding force user = defaultUser did the job for me.
              – firepol
              Jan 7 '17 at 11:03











            • I can't get this to work, any time I try to share the directory, I just get a window telling me I need to give "others" write permission in order to share the directory.
              – Mark Kramer
              Jun 22 '17 at 3:49










            • I got it, the problem was the location of smb.conf. Google and even sambas documentation said the file should be at /usr/local/samba/lib but actually it is in /etc/samba
              – Mark Kramer
              Jun 22 '17 at 15:37













            up vote
            31
            down vote



            accepted







            up vote
            31
            down vote



            accepted






            I recommend to create a dedicated user for that share and specify it in force user.



            Create a user (shareuser for example) and set the owner of everything in the share folder to that user:



            adduser --system shareuser
            chown -R shareuser /path/to/share


            Then add force user and permission mask settings in smb.conf:



            [myshare]
            path = /path/to/share
            writeable = yes
            browseable = yes
            public = yes
            create mask = 0644
            directory mask = 0755
            force user = shareuser


            Note that guest ok is a synonym for public.






            share|improve this answer












            I recommend to create a dedicated user for that share and specify it in force user.



            Create a user (shareuser for example) and set the owner of everything in the share folder to that user:



            adduser --system shareuser
            chown -R shareuser /path/to/share


            Then add force user and permission mask settings in smb.conf:



            [myshare]
            path = /path/to/share
            writeable = yes
            browseable = yes
            public = yes
            create mask = 0644
            directory mask = 0755
            force user = shareuser


            Note that guest ok is a synonym for public.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered May 29 '15 at 12:56









            yaegashi

            7,89611432




            7,89611432







            • 1




              I had a similar problem and all google searches showed the dirty way to simply use 777. I wanted 775 for my shared folder and I wanted files to be created using my linux "defaultUser", I used also public = yes. Folder was 775, create and dir mask was 775 but in Windows it was not writable and I could not get why. Adding force user = defaultUser did the job for me.
              – firepol
              Jan 7 '17 at 11:03











            • I can't get this to work, any time I try to share the directory, I just get a window telling me I need to give "others" write permission in order to share the directory.
              – Mark Kramer
              Jun 22 '17 at 3:49










            • I got it, the problem was the location of smb.conf. Google and even sambas documentation said the file should be at /usr/local/samba/lib but actually it is in /etc/samba
              – Mark Kramer
              Jun 22 '17 at 15:37













            • 1




              I had a similar problem and all google searches showed the dirty way to simply use 777. I wanted 775 for my shared folder and I wanted files to be created using my linux "defaultUser", I used also public = yes. Folder was 775, create and dir mask was 775 but in Windows it was not writable and I could not get why. Adding force user = defaultUser did the job for me.
              – firepol
              Jan 7 '17 at 11:03











            • I can't get this to work, any time I try to share the directory, I just get a window telling me I need to give "others" write permission in order to share the directory.
              – Mark Kramer
              Jun 22 '17 at 3:49










            • I got it, the problem was the location of smb.conf. Google and even sambas documentation said the file should be at /usr/local/samba/lib but actually it is in /etc/samba
              – Mark Kramer
              Jun 22 '17 at 15:37








            1




            1




            I had a similar problem and all google searches showed the dirty way to simply use 777. I wanted 775 for my shared folder and I wanted files to be created using my linux "defaultUser", I used also public = yes. Folder was 775, create and dir mask was 775 but in Windows it was not writable and I could not get why. Adding force user = defaultUser did the job for me.
            – firepol
            Jan 7 '17 at 11:03





            I had a similar problem and all google searches showed the dirty way to simply use 777. I wanted 775 for my shared folder and I wanted files to be created using my linux "defaultUser", I used also public = yes. Folder was 775, create and dir mask was 775 but in Windows it was not writable and I could not get why. Adding force user = defaultUser did the job for me.
            – firepol
            Jan 7 '17 at 11:03













            I can't get this to work, any time I try to share the directory, I just get a window telling me I need to give "others" write permission in order to share the directory.
            – Mark Kramer
            Jun 22 '17 at 3:49




            I can't get this to work, any time I try to share the directory, I just get a window telling me I need to give "others" write permission in order to share the directory.
            – Mark Kramer
            Jun 22 '17 at 3:49












            I got it, the problem was the location of smb.conf. Google and even sambas documentation said the file should be at /usr/local/samba/lib but actually it is in /etc/samba
            – Mark Kramer
            Jun 22 '17 at 15:37





            I got it, the problem was the location of smb.conf. Google and even sambas documentation said the file should be at /usr/local/samba/lib but actually it is in /etc/samba
            – Mark Kramer
            Jun 22 '17 at 15:37













            up vote
            0
            down vote













            In the share settings in smb.conf, you'll need to specify the names of users and/or groups that are allowed to write to the share, using a write list = ... line.



            Example:



            [myshare]
            ...
            write list = my_linux_username



            Then you'll need to use the smbpasswd command to set up a password to authenticate my_linux_username for Samba:



            sudo smbpasswd -a my_linux_username


            This step is necessary because the standard system passwords in /etc/shadow are hashed in algorithms that are incompatible with the password hash algorithms used in the SMB protocol. When a client sends a SMB authentication packet, it includes a hashed password. It can only be compared to another password hash that uses the same algorithm.



            (Very, very old instructions from the previous millennium may recommend disabling password encryption in Samba, and using certain registry hacks to allow Windows to emit unencrypted passwords to the network. This advice is obsolete: those registry hacks may no longer work in current versions of Windows, and allow anyone who can monitor your network traffic to trivially capture your password.)




            There's one more thing you may have to do client-side. When your Windows client system is joined to an Active Directory domain and you're logged in with an AD account, it automatically prefixes all unqualified usernames with the name of the AD domain of the user, i.e. you will be authenticating as AD_DOMAINyour_username, not just your_username.



            If you are logged in with a local account (or your client system is not joined to an AD domain), Windows may automatically prefix the username with the client hostname unless you specify another domain name.



            To successfully log in to a stand-alone Samba server from a stand-alone Windows client, you may have to specify your username as SAMBA_SERVER_HOSTNAMEyour_username.



            Otherwise Samba will see the username as WINDOWS_CLIENT_HOSTNAMEyour_username, conclude that it has no way to verify any users belonging to domain named WINDOWS_CLIENT_HOSTNAME, and will reject the login.



            (Newer versions of Samba may have a built-in check for this specific situation, and they might allow you access nevertheless. But this is basically how SMB authentication works "under the hood", and if you need to deal with old versions of Samba, it might be useful still.)






            share|improve this answer
























              up vote
              0
              down vote













              In the share settings in smb.conf, you'll need to specify the names of users and/or groups that are allowed to write to the share, using a write list = ... line.



              Example:



              [myshare]
              ...
              write list = my_linux_username



              Then you'll need to use the smbpasswd command to set up a password to authenticate my_linux_username for Samba:



              sudo smbpasswd -a my_linux_username


              This step is necessary because the standard system passwords in /etc/shadow are hashed in algorithms that are incompatible with the password hash algorithms used in the SMB protocol. When a client sends a SMB authentication packet, it includes a hashed password. It can only be compared to another password hash that uses the same algorithm.



              (Very, very old instructions from the previous millennium may recommend disabling password encryption in Samba, and using certain registry hacks to allow Windows to emit unencrypted passwords to the network. This advice is obsolete: those registry hacks may no longer work in current versions of Windows, and allow anyone who can monitor your network traffic to trivially capture your password.)




              There's one more thing you may have to do client-side. When your Windows client system is joined to an Active Directory domain and you're logged in with an AD account, it automatically prefixes all unqualified usernames with the name of the AD domain of the user, i.e. you will be authenticating as AD_DOMAINyour_username, not just your_username.



              If you are logged in with a local account (or your client system is not joined to an AD domain), Windows may automatically prefix the username with the client hostname unless you specify another domain name.



              To successfully log in to a stand-alone Samba server from a stand-alone Windows client, you may have to specify your username as SAMBA_SERVER_HOSTNAMEyour_username.



              Otherwise Samba will see the username as WINDOWS_CLIENT_HOSTNAMEyour_username, conclude that it has no way to verify any users belonging to domain named WINDOWS_CLIENT_HOSTNAME, and will reject the login.



              (Newer versions of Samba may have a built-in check for this specific situation, and they might allow you access nevertheless. But this is basically how SMB authentication works "under the hood", and if you need to deal with old versions of Samba, it might be useful still.)






              share|improve this answer






















                up vote
                0
                down vote










                up vote
                0
                down vote









                In the share settings in smb.conf, you'll need to specify the names of users and/or groups that are allowed to write to the share, using a write list = ... line.



                Example:



                [myshare]
                ...
                write list = my_linux_username



                Then you'll need to use the smbpasswd command to set up a password to authenticate my_linux_username for Samba:



                sudo smbpasswd -a my_linux_username


                This step is necessary because the standard system passwords in /etc/shadow are hashed in algorithms that are incompatible with the password hash algorithms used in the SMB protocol. When a client sends a SMB authentication packet, it includes a hashed password. It can only be compared to another password hash that uses the same algorithm.



                (Very, very old instructions from the previous millennium may recommend disabling password encryption in Samba, and using certain registry hacks to allow Windows to emit unencrypted passwords to the network. This advice is obsolete: those registry hacks may no longer work in current versions of Windows, and allow anyone who can monitor your network traffic to trivially capture your password.)




                There's one more thing you may have to do client-side. When your Windows client system is joined to an Active Directory domain and you're logged in with an AD account, it automatically prefixes all unqualified usernames with the name of the AD domain of the user, i.e. you will be authenticating as AD_DOMAINyour_username, not just your_username.



                If you are logged in with a local account (or your client system is not joined to an AD domain), Windows may automatically prefix the username with the client hostname unless you specify another domain name.



                To successfully log in to a stand-alone Samba server from a stand-alone Windows client, you may have to specify your username as SAMBA_SERVER_HOSTNAMEyour_username.



                Otherwise Samba will see the username as WINDOWS_CLIENT_HOSTNAMEyour_username, conclude that it has no way to verify any users belonging to domain named WINDOWS_CLIENT_HOSTNAME, and will reject the login.



                (Newer versions of Samba may have a built-in check for this specific situation, and they might allow you access nevertheless. But this is basically how SMB authentication works "under the hood", and if you need to deal with old versions of Samba, it might be useful still.)






                share|improve this answer












                In the share settings in smb.conf, you'll need to specify the names of users and/or groups that are allowed to write to the share, using a write list = ... line.



                Example:



                [myshare]
                ...
                write list = my_linux_username



                Then you'll need to use the smbpasswd command to set up a password to authenticate my_linux_username for Samba:



                sudo smbpasswd -a my_linux_username


                This step is necessary because the standard system passwords in /etc/shadow are hashed in algorithms that are incompatible with the password hash algorithms used in the SMB protocol. When a client sends a SMB authentication packet, it includes a hashed password. It can only be compared to another password hash that uses the same algorithm.



                (Very, very old instructions from the previous millennium may recommend disabling password encryption in Samba, and using certain registry hacks to allow Windows to emit unencrypted passwords to the network. This advice is obsolete: those registry hacks may no longer work in current versions of Windows, and allow anyone who can monitor your network traffic to trivially capture your password.)




                There's one more thing you may have to do client-side. When your Windows client system is joined to an Active Directory domain and you're logged in with an AD account, it automatically prefixes all unqualified usernames with the name of the AD domain of the user, i.e. you will be authenticating as AD_DOMAINyour_username, not just your_username.



                If you are logged in with a local account (or your client system is not joined to an AD domain), Windows may automatically prefix the username with the client hostname unless you specify another domain name.



                To successfully log in to a stand-alone Samba server from a stand-alone Windows client, you may have to specify your username as SAMBA_SERVER_HOSTNAMEyour_username.



                Otherwise Samba will see the username as WINDOWS_CLIENT_HOSTNAMEyour_username, conclude that it has no way to verify any users belonging to domain named WINDOWS_CLIENT_HOSTNAME, and will reject the login.



                (Newer versions of Samba may have a built-in check for this specific situation, and they might allow you access nevertheless. But this is basically how SMB authentication works "under the hood", and if you need to deal with old versions of Samba, it might be useful still.)







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Sep 22 at 8:57









                telcoM

                12.2k11435




                12.2k11435



























                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f206309%2fhow-to-create-a-samba-share-that-is-writable-from-windows-without-777-permission%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    How to check contact read email or not when send email to Individual?

                    Displaying single band from multi-band raster using QGIS

                    How many registers does an x86_64 CPU actually have?