Mail failure notice after setting it up correctly?

No one? :(

Hi all,

I have the same problem on ReadyNAS NV+ v2.
Seems that the username "root" to which the NAS tries to send the message to is hardcoded somehow.
Any idea? :idea:

Cheers
Andy

So, after 2 hours of investigation, here's the issue... Followed by my ranting...

The readynas v2's seem to use msmtp to send email. Its supposed to be a lightweight mailer to replace sendmail and postfix. By default, if you don't give it a domain to send from msmtp defaults to "localhost". Most mail servers won't allow mail from that domain to be relayed through it as it increases the chances that the mail server can be used as a mail relay for spammers. However, looking at the man page, one can add a domain line to /etc/msmtprc and mail will work from the command line. This is my msmtprc file with the domain line. Note that if you edit it manually, and then update the front view UI, it will remove the entry as it doesn't know about the setting:

root@backup-nas:/frontview/lib# cat /etc/msmtprc 

defaults
tls on
tls_nocertcheck

logfile /var/log/frontview/msmtp.log

account default
connect_timeout 60
host xxx.domain.com
port 587
from myuser

auth cram-md5
user myuser
password mypass

domain domain.com

Sending from the command line looks like this:

root@backup-nas:/frontview/lib# /usr/sbin/sendmail -B8BITMIME -f from-addr@domain.com authuser to-user@domain.com
abcd1234
root@backup-nas:/frontview/lib# 

It sends fine. I got the string from /frontview/bin/functions (send_email_alert function to be precise). For some reason when I use the front view UI, I still can't send a test email... So, it looks like front view is a bit wasteful and has its own mail routines. digging around the UI directories a bit and apache config, it looks like all the important bits are somewhere in /frontview/lib. Now here is the catch... Readynas has encrypted all their Perl files and completely obfuscated their stuff...

So bottom line... its broken on the readynas side of things... and we as users can't fix it. Only the readynas engineers can. Now for my rant directed at the engineers...
* The new v2 GUI looks nice, but has no functionality. The v1 GUIs look back but are way more customizable. Examples: I can turn on and off individual file sharing services per share (such as afp, smb/cifs, http, rsync). I can't do that in the v2 version. Why not?
* If I make a change via ssh to the system I would expect it to persist in a firmware update. I get it. You don't support us mortals doing anything via ssh, but with a completely limited GUI and no ability to do what I want without it, ssh is the only way. (I do backups over ssh and to do encryption on the disk needed some deb packages installed. Firmware updates blow it all away and break everything). An alternate approach it to put your stuff on your own partition and anything you want to persist beyond firmware updates on a different one. This is debian (or a spin off). it is possible.
* Don't make it impossible to debug things by obfuscating everything. When I look at the source of the UI in my web browser i get a bunch of gobbledygook. Your perl is encrypted? Seriously? All I want to do is fix a problem and get email working. You're making it impossible.
* This was the last readynas I buy. The product has gone downhill, and in todays day and age there are literally dozens of companies making workgroup sized NAS devices. I love the ReadyNas line and the fact that I can swap in and out disks on the fly to replace bad ones or grow the filesystem, and I like the fact that I get alerted on disk or other issues out of the box. But in today's day and age any workgroup NAS can do that. Why should I stick with ReadyNAS? I should be allowed to extend the functionality and fix things openly.

Sigh... End rant.
Scott

Hi guys,
The obfuscated code has nothing to do with these mails. it is sent by cron daemon.When cron starts a process, it captures any output that reaches stdout and stderr, and sends that in an email.
The messages you saw is just warnings, don' t worry about it.
You can add MAILTO="" in /etc/crontab to avoid sending mails, like the following:
# cat /etc/crontab
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=""

# m h dom mon dow user command
17 * * * * root cd / && run-parts --report /etc/cron.hourly
35 20 * * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6 * * 7 root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6 1 * * root test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )
#