Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 2 subscribers
  • Views 5444 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unable to configure SMB share for log archiving

JonEtkins
I'm trying to configure ASG to archive my logs to a share on my local NAS.  It allowed me to enter the necessary parameters when I initially set it up, but I subsequently discovered I made an error in the share definition.  However, now when I try to apply the updated information, the WebAdmin interface blinks a red box around the Host field and pops up the following message in red text:
Cannot apply changes:
conflicting data types for specified node


The host definition I'm using is not used anywhere else.  I've also tried creating a completely new host definition, and I've also tried both Host and DNS Host definitions; it won't accept any of them.

Any and all suggestions welcomed!

Thanks.


This thread was automatically locked due to age.
  • 0
    Further information:

    I've also tried changing from SMB to FTP or SSH archiving, but I get the same error message for those, too.  The only archiving method it will let me save is e-mail; any method that requires a host fails with that same message.

    Anyone?  Bueller?
  • 0
    I see you have 4 NICs.  Any chance the host is on a different interface and the necessary packet filter rule isn't yet in place?  Do you see anything blocked in the pF live log?

    Also, if there's nothing in the PF log, you might check Intrustion Prevention.

    Cheers - Bob
    PS One of my favorite Ben Stein quotes  [;)]
  • 0 in reply to BAlfson
    Thanks for replying, Bob.

    Of my four NICs, only three are in use:


    • WAN - self-explanatory.  Default route; public address (DHCP)
    • Guest - connected only to a loosely secured WAP which provides internet access for house guests.  192.168.1.1/24; DHCP and DNS servers; NAT'ed to WAN; no access to LAN at all.
    • LAN - our private network.  192.168.0.1/24; NAT'ed to WAN; includes my existing server which provides DHCP and DNS for LAN clients and DNAT'ed web, ftp, email, and a couple of other services.

    The NAS is on the LAN segment.  I can ping it fine, and this is the only place I'm trying to define it; it's not NAT'ed or shared across segments at all.  I've tried changing the definition to bind it explicitly to the LAN interface; makes no difference at all.

    I see nothing in any of the logs when this happens.

    I see you have 4 NICs.  Any chance the host is on a different interface and the necessary packet filter rule isn't yet in place?  Do you see anything blocked in the pF live log?
  • 0
    They say the first sign of madness is repeating the same steps expecting a different result, but that's exactly what just happened.  As I was repeating the same steps over and over while examining the live logs, all of a sudden it started accepting my input!

    Or at least it says it has.  I get a green "Changes have been applied successfully" message, but the Host field reverts to what was there before, not the updated value that it claims it just accepted. [:S]

    When I try a test connection, I get the following:

    loginuser@astaro:/home/login > logarchiver.plx -t -d 15
    DEBUG: **************************************************
    DEBUG: logarchiver.pl ($Revision: 1.33.2.1.2.1 $)
    DEBUG: Options:
    DEBUG:  - debug mode: 15
    DEBUG:  - remote archive testing run
    DEBUG: **************************************************
    DEBUG: * doing remote storage test...
    DEBUG: - writing test file: /opt/tmpfs/remote-log-test.txt
    DEBUG: - storing test file...
     INFO: - doing remote storage via smb
    DEBUG: found data: (key:REMOTE_HOST) 192.168.0.8
    DEBUG: found data: (key:REMOTE_USER) backup
    DEBUG: found data: (key:REMOTE_PASS) ******xx
    DEBUG: found data: (key:REMOTE_SHARE) Backups\Astaro
    DEBUG: smbclient //192.168.0.8/Backups\Astaro -U backup%******xx -W tower -c put /opt/tmpfs/remote-log-test.txt remote-log-test.txt
    DEBUG: file exists: yes
    params.c[:$]penConfFile() - Unable to open configuration file "/etc/samba/smb.conf":
            No such file or directory
    /usr/sbin/smbclient: Can't load /etc/samba/smb.conf - run testparm to debug it
    Domain=[TOWER] OS=[Unix] Server=[Samba 3.3.7]
    tree connect failed: NT_STATUS_BAD_NETWORK_NAME
     WARN: couldn't store logfile archive remotely! Error code was: 1
    DEBUG: -> failed!
    loginuser@astaro:/home/login >


    So the symptoms have changed, but the end result - broken SMB archiving - remains.

    I feel a support case coming on. [:(]
  • 0
    OK, after pounding on it for another couple of hours, I believe I've got to the root of the problem...

    According to the online help, 
    Share: SMB share name. Enter the path or the network share information where the log files are to be transferred to, e.g. /logs/logfile_archive.


    However, if you specify a subdirectory (per that example) it causes the connection to barf because ASG fails to parse out the subdirectory and pass it to the smbclient command correctly.  Instead of 
    smbclient //192.168.0.8/Backups/Astaro_logs -U backup%******xx -c put /opt/tmpfs/remote-log-test.txt remote-log-test.txt
     it needs to break out the subdirectory into a separate -D parameter:
    smbclient //192.168.0.8/Backups -D Astaro_logs -U backup%******xx -c put /opt/tmpfs/remote-log-test.txt remote-log-test.txt


    As far as I can see, the only way around it at the moment is to define another SMB share at the desired subdirectory. [:(]  I'll raise an enhancement (and documentation change) request.
  • 0
    the only way around it at the moment is to define another SMB share at the desired subdirectory.

    Since I haven't tried this, I want to say this in a different way to be certain I understand what to do: the only way this works is when the share is the exact subdirectory that is to contain the archive - no pathing is possible in the definition in the Astaro.  Is that right?

    Thanks for documenting your results! - Bob
  • 0 in reply to BAlfson
    the only way this works is when the share is the exact subdirectory that is to contain the archive - no pathing is possible in the definition in the Astaro.  Is that right?
    That's correct, as it stands in 7.504.  Astaro will allow you to specify a subdirectory, but if you do so then SMB archiving will fail.