Backup to Workstation configured to backup to another SME server on local Lan. If the password to access the remote server contains the "!" character the backup will fail. Alternate passwords result in normal operation. Error Messages below. ================================== DAILY BACKUP TO WORKSTATION REPORT ================================== Backup started at Fri Dec 12 12:51:02 2008 Backup of mysql databases has been done. Mounting backup shared directory svr03/recovery *** No backup allowed or error during backup *** Error while mounting svr03:recovery : mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) Error while mounting svr03:recovery : mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) Backup terminated: backup failed - status: 7424
*** Bug 4923 has been marked as a duplicate of this bug. ***
Released in SME 7.5
(In reply to comment #49) > I think we should split off first as the problem we are discussing is not > related to the issue fixed in this bug. Cloned to bug 5589.
Setting back to VERIFIED
(In reply to comment #48) > Yes, as stated earlier, there is a samba bug which parses that file > incorrectly. We have a choice to be fancy during template expansion and > post-process the file to remove the trailing newline, or to fix samba. I think we should split off first as the problem we are discussing is not related to the issue fixed in this bug.
(In reply to comment #47) > (In reply to comment #45) > > An empty line? Do you really mean an empty line - i.e. file ends with \n\n? If > > so, the only thing I can see which would cause that is if $backupwk{'Password'} > > actually contains a \n. > > According to this, no;(nice tip, thanks): > > [root@example dar]# od -c CIFScredentials > 0000000 u s e r n a m e = b a c k u p \n > 0000020 p a s s w o r d = b a c k u p \n > 0000040 > [root@example dar]# > > But as soon as you remove the 0000040 line the workstation to backup parses > correctly. There is no 0000040 line. You mean byte 0x3F, I think, which is the trailing newline. Yes, as stated earlier, there is a samba bug which parses that file incorrectly. We have a choice to be fancy during template expansion and post-process the file to remove the trailing newline, or to fix samba.
(In reply to comment #45) > An empty line? Do you really mean an empty line - i.e. file ends with \n\n? If > so, the only thing I can see which would cause that is if $backupwk{'Password'} > actually contains a \n. According to this, no;(nice tip, thanks): [root@example dar]# od -c CIFScredentials 0000000 u s e r n a m e = b a c k u p \n 0000020 p a s s w o r d = b a c k u p \n 0000040 [root@example dar]# But as soon as you remove the 0000040 line the workstation to backup parses correctly.
(In reply to comment #40) > Looking at the patch from e-smith-backup v22 I don't see how we could > avoid the 0A We could avoid it by use of a custom FILTER in the templates.metadata file. > so do we need to take the patch from > https://bugzilla.redhat.com/show_bug.cgi?id=532094 which has been tested by > CentOS. I think that is a better option, especially since I believe we should be using a much later samba version anyway (for Vista and Windows 7 compatibility).
(In reply to comment #36) > This is because CIFScredentials file in /etc/dar has an empty line at the end > of the file. If you remove the empty line at the end of the file you are then > able to mount correctly. An empty line? Do you really mean an empty line - i.e. file ends with \n\n? If so, the only thing I can see which would cause that is if $backupwk{'Password'} actually contains a \n.
(In reply to comment #41) > Maybe the credentials file issue should be made into a separate bug against > samba, as the fix for e-smith-backup is actually correct. OK, sounds good. [This is another reason for us maintaining our own samba stream, rather than relying on an upstream who seem not to care enough about samba capabilities.]
(In reply to comment #38) > Not sure about that. In vi there is no additional line visible, and from my > workstation I cannot see any strange line endings, although it sounds like a > good theory. Don't trust what vi shows you as line feeds. Use: od -c < /path/to/file and you will see exactly what is in the file.
(In reply to comment #41) > Maybe the credentials file issue should be made into a separate bug against > samba, as the fix for e-smith-backup is actually correct. Here is a > verification for this bug but it is blocked due to the samba issue so I won't > change the bug status. It also makes me think that bug 5442 wasn't verified correctly due to this issue.
Maybe the credentials file issue should be made into a separate bug against samba, as the fix for e-smith-backup is actually correct. Here is a verification for this bug but it is blocked due to the samba issue so I won't change the bug status. = Environment: SME Server 7.4 Backup to Workstation configured to backup to another SME server on local Lan. If the password to access the remote server contains the "!" or "," character the backup will fail. Other passwords result in normal operation. # rpm -q e-smith-backup samba e-smith-backup-2.0.0-19.el4.sme samba-3.0.28-0.el4.9 Either start a backup from the panel, or just # /sbin/e-smith/do_backupwk Error while mounting 192.168.0.254:temp : mount error 13 = Permission denied Refer to the mount.cifs(8) manual page (e.g.man mount.cifs) Backup terminated: backup failed - status: 7424 = Updated version installed: Updated via yum # rpm -q e-smith-backup samba e-smith-backup-2.0.0-23.el4.sme samba-3.0.33-0.18.el4_8 # signal-event post-upgrade; signal-event reboot Note: Hack /etc/e-smith/templates/etc/dar/CIFScredentials/template-begin to remove the final LF if using samba-3.0.33-0.18.el4_8 due to a known problem with the credentials file = Problem fixed: Try a problematic password eg "Te2er,!" # /sbin/e-smith/do_backupwk Backup is made and email arrives informing of successful backup. = Release note information suggestion: Some valid passwords would fail due to how the backup directory was mounted. The backup now uses a credentials file for mount.cifs to avoid this limitation. = Verified or Reopen: Marking VERIFIED pending resolving the samba credentials file issue, or splitting that into a separate bug.
(In reply to comment #36) > This is because CIFScredentials file in /etc/dar has an empty line at the end > of the file. If you remove the empty line at the end of the file you are then > able to mount correctly. I can now see the 0A LineFeed character in the file. Vi also adds it by default so in my own credentials file I also got it. Looking at the patch from e-smith-backup v22 I don't see how we could avoid the 0A so do we need to take the patch from https://bugzilla.redhat.com/show_bug.cgi?id=532094 which has been tested by CentOS.
http://www.mail-archive.com/centos@centos.org/msg44572.html It seems that a samba update may have broken this. Even the final LF needs to be removed now, or patch samba.
(In reply to comment #36) > (In reply to comment #35) > > It just fails when tying to use the credentials file, which visually contains > > the correct information. > > This is because CIFScredentials file in /etc/dar has an empty line at the end > of the file. If you remove the empty line at the end of the file you are then > able to mount correctly. Not sure about that. In vi there is no additional line visible, and from my workstation I cannot see any strange line endings, although it sounds like a good theory. I've also tried manually creating a credentials file but that also failed.
(In reply to comment #36) > (In reply to comment #35) > > It just fails when tying to use the credentials file, which visually contains > > the correct information. > > This is because CIFScredentials file in /etc/dar has an empty line at the end > of the file. If you remove the empty line at the end of the file you are then > able to mount correctly. Reopening.
(In reply to comment #35) > It just fails when tying to use the credentials file, which visually contains > the correct information. This is because CIFScredentials file in /etc/dar has an empty line at the end of the file. If you remove the empty line at the end of the file you are then able to mount correctly.
I cannot verify this, even with a normal user and password I just get mount error 13 = Permission denied I've tried running the mount.cifs by itself with the --verbose to see what is going on. OLD WAY mount.cifs kernel mount options: unc=//192.168.0.254\data,ip=192.168.0.254,ver=1,rw,user=test2,pass=******** This mounts fine NEW WAY mount.cifs kernel mount options: unc=//192.168.0.254\data,ip=192.168.0.254,user=test2,ver=1,rw,credentials=/etc/dar/CIFScredentials,nounix,pass=******** This fails, however it does pick up the user correctly so it has been able to read the credentials file correctly. It just fails when tying to use the credentials file, which visually contains the correct information.
(In reply to comment #33) > seems done > > see e-smith-backup.spec for 2.2.0-22 : > > * Wed Aug 26 2009 Jonathan Martens <smeserver-contribs@snetram.nl> 2.2.0-22.sme > Porting Jean-Paul Leclere changes in the SME Server 7 tree to SME Server 8: > - using credentials file for cifs mount [SME: 5442] > - workstation backup: add cifs credentials expand to bootstrap-console-save > [SME: 5442] > > needs only verification No this is the SME Server 8.x fix actual changelog entries for SME Server 7.x release are: * Wed Aug 26 2009 Jean-Paul Leclere <jean-paul@leclere.org> 2.0.0-23.sme - workstation backup: add cifs credentials expand to bootstrap-console-save [SME: 4850] * Tue Aug 25 2009 Jean-Paul Leclere <jean-paul@leclere.org> 2.0.0-22.sme - workstation backup: using credentials file for cifs mount [SME: 4850]
seems done see e-smith-backup.spec for 2.2.0-22 : * Wed Aug 26 2009 Jonathan Martens <smeserver-contribs@snetram.nl> 2.2.0-22.sme Porting Jean-Paul Leclere changes in the SME Server 7 tree to SME Server 8: - using credentials file for cifs mount [SME: 5442] - workstation backup: add cifs credentials expand to bootstrap-console-save [SME: 5442] needs only verification
(In reply to comment #31) > Shouldn't this be cloned to SME 8 as well? It should and fixes should be applied there as well.
(In reply to comment #30) > Marking FIXED in e-smith-backup: > > * Wed Aug 26 2009 Jean-Paul Leclere <jean-paul@leclere.org> 2.0.0-23.sme > - workstation backup: add cifs credentials expand to bootstrap-console-save > [SME: 4850] Shouldn't this be cloned to SME 8 as well?
Marking FIXED in e-smith-backup: * Wed Aug 26 2009 Jean-Paul Leclere <jean-paul@leclere.org> 2.0.0-23.sme - workstation backup: add cifs credentials expand to bootstrap-console-save [SME: 4850]
(In reply to comment #28) > (In reply to comment #27) > > But the two solutions are equally functional for SME, and the core team > > decides. So, agree with expand in conf-backup event (which is effectively > > called in backup function). > > You also want to link this into console-save or bootstrap-console-save. This > way the file gets expanded after a restore as well. bootstrap-console-save. console-save is only used in very limited circumstances, and not, as far as I am aware, after restore.
(In reply to comment #27) > But the two solutions are equally functional for SME, and the core team > decides. So, agree with expand in conf-backup event (which is effectively > called in backup function). You also want to link this into console-save or bootstrap-console-save. This way the file gets expanded after a restore as well.
I am convinced for the place of the credentials file under /etc/dar. Not for expanding credentials file from template in pre-backup event or, as Shad suggests only in the conf-backup event, because I prefer code which updates only one reference (the config db), and derives from it the shell command parameters (the credentials file) each time that is needed and close by the calling code. "Une affaire de gout et de couleurs", as we said in french. But the two solutions are equally functional for SME, and the core team decides. So, agree with expand in conf-backup event (which is effectively called in backup function).
(In reply to comment #25) > Don't agree. I do. > As every configuration data, cifs login/password are stored in > configuration db when changed in the backup panel via the backuop function.. > But it's also perfectly legitimate, like for others conf db variables, to set > them via the db command in a console. Yes. And if you change the db via the command line, then you either need to do: signal-event post-upgrade ; signal-event reboot or you take full responsibility to know what templates need to be expanded and what actions need to be executed. > The credentials file is just a file needed during the mount.cifs command, and > it is logical (and has no drawback) to generate it from real effective db > values just before launching the cifs mount. No, I agree with Shad that it is logical to generate it whenever the data it contains might have changed. It's harmless, but unnecessary, to generate it any other time.
(In reply to comment #24) > (In reply to comment #22) > > Mounting the cifs folder job is not needed by the pre-backup event but by the > > workstation-backup-dar action (and also by the backup server-manager script). > > Getting the actual values of cifs login/password from configuration db must be > > made by them when the do the mount, not by any other event driven mechanism. > > All you are going to do in the mount is use a file that is already there. The > place you want to expand that file is where you change the values on the > database. It would make sense to expand that template as part of the > conf-backup event which is called when the panel is saved (or should be). Then > all you need is an event script in pre-backup to mount the share if the backup > type is workstation/dar. Don't agree. As every configuration data, cifs login/password are stored in configuration db when changed in the backup panel via the backuop function.. But it's also perfectly legitimate, like for others conf db variables, to set them via the db command in a console. SME configuration db variables are the real references, not the content of a file generated for command purpose. The credentials file is just a file needed during the mount.cifs command, and it is logical (and has no drawback) to generate it from real effective db values just before launching the cifs mount.
(In reply to comment #22) > Mounting the cifs folder job is not needed by the pre-backup event but by the > workstation-backup-dar action (and also by the backup server-manager script). > Getting the actual values of cifs login/password from configuration db must be > made by them when the do the mount, not by any other event driven mechanism. All you are going to do in the mount is use a file that is already there. The place you want to expand that file is where you change the values on the database. It would make sense to expand that template as part of the conf-backup event which is called when the panel is saved (or should be). Then all you need is an event script in pre-backup to mount the share if the backup type is workstation/dar.
(In reply to comment #22)> > Events rely on actions, not the opposite. Not really. Many of the actions do depend on the template expansion which is provided by the the templates2expand tree. Either technique will get the job done. > And the credential file, if we want security, must be resident in a secure > directory, accessed onle y by root. No, the file must be readable only by root, and the directory must not be writable by non-root, but there is no problem with other users having read and execute access to the directory. > /home/e-smith/db seems the right choice. It would be better in a directory you create within /etc. All the other files in /home/e-smith/db are db files, and you are also including this templated configuration file unnecessarily in the backup. No big deal either way.
I am also a supporter of event driven actions from SME, but I don't agree. Mounting the cifs folder job is not needed by the pre-backup event but by the workstation-backup-dar action (and also by the backup server-manager script). Getting the actual values of cifs login/password from configuration db must be made by them when the do the mount, not by any other event driven mechanism. workstation-backup-dar action and backup function should not rely on an event to get the credentials. Events rely on actions, not the opposite. And the credential file, if we want security, must be resident in a secure directory, accessed only by root. /home/e-smith/db seems the right choice.
what if you do it the same way as you did for DailyBackup.dcf cd /etc/e-smith/events/pre-backup/templates2expand/etc/dar touch SmbLogin.cred and create the template accordingly. i always liked the event driven approach of SME, it makes it well structured. expanding templates in the code works but is a different philosophy.
So, we should change the lines : < $err = qx(/bin/mount -t cifs "$smbhost:$smbshare" $mntdir -o nounix,user=$login,pass=$password 2>&1); with lines : > processTemplate({ > TEMPLATE_PATH => '/home/e-smith/db/workstationSmbLogin', > PERMS => 0640 > }); > $err = qx(/bin/mount -t cifs "$smbhost:$smbshare" $mntdir -o credentials=/ho me/e-smith/db/workstationSmbLogin,nounix 2>&1); and have a template file for /home/e-smith/db/workstationSmbLogin with the lines : username={$backupwk{'Login'}} password={$backupwk{'Password'}}
(In reply to comment #18) > > You won't. You'll see it there during the mount command. > > Was what I supposed. So don't see here a real security problem. Of course it is. Any exposure of the password makes the backup vulnerable.
> You won't. You'll see it there during the mount command. Was what I supposed. So don't see here a real security problem.
(In reply to comment #16) > (In reply to comment #15) > > > This may be the only way to be able to use any character but does make the > > password visible in the process table. > > Are you sure ? I don't see any info about USER and PASSWD in the process table > once the mount is done. You won't. You'll see it there during the mount command.
(In reply to comment #15) > This may be the only way to be able to use any character but does make the > password visible in the process table. Are you sure ? I don't see any info about USER and PASSWD in the process table once the mount is done.
(In reply to comment #14) > $ENV{'USER'} = $login; > $ENV{'PASSWD'} = $password; > $err = qx(/bin/mount -t cifs "$smbhost:$smbshare" $mntdir -o nounix 2>&1); This may be the only way to be able to use any character but does make the password visible in the process table.
I think a more simple way could be to change the line : > $err = qx(/bin/mount -t cifs "$smbhost:$smbshare" $mntdir -o nounix,user=$login,pass=$password 2>&1); with lines : > $ENV{'USER'} = $login; > $ENV{'PASSWD'} = $password; > $err = qx(/bin/mount -t cifs "$smbhost:$smbshare" $mntdir -o nounix 2>&1);
both scripts /etc/e-smith/events/actions/workstation-backup-dar /etc/e-smith/web/functions/backup can't handle shell special characters, the will both fail with a an error message similar to sh: -c: line 0: syntax error near unexpected token `(' sh: -c: line 0: `/bin/mount -t cifs "192.168.1.62:backup" /mnt/smb -o user=administrator,pass=xxxxxx(? 2>&1' umount: /mnt/smb: not mounted the shell special character case could be dealt with by putting single quotes around $password like root@sme73-dev - base-oti-backup-0.1 > cd /etc/e-smith/web/functions/ root@sme73-dev - base-oti-backup-0.1 > diff backup* 3048c3048 < return ( qx(/bin/mount -t cifs "$host:$share" $mountdir -o user=$login,pass='$password') ); --- > return ( qx(/bin/mount -t cifs "$host:$share" $mountdir -o user=$login,pass=$password) ); as stated before, comma is a whole different story, it disturbs the mount command and not the shell. to allow strong passwords and to keep exceptions for administrators at a minimum, my suggestion would be to create a credentials file via the templates meachnism and change the call to the mount command to use the "credentials" option instead of the "user" and "pass" ones.
(In reply to comment #11) > Bug 4529 which has just been marked as a duplicate was specifically about the > use of comma which appears to be a special case that has a workaround either > via the credentials file, or environment variable: > (http://linux.die.net/man/8/mount.cifs) Thanks Ian, did not find this that quickly.
Bug 4529 which has just been marked as a duplicate was specifically about the use of comma which appears to be a special case that has a workaround either via the credentials file, or environment variable: (http://linux.die.net/man/8/mount.cifs) "Note that a password which contains the delimiter character (i.e. a comma ',') will fail to be parsed correctly on the command line. However, the same password defined in the PASSWD environment variable or via a credentials file (see below) or entered at the password prompt will be read correctly."
*** Bug 4529 has been marked as a duplicate of this bug. ***
See also Bug 4906 Another bug that would not have been raised if some password checking was done in the panel.
I thought about this possibility, but : - the pannel does not assign a password, it just gathers an existent information - if an admin has succesfully put this password on the workstation share, it will be difficult for him to understand why sme doesn't want to read it on the panel So if we want to prevent such passwords we must give the admin a comprehensive feedback ans ask him to change the pasword on the workstation share.
I'm going to re-open this as the Backup panel should not accept passwords that we know are not acceptable. On one page you have to select your backup method, in this case cifs Then on the next page you enter the password. I would recommend that this is then checked and only accepted if valid for mount.cifs
Moving back to SME Server tracker.
Marking FIXED in http://wiki.contribs.org/index.php?title=SME_Server%3ADocumentation%3AAdministration_Manual%3AChapter10&diff=11803&oldid=11772 Although I am not sure if there does not need to be some escaping/urlencoding as I am unfamiliar with the script.
(In reply to comment #3) > Thanks Jean-Paul. Yes, thanks indeed. > Looking at the mount.cifs man page I see that other characters are also taboo. > I understand now that this is not a SME bug, and the workaround is to use a > different password. > > I guess the best action would be to document what to avoid. The errors give > little clue to what is going on and I would like to help other avoid the hours > of frustration I have just spent. > > I now know exclamation marks, commas and leading spaces are taboo, is anyone > aware of others? Moving to DocTeam as this should be documented in the Manual: http://wiki.contribs.org/SME_Server:Documentation:Administration_Manual:Chapter10#To_desktop
Thanks Jean-Paul. Looking at the mount.cifs man page I see that other characters are also taboo. I understand now that this is not a SME bug, and the workaround is to use a different password. I guess the best action would be to document what to avoid. The errors give little clue to what is going on and I would like to help other avoid the hours of frustration I have just spent. I now know exclamation marks, commas and leading spaces are taboo, is anyone aware of others?
Backup to workstation is no more maintained as a contrib. The code is in e-smith-backup. But for the reported problem, it's not a sme bug, but a mount.cifs problem that we cannot resolve in sme.
Backup in 7.4 is based on DAR, a Contrib and not core SME7xx. Moving to contrib section