• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 888
  • Last Modified:

Samba as part of an NT domain - net use fails with " does not exist or permission denied"

I built an "NAS" box with a large RAID array and I need to share it to clients on an existing Windows NT domain so they can map to various shares using their existing NT domain user names and passwords (without me having to add them as LINUX users). I also would like to install Netware emulation, but that is another story :-)

I have CentOS release 5.3 and Samba version 3.0.33-3.7.el5 .

I got everything installed, but when I try to map a drive from a windows box to the share I made I get:

  '/data/backup' does not exist or permission denied when connecting to [backup] Error was Permission denied

I followed the troubleshooting guide here:

and everything seems to work as expected until I try to map MY share.  I added the /tmp share as they show in their example and I CAN map to that (it does not even require a password) but when I try to map to the share I NEED to use it does not work. /tmp is drwxrwxrwt so I made my to be shared folder (/data/backup) the same - still no go. Both show root as owner:group, but I have tried many different "owners" and always get the same result.

I have tried to simplify my smb.conf for testing, so running testparm smb.conf produces:

Load smb config files from smb.conf
Processing section "[printers]"
Processing section "[backup]"
Processing section "[tmp]"
Loaded services file OK.
Press enter to see a dump of your service definitions
        workgroup = DOMAIN_NAME
        server string = 'NAS Server'
        security = DOMAIN
        password server = PRIMARY_NT_DOMAIN_CONTROLLER_NAME
        load printers = No
        cups options = raw

        comment = All Printers
        path = /var/spool/samba
        printable = Yes
        browseable = No

        comment = Backup Folder
        path = /data/backup

        comment = temporary files
        path = /tmp

I removed stuff like valid users = @DOMAIN_NAME\users from my share, since the problem seems to be permissions at the LINUX level with the folder I want to share.

If I issue the command

net use W: \\NAS\tmp /USER:DOMAIN_NAME:any_user

from a box on the domain it maps right up and the log shows

  machine_name ( connect to service tmp initially as user DOMAIN_NAME\user_name (uid=10000, gid=30000) (pid 11504)

It did not ask for a password.

If I delete that mapping and try:

net use W: \\NAS\backup /USER:DOMAIN_NAME:any_user

I am prompted for a password. If I use the wrong password, I get

System error 1326 has occurred.
Logon failure: unknown user name or bad password.

on the windows box - so it knows I missed the password. There is no entry in the smbd.log when I do this.  So I try again with the correct password and I get:

System error 87 has occurred.
The parameter is incorrect.

on the windows box and get this in the smbd.log

  '/data/backup' does not exist or permission denied when connecting to [backup] Error was Permission denied

What am I doing wrong?  I added another new share, but did not make the folder and I get the same error as I get when trying to map the share that DOES exist. I made a share for the /etc folder as a test, and that worked.  The /tmp and /etc are on the "OS volume" (/dev/hda3 with about 52 gb available) which is an IDE hard drive. The other shares are on the RAID array, if that matters. This is /dev/sda1 and has 1.1 tb available.  I tried sharing a LINUX user's home folder and I get the same error (but its permission is drwx------ so that might be "normal"


  • 3
  • 2
1 Solution
1)add to [global]:
log level = 3

and restart samba

2) check that directiry permissions on '/data' are also OK (not only on /data/backup)
Daniel McAllisterPresident, IT4SOHO, LLCCommented:
Permissions on /          must include other execute (d--x--x--x is a minimum)
Permissions on /data  must include other execute (d--x--x--x is a minimum)
Permissions on /data/backup must ALSO include READ permissions (and write, if Samba is to write files to it... (drwxrwxr-x would be a workable minimum)

What I mean by a MINIMUM above is that those r's & x's MUST be there, and the -'s may be replaced with optional r's & w's if you want/need them.

It is also possible that /data/backup is a symbolic link to someplace that doesn't have full execute-path permission (so you'll get the same error).

It is also possible that the filesystem that houses /data/backup may be corrupt -- do an "ls -al /data/backup" and make sure that . and .. appear (as a minimum).

The additional logging created by the above suggestion may help if these don't reveal the issue...

I hope this helps...

dlwynneAuthor Commented:
/data is also drwxrwxrwt  as are the directories under it.

Here is the strange part, it is now working (it seems). I have to put everything back as it was.  While waiting for help on this topic I started working on the mars_nwe install and I had to get a newer kernel that supports IPX so I am now on 2.6.18-128.1.10.el5.centos.plusPAE .

It could have been something else I did last night or just the kernel update?  I don't know, but I can map to the shares for folders I made now.  I have to double check that only valid domain users that authenticate can connect, but it looks good so far.

I  can see my real NW servers from the Centos box, but I can't see the NWE on the Centos from any NW clients. I feel a new EE question comeing on  :-)
Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Daniel McAllisterPresident, IT4SOHO, LLCCommented:
The "t" at the end of the directories was put there for tmp so that files in a "shared" folder would be protected from users OTHER THAN the creator (of the file).... it is referred to as a "sticky-bit", but that's not the real use here.
The result is that userB cannot remove a file created by userA in the folder unless userB has write permission to the file.
Suppose /tmp looks like this:

drwxrwxrwt   3  root     root     20480   May 20 12:00  .
dr-x--x--x  30  root     root      4096   Jan  1  1997  ..
-r-xr-xr-x   1  userA    userA        5   May 20 12:01  file

Open in new window

Daniel McAllisterPresident, IT4SOHO, LLCCommented:
OOps... my bad on the submit there...
In any case, with the code snippet above, userB CANNOT remove the file (file) EVEN THOUGH they have write permission on the directory, because they do not also have write permission on the FILE (file) while the sticky-bit is on.
I bring this up because that MAY NOT be the behavior you want on your backup folder (then again, it may be... but you should know).
I'm glad its working...
dlwynneAuthor Commented:
That is what I wanted. The backup share (for example) is for image backups of workstations and there is no problem having other users see or even access the backup images of others, I just don't want them to be able to delete a file or directory belonging to someone else - thus the sticky bit.  I tested, and that part works too.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now