We have a windows XP share entry in our FSTAB that works as follows:

//MAIN/StorageD /mnt/storaged cifs username=admin,password='',uid=1001,gid=1000,iocharset=utf8,file_mode=0777,dir_mode=0777,noperm 0    0

But the entry for a Windows 7 box does not:

//MAIN-WIN7/Win7VM /mnt/Win7VM cifs username=main,password='',uid=1001,gid=1000,iocharset=utf8,file_mode=0777,dir_mode=0777,noperm 0    0

The directory /mnt/Win7VM is set to 777 permissons and owned by user 1001

So we try to debug a bit and mount manually...

Just as a check, the following works:

mount -t cifs '//MAIN/backupx' /mnt/backupx -o username=Admin,password=''

But for the windows 7 machine, this does not work.

mount -t cifs '//MAIN-WIN7/Win7VM' /mnt/Win7VM -o username=Main,password=''

As I get the error (which is famous I guess):

root@debian:/home/user# mount -t cifs //MAIN-WIN7/Win7VM /mnt/Win7VM -o     username=Main,password='',sec=ntlm
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

So, I spend hours searching, checking, and trying to do the following:

Checked settings:

  • Workgroup is "WORKGROUP"
  • Domain is "MAIN-WIN7"
  • User is "Main"
  • Password is not set
  • Share is Win7VM
  • Share is available through network shares in windows

SMBTREE lists:

root@debian:/home/user# smbtree
Enter root's password: 
  • Changed Windows security policy settings of "Microsoft Network Client: Send un-encrypted passwords to third party" to "Enabled"
  • Changed Windows security policy of "Network Security: LAN manager authentication level in to send LM & NTLM - use NTLMv2 session security if negotiated"
  • Turned off all anti virus and firewalls
  • Adding "sec=ntlm" switch as in "/mnt/Win7VM -o username=Main,password='',sec=ntlm"
  • Adding domain to user as in "MAIN-WIN7/Main"
  • Using "mount.cifs" instead of "mount -t cifs"
  • CHMOD mount directory to 777 CHOWN mount directory to user "1001" and Group to "user" (will need this for fstab entry if I can get it to mount manually)

Share is on Windows 7 Ultimate and Client with permission errors is Debian Wheezy.

Now I am out of searching terms and ideas. I thought this would be simple; now I have wasted hours. Anyone got any ideas? Its probably something simple right?


Forgot the dummy check of trying to access the share from a windows computer. It did not work leading me to investigate more windows settings which led me to the solution posted below.

  • Hidden on the right of your command line is the sec=ntlm option which happened to be the key in my case. Also worth a read: askubuntu.com/questions/580069/… Jul 8, 2015 at 16:12
  • (windows 7) I had to go to control panel -> network and internet -> network and sharing center -> advanced sharing settings -> and choose "turn off [yes, off] password protected sharing". Then I could mount my share on Debian with a password (yes, with).
    – BurnsBA
    Mar 27, 2016 at 23:57

2 Answers 2


Leave it to Windows to be the problem, NOT Linux.

Solution was to change the sharing AND the security settings of the share to include the necessary permissions.

Found a video here on you tube that was the final piece of the puzzle.

Essentially you give both sharing and security permissions to "EVERYONE" on the drive you want to share (this probably is true for a folder as well, but that is not what I was trying to share).

For the first, go to the drive and then go to Properties>Sharing>Advanced Sharing>Permission and on the "EVERYONE" group/user assign all the permissions. If everyone is not listed, then add them to the list.

For the second go to Properties>Security>Edit>Add and add "EVERYONE". Then assign all the permission you want to "EVERYONE".

As a note I also identified the network as "private" via Control Panel>Administrative Tools>Local Security Policy>Network Manger List Policies> then selected the applicable network and changed the location to "Private".. Not sure if this affected anything in the end.

I am sure the default settings are all for a good cause and by giving "everyone" full control permissions opened some gaping hole that will cause my computer and network to explode by some people's interpretation of future event, but hey, it fixed the problem.


This might be weird, but as I used the previous answer, it seemed it did not solve all the problems. But I found a combination of solutions the seemed to actually fix the problem and since this problem seems so prevalent, it seemed prudent to post my fix.

First note some items in windows and change some settings. Note user name, password, and workgroup (domain). I left my "homegroup" as well.

Also change a registry entry to prevent memory allocation errors with larger (<1GB caused problems for me) shares and transfers. Change HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\Size to "3"

A link to additional info about this registry setting is Here.

Now restart the LanmanServer to apply the registry settings. Open the CMD prompt with administrator rights and type in:

sc stop LanmanServer
sc start LanmanServer

That solution came from Here

Now hopefully windows is ready to go.

Next the linux side. The big change that worked was putting the share's user and server information into a credentials file instead of the mounting command. This was the final magic piece that I thought would not do any thing and it started working immediately after the change (albeit with memory issues that we solved above). Do this by creating a file with:


Then add a "cred" parameter to the fstab entry. I also added a rw parameter. And just in case, I changed the uid and gid to my the user logged in on the linux box. 1001 might work, I just have not tried it.

So my final fstab entry looked like this.

//DESIGNPC/BackupX /mnt/backupx cifs rw,uid=user,gid=user,file_mode=0777,dir_mode=0777,cred=/home/user/.cred,sec=ntlm 0 0

Details of some of this came from Here

Transferring files both directions has worked flawlessly along with reading and deleting where my answer before still had some permissions issues with writing and deleting that I was just working around and had not come back to this question. This also solve the memory allocation issues that are bound to arise that seem like they are on the Linux side, but required the windows registry change to be fixed.

You must log in to answer this question.

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