dlwynne
asked on
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:
smbd/service.c:make_connec
'/data/backup' does not exist or permission denied when connecting to [backup] Error was Permission denied
I followed the troubleshooting guide here:
http://us5.samba.org/samba/docs/man/Samba-HOWTO-Collection/diagnosis.html
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.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions
[global]
workgroup = DOMAIN_NAME
server string = 'NAS Server'
security = DOMAIN
password server = PRIMARY_NT_DOMAIN_CONTROLL
load printers = No
cups options = raw
[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No
[backup]
comment = Backup Folder
path = /data/backup
[tmp]
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
smbd/service.c:make_connec
machine_name (192.168.0.109) 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
smbd/service.c:make_connec
'/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"
Thanks!
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:
smbd/service.c:make_connec
'/data/backup' does not exist or permission denied when connecting to [backup] Error was Permission denied
I followed the troubleshooting guide here:
http://us5.samba.org/samba/docs/man/Samba-HOWTO-Collection/diagnosis.html
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.
Server role: ROLE_DOMAIN_MEMBER
Press enter to see a dump of your service definitions
[global]
workgroup = DOMAIN_NAME
server string = 'NAS Server'
security = DOMAIN
password server = PRIMARY_NT_DOMAIN_CONTROLL
load printers = No
cups options = raw
[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No
[backup]
comment = Backup Folder
path = /data/backup
[tmp]
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
smbd/service.c:make_connec
machine_name (192.168.0.109) 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
smbd/service.c:make_connec
'/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"
Thanks!
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...
Dan
IT4SOHO
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...
Dan
IT4SOHO
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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:
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
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...
Dan
IT4SOHO
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...
Dan
IT4SOHO
ASKER
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.
log level = 3
and restart samba
2) check that directiry permissions on '/data' are also OK (not only on /data/backup)