Linux mount windows share permission denied

Cannot Mount Windows 7 Share from Linux using CIFS: Mount error(13): Permission denied

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

But the entry for a Windows 7 box does not:

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:

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

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

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

• 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

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

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 ( 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:

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.

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.

Источник

Permission denied on files in a directory on a CIFS-mounted Windows share in Linux

I have two directories:

which are mounted under:

When I try to read any file under directory1 I can, but when I try to read any file in directory2 I receive a «Permission Denied» error.

The Windows machine is running Windows XP Media Center Edition. The Linux is Fedora 10.

When I right click on either of the two files or their parent directories their attributes appear identical. On files: Read Only -, Hidden -, file is ready for archiving +, for fast search +, compress -, encrypt — On directories: Read Only +, Hidden -, file is ready for archiving -, for fast search +, compress -, encrypt —

If there’s any other info I can give to help, let me know.

Any help would be appreciated, thanks.

Additional info: Mounted via: mount -t cifs //192.168.1.103/c /mnt/c-drive with no username/password

Here are CACLS info for 2 individual files directory1\file1

So now that I see the premission differences.

2 Answers 2

It sounds to me like you should go look at the NTFS permissions on those directories on the Windows XP computer. My guess is that the user account you’re using to mount those from the Fedora box doesn’t have rights.

Since it’s XP Media Center the «Security» tab of the folder properties might be hidden. From a command-prompt, you can use the CACLS command (as below) to list the permissions:

The output of CACLS is somewhat easy to parse, but you can post the output here as an edit to your question if you’re having trouble with it.

What Windows username are you specifying in the arguments to your mount on Linux?

Okay— so w/o a username and password specified you’re connecting as «guest». The permission «Everyone:F» is allowing that to work.

The NTFS permissions on those directories are the same. If you create a new file in each directory from either the Windows or Linux machine you should see the same access. Try that and make sure it works.

I’m wondering if you have permissions set on individual files in «directory2». Since XP Media Center «hides» the «Security» tab by default (if I remember properly), try a CACLS referencing an individual file that’s giving you problems in «directory2». I suspect you’ll find that it has different permissions than «directory2» itself. Did you happen to move files into «directory2» from elsewhere on the hard disk drive of the computer?

Источник

mount error 13 = Permission denied

One of my servers is set up to automatically mount a Windows directory using fstab. However, after my last reboot it stopped working. The line in fstab is:

The .Smbcredentials file is:

I do a mount -a and I receive mount error 13 = Permission denied . If I do this enough it will lock out my Windows account, so I know it’s trying. I’ve checked that my password is correct.

What am i doing wrong?

5 Answers 5

A couple of things to check out. I do something similar and you can test mount it directly using the mount command to make sure you have things setup right.

Permissions on credentials file

Make sure that this file is permissioned right.

Verbose mount

You can coax more info out of mount using the -v switch which will often times show you where things are getting tripped up.

Resulting in this output if it works:

Check the logs

After running the above mount command take a look inside your dmesg and /var/log/messages or /var/log/syslog files for any error messages that may have been generated when you attempted the mount .

Type of security

You can pass a lot of extra options via the -o .. switch to mount. These options are technology specific, so in your case they’re applicable to mount.cifs specifically. Take a look at the mount.cifs man page for more on all the options you can pass.

I would suspect you’re missing an option to sec=. . Specifically one of these options:

You may need to adjust the sec=. option so that it’s either sec=ntlm or sec=ntlmssp .

Источник

Linux Mint Forums

Welcome to the Linux Mint forums!

Samba | Failed to mount Windows share: Permission denied

Samba | Failed to mount Windows share: Permission denied

Post by Boarnads » Wed Feb 18, 2015 1:29 am

I’ve been trying to setup samba via webmin and have run into several permission problems. I’m trying to setup several shares that require no authentication.
Below are the current problematic shared folders and their status:

‘/media/username/My Book’
Visible in network but get the following when trying to access it

‘/home/username/Videos’
I can access this from the network but I cannot access any of the individual files, I can only browse through the folders.

‘ls -l’ gives me the following
drwx—— 1 username username 8192 Feb 17 02:18 My Book
drwxr-xr-x 9 username username 4096 Feb 18 04:48 Videos

I also tried chmod 777 for My Book prior to ls -l command, it appeared to complete successfully although the permissions dont seem to have changed.

Any help in resolving this issus would be greatly appreciated
Regards,
Boarnads

Re: Samba | Failed to mount Windows share: Permission denied

Post by Pjotr » Wed Feb 18, 2015 5:26 am

Works flawlessly with my own NAS.

Re: Samba | Failed to mount Windows share: Permission denied

Post by altair4 » Wed Feb 18, 2015 7:19 am

You might be able to fix both problems by forcing the remote quest to appear to be you — at least for your samba shares anyway:

Edit smb.conf and under the workgroup = workgroup line add this line:

I’m using your reference to «username» so change that to whatever your real user name is.

Then restart smbd:

Re: Samba | Failed to mount Windows share: Permission denied

Post by kwisher » Wed Feb 18, 2015 2:36 pm

Is the MyBook formatted as NTFS? This could be the problem as NTFS doesn’t work with Linux permissions, iirc.

altair, please correct me if I am all wet.

Re: Samba | Failed to mount Windows share: Permission denied

Post by altair4 » Wed Feb 18, 2015 3:31 pm

Re: Samba | Failed to mount Windows share: Permission denied

Post by Aristotelian » Wed Feb 18, 2015 5:28 pm

Re: Samba | Failed to mount Windows share: Permission denied

Post by Boarnads » Wed Feb 18, 2015 9:45 pm

The hdd is NTFS but Ive gotten the shares to work before with NTFS drives without the ‘force user’, I just cant remember what I did.
However I’m now using ‘force user = username’ which seems to have fixed the problem, I’m just wondering are there any negatives to ‘force user’, would I be better off getting the permissions working, especially for the ‘Videos’ share?

Thank you all very much for your help.

Re: Samba | Failed to mount Windows share: Permission denied

Post by altair4 » Thu Feb 19, 2015 7:47 am

Warning: This is going to be an unbelievably long answer

Let’s take the worst case scenario and assume the client machine is running Windows and that the user on that machine is named «bob».

When bob tries to access your Mint machine Windows automatically passes his user name to Samba. If there is no match in the samba password database for «bob» the «map to guest = Bad User» parameter is invoked and changes «bob» to the default guest user in Mint which is literally «nobody».

«nobody» doesn’t have access to «/media/username/My Book» at all ( actually no one has access to that folder except «username» ) and only has read access to /home/username/Videos. «force user» makes «nobody» «username» so he now does have access to both. Depending on how you create the samba share definition it still has a gatekeeper function in that if you set it up to be read only the Windows client cannot write even though he is now «username».

If however the user name on the Windows machine is also «username» and his name does appear in the samba password database then he is no longer a «Bad User» and he comes across as «username» and the situation is resolved. If this is the case then you could add yourself ( username ) to the samba password database:

Now the Windows user is also the Linux user and he has access to both shares without the need for «force user». But this will only work for the Windows user «username». You would still need the «force user» if you have many windows clients.

If however the client machine is running Linux the situation changes.

The Linux samba client doesn’t pass a user name when it tries to access the Mint machine because . well . Linux thinks that’s goofy. The Linux client will always come across as «nobody» unless the share requires credentials. In this scenario — for a guest share — «force user» is the easiest way to resolve the situation without changing the guest share to a private share requiring credentials.

Either way «force user» doesn’t give the remote user full access to your entire box only to the samba shares and only within the parameters set in the share definition for those shares.

Edited for spelling — I just can’t spell

Источник

Mounting Windows shares using cifs results in «Error:13(Permission denied)»

Ubuntu 12.04.1 LTS, kernel 3.2.0-57-generic Windows Server 2008 R2 SP1 x64

Trying to setup a network share from Ubuntu 12.04 to a Windows Server 2008 R2 however no matter what changes are made the share fails to mount due to error(13): permission denied.

Firewall port 445 has been opened between the two servers which enabled me to ping the servers from each other so it’s not something on the firewall blocking the connection.

The windows server is not part of a domain so I’ve tried with and without workgroup option. The windows account isn’t disabled, I check often to make sure that I haven’t locked it. Trying to use a 16 char password with lower/upper alphanumeric. No special characters.

Windows Advanced Share permissions has Everyone(full/read/write) and the user account(full/read/write) permissions. Windows Folder Security has Everyone(Full/read/write) and the user account (full/read/write). I can access the windows share from my local box using the same username/password as used for the mount commands below. The windows share is located at C:\Share.

Windows Event viewer is reporting it as Unknown user name or bad password with or without the sec=ntlmv2 or sec=ntlm. Any changes to the sec option still provides a error(13). The user account is an administrator on the server and i’ve typed and retyped and reset the password from something complex to something simple and still not going through. My local box can connect through the windows share no problem with any version of the password set.

The windows network connection is considered a public network. Under Network and Sharing Center the Advanced Sharing Settings->Home/Work and Public — Public Folder sharing have been set to turned On. Password protected sharing-> turned on since I’m trying to use an admin account local to the server.

The /mnt/share directory has been created and has been tested with rw-rw-r—,rwxrwxrwx,rw-rw-rw-,rwxrwxrw- permissions just in case it had something to do on the linux side.

I tried both user= and username= with all of the commands listed below. Also made sure not to use any extra white spaces unless needed. No quotation marks are used anywhere in the commands, I’ve read some people were doing username=’user’

Following received a Error:13(Permission denied)

Following received a Error:22(Invalid Argument)

I also downloaded and tried the outdated SMBFS which also produced a Error:13

Источник