Topic: backup2ws, sme7 & "permission denied" to share

[dvdsmith]

First, I've read though all the prior posts regarding backup2ws and also in the Bugtracker.  I currently have a 6.0.1 server with backup2ws working just fine and I'm testing out sme7 prior to upgrading to the final version when it comes out.

I setup a test box with a fresh install of 7pre1.  The only addons are the following 2 rpms, which I installed by copying the files over and running "yum install *.rpm".

rar-3.5.1-7dmay.i386.rpm
smeserver-backup2ws-0.0.1-31dmay.noarch.rpm

Near as I can tell these are the current valid files for sme7.  I went to the server panel and configured a manual 911 backup, using the same network share and login/password my 6.0.1 box currently backs up to (after renaming the 911 folder in the share).  However, when I try to start it manually, I no log file is generated.  In the messages log I find the following which seem to be where things went wrong;

Jan 12 14:42:01 smetest kernel: init_special_inode: bogus i_mode (0)
Jan 12 14:42:01 smetest kernel: smb_retry: no connection process
Jan 12 14:42:31 smetest kernel: smb_add_request: request [cba24e00, mid=0] timed out!
Jan 12 14:42:31 smetest kernel: smb_delete_inode: could not close inode 2
Jan 12 14:42:31 smetest mount.smbfs[3895]: [2006/01/12 14:42:31, 0] client/smbmount.c:send_fs_socket(410)
Jan 12 14:42:31 smetest mount.smbfs[3895]:   mount.smbfs: entering daemon mode for service \\XXXX\XXXX pid=3895
Jan 12 14:42:31 smetest kernel: smb_lookup: find //911 failed, error=-13
Jan 12 14:42:31 smetest e-smith-bg: /bin/mkdir: cannot create directory /mnt/backup2ws.911/911': Permission denied
Jan 12 14:42:31 smetest e-smith-bg: /bin/rm: cannot remove /mnt/backup2ws.911/911/911.*': Permission denied
Jan 12 14:42:31 smetest e-smith-bg: Error occured removing previous backup at /etc/e-smith/events/actions/backup2ws-backup line 97.

FYI, I overwrote the actual smb path with \\XXXX\XXXX.  I also attempted to creat a manual backup of /root with the same result.

I've rechecked the share and login settings.  I've made sure to click "Save" after making any changes.  I've read and applied all the advice in prior posts regarding upper/lowercase share names, making sure forward slashes are used, adding an account the same as on the share, etc.  Nothing works, yet the sme6.01 server keeps on working just fine.  The only thing I can figure is its some basic difference between Samba 2 and 3 regarding permissions is taking place.  Having the wrong case entered for sharenames doesn't seem to matter to 6.01, the backups work regardless.

FWIW, password strength for Users and Ibays is set to none. (Please, no rants on security etc, I'm well aware of potential consequences).  Aside from that, adding 2 RPMs, 2 User accounts and network settings, the installation is untouched.

Anyone have any thoughts on this one?  I'm at a loss.  Time to go home.

[dmay]

I suggest you peak inside the backup2ws-backup action and look at the mkdir & mount commands in question. Execute them directly from the command-line to isolate where your error is coming from.

The commands are quite straight forward:

# /bin/mkdir -p /mnt/backup2ws.$BackupJob

# /bin/mount -t smbfs -o username=$Username,password=$Password $Destination /mnt/backup2ws.$BackupJob

I have not seen any difference between SME versions in relation to this mounting a workstation share.

Darrell

[dvdsmith]

dmay said the following

The commands are quite straight forward:

# /bin/mkdir -p /mnt/backup2ws.$BackupJob

# /bin/mount -t smbfs -o username=$Username,password=$Password $Destination /mnt/backup2ws.$BackupJob

Darrell,  thanks for replying.  Now I think it has something to do with the 2003 Server the network share is on.  I tried the above on both boxes, with the 6.0.1 succeeding, and the 7pre1 box not.   Trying to list the contents of the mounted share results in a "Permission denied" response.  I then created a share on an XP workstation with identical login/password/permissions, and the 7pre1 box was able to mount and read the share.

Slightly off topic, I had a similar problem sometime back between the 2003 server and my only OS X user.  After loading 2003 Service Pack 1, the Mac was unable to access shared files on the server.  Something to do with login authentication, and I can't remember what the resolution was.  I guess I'll do a search for similar issues between 2003 and Samba3.

Thanks again.  David

[dvdsmith]

Darrell,

I think I found the specific cause of my problem, and I hope this is of help to others accessing a share on a W2K3 Server.  The share I'm trying to mount is on a W2K3 Server NOT acting as a Domain Controller.  From research and repeated testing if either of the the following two Group Policy settings are Enabled on the W2K3 server, mounting with smbfs on sme7pre1 (with samba 3.0.10) will fail;

Microsoft Network Server: Digitally sign communications (always)
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/9842e709-0583-4367-8618-ee7edaf8d2f6.mspx
Microsoft Network Server: Digitally sign communications (if client agrees)
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/ServerHelp/9842e709-0583-4367-8618-ee7edaf8d2f6.mspx

Both can be found by going to Control Panel\Administrative Tools\Local Security Policy

There are two ways around this.  

The first is to disable both policies.  If I understand things correctly, this is only an issue if the W2K3 server is operating as a Domain Controller and I'm concerned with man-in-the-middle attacks.  FYI, the second policy appears to have changed to Enabled following the SP1 update last year.

The second is to use cifs rather than smbfs as follows;

# /bin/mount -t smbfs -o username=$Username,password=$Password $Destination /mnt/test
doesnt' work

# /bin/mount -t cifs -o username=$Username,password=$Password $Destination /mnt/test
does work, provided I use the servers IP and not its UNC name

Is modifying backup2ws to use cifs an option?  Is there a compelling reason not to?   I'm not making a change request, but can I make the change myself for my own situation?

Dave

[dvdsmith]

Darrell, thanks for the great contrib.  I managed to get backup2 alpha3 (on sme7pre1) to backup to and restore from the W2K3 server.  I modified backup2-backup and backup2-restore using vi, replacing smbfs with cifs.  Since I don't have an internal DNS, I also had to use the server's IP in place of its UNC name.

But it works!  

I guess this isn't a common circumstance, but I hope someone else with the same problem later on can benefit from my stumbling around.

Thanks again,

David

[dmay]

Is modifying backup2ws to use cifs an option?

It could be   I'm quite familiar with cifs as it is used in SSLExplorer. Let me test this further on backup2.

Darrell

[dmay]

I modified backup2-backup and backup2-restore using vi, replacing smbfs with cifs.  Since I don't have an internal DNS, I also had to use the server's IP in place of its UNC name.

David,

After some research I found a major limitation of the current release of mount.cifs is the lack of true UNC support. The destination must be in the form of //ipaddress/share. Since most workstations have a dynamic IP this really is a major limitation. However, as you noted cifs is the best solution when the destination is a W2K3 server. In this instance servers typically have a static IP.

In summary, I've decided to initially provide support for cifs via admin defined command line db entry only.

[root@test RPMS]# rpm -qp --changelog smeserver-backup2-0.0.1-a4dmay.noarch.rpm
* Thu Jan 19 2006 Darrell May <dmay@myezserver.com>
- added db FileSystem variable supporting smbfs (default) or cifs (optional)
- syntax: /sbin/e-smith/db backup2 setprop $BackupJob FileSystem cifs
- note cifs currently supports destination unc format of //ipaddress/share only
- [0.0.1-a4dmay]

Thanks for the feedback.

Darrell