Topic: [SOLVED] Connecting to a NFS share for backups.

[TerryF]

NAS as in the generic term which covers all forms

OK, so just making sure they were on same subnet.

With the first statement above in mind have you tried changing the NAS setting for "Map all users to root" I see default is yes have you changed it? Have you tried setting it to Yes?

[DanB35]

NASMonkey, I understand you're using NAS4Free rather than FreeNAS, but hopefully the experience of someone using FreeNAS can be useful.  Here's my SME server configuration:

Code: [Select]

[root@e-smith ~]# config show backupwk
backupwk=service
    BackupTime=23:00
    Compression=0
    CompressionProg=gzip
    DaysInSet=7
    FullDay=5
    IncNum=3
    IncOnlyTimeout=yes
    Login=
    Password=
    Program=dar
    SetNum=3
    SetsMax=4
    SmbHost=192.168.1.10
    SmbShare=mnt/tank/newsme
    Timeout=8
    VFSType=nfs
    status=enabled


[LANMonkey]

Here is where we should have been able to stop.

That worked.

Now I am getting a different error:

No directory for your host in shared folder. Maybe your host name is different from backup ones

I had some confusion over the "authorized network".  My LAN is like 123.123.123.1, 123.123.123.2, etc.  So I assume the setting is 123.123.123.0/24.  Right?

The shares I have set up are /mnt, /mnt/TEST.

What else might be causing a problem?

"No directory for your host in shared folder. Maybe your host name is different from backup ones"

When I go into the server-manager, I select "Verify workstation backup".  I try that and get the error, "No directory for your host in shared folder. Maybe your host name is different from backup ones".

Ah, but I haven't made a backup yet, I only want to verify that I can make a backup.  When you actually make a backup, the backup creates a backup directory for your host.  This explains the report, it can't find a directory to verify a backup has been made.

When I actually test the connection from the command line in SME, I'm getting a connection, mount -t nfs 192.168.1.3:/mnt/nfs /TEST" works.  I can read files in the imported directory.

I have configured a backup and ran a test backup, and my email cron reports from do_backupwk:

"Backup terminated: pre-backup failed - status: 256"

But I'm ready to post this thread [SOLVED] based on the correction and the fact that I can make a connection from the command line.

Still, can anyone explain why the backup failed?

One of the things I see on my NAS is that I have mounted the data partition of the NAS on the exact same directory that I am mounting using nfs for the SME backup.  So the backup directory is /mnt/TEST and the mount for the data partition is also /mnt/TEST.

And also, there is only 32GB available on this little experimental NAS4Free installation and both the MySQL database and the website files is pretty big.  Can anyone tell me how to see how much space the backup would need?  That might finish this up.

I would like to suggest an option in the Backup or Restore page dropdown menu to actually verify the connection, rather than verify an existing backup

[DanB35]

And also, there is only 32GB available on this little experimental NAS4Free installation and both the MySQL database and the website files is pretty big.  Can anyone tell me how to see how much space the backup would need?  That might finish this up.

On the Backup and Restore panel in the server manager is an estimate of the disk space used by the configuration and data files on your system, and the note that twice that amount of space is needed on the backup share.

I would like to suggest an option in the Backup or Restore page dropdown menu to actually verify the connection, rather than verify an existing backup

I agree, and I'm pretty sure a bug report has already been filed suggesting this, but I can't find it at the moment.

[LANMonkey]

Sure enough, it's right there.  I see 5GB necessary, so I should have enough space.

I am looking at "messages" in the logs and I see a backup error related to mysql.

"Dec 11 09:11:03 finch esmith::event[3611]: mysqldump: Got error: 1044: Access denied for user 'root'@'localhost' to database 'information_schema' when using LOCK TABLES"

I'm checking my old email, and this problem predates storage problems, so this should be the subject of another thread, if I can't fix it myself.

End of thread and problem.

Thanks to all who posted, there were definitely things that had to be fixed.  Despite the occasional gotchas, SME is still the greatest.

[TerryF]

Smacks forehead..it would have been handy to have had that info at the start..

The wiki tells it all, it would be of benefit to have a close read - Workstation Backup/Verify Backup

There is a multitude of references in the forums and bugzilla, eg Bug 6921 relating to that error, all clues

In particular there will be log entries associated with the pre-backup event..

I think its time you flew solo..good luck