Jump to content
XPEnology Community

Schmill

Member
  • Posts

    148
  • Joined

  • Last visited

Posts posted by Schmill

  1. Ok, so my connection log is full of the messages "User [foo] from [1.2.3.4] failed to log in via [ssh] due to authorisation failure".

     

    So - I expect this on an internet connected machine, but what I don't understand is the [sSH] part... Does Synology report HTTPS connections as [sSH] as far as the logs are concerned?

     

    I have only one port forwarded on my router (at the moment), and that is 5001 for the HTTPS version of DSM access.

     

    Just wondering if this is a quirk of the reporting, or if I have a hole somewhere in my setup that I'm not aware of...

     

    Thanks :smile:

  2. Hi guys, I've been following this PCI-E card 'from the shadows' - glad to see it worked :smile:

    I presume you are using the white connector on the card to provide the additional power - what is the black connector for?

     

    Also - as you are running DSM5.1-4528 baremetal, as I am now, have you had any issues with the drives not spinning down? My seem to refuse to spin down and I'm not sure why...

     

    Thanks :smile:

  3. Many thanks Spammy.

    I don't NEED to be able to access my DSM via the internet, but it would be nice to be able to, whether for sharing links, streaming media when I am away etc, so I presume that nanoboot is the path I should probably take then?

    I think the safest bet will be for me to start 'fresh', is there a handy link to the nanoboot installation instructions? (If not I shall go trawling through the threads :smile: )

     

    Thanks :smile:

  4. Unfortunately I've been 'out of the scene' for a period of time, during which my N54L has been powered down, and stuck in limbo.

    As I never quite got it setup correctly I am more than happy to pull my (limited) existing user data off of it, and start again, but my query is... where to start?

     

    With the heartbleed issue, the various updates from syno, which either stop systems working, or cause other issues, I'm now at a loss as to where, what and how I should start again.

     

    Can anyone give me some pointers please?

     

    TIA :smile:

  5. I'm not sure if anyone has tested to see if maybe it is just a serial number check? I own a Synology NAS, and I gave my ESXI Xpenology the SN of my offline real NAS and the MAC of my offline real NAS, and it seems like features such as the buildt in dynamic DNS etc all work for me.

     

    My N54L is using a 'real serial' number which meant that the builtin dynamic dns all worked for me, but I don't know if that will let 4482 work as I have held off the upgrade due to posts on here.

  6. So....

     

    What with the fact that my DSM install has been misbehaving, and the recent Heartbleed issue, I figure now is a good time to update.

     

    So first things first, I take a full backup of my data drive.

     

    Then what? I'm presuming there isn't an 'upgrade path' as such, so which DSM5 install should I go for?

    Trantor: viewtopic.php?f=14&t=2219

     

    or:

     

    gnoBoot: http://cyanlabs.co.uk/news/install-xpen ... thout-esxi

     

    ??

     

    It 'looks' like the gnoBoot uses a later version of the pat file, but I'm unsure. I just want to update my server, but keep my current MAC addresses AND SERIAL number, or at least know how to change them back to what I am currently using after the install finishes.

     

    If someone can guide me as to which install I am supposed to use these days I'll get on with it :smile:

     

    Many thanks!

  7. Today I received a notification that my DS had lost comms with Synology server, but then it came back and I thought nothing more about it until this evening when I tried to access my server, only to find out that I couldn't access the shares.

     

    Logging into the web interface and checking the logs I see that Volume2 (my main drive) has apparently crashed, but bizarrely it is also reported in the logs as having been removed?!

     

    Looking at the Storage Manager my second drive (and volume) is no longer even listed, as if it is not even in the system.

     

    How do I go about getting it back? I've seen posts about people doing repairs etc on their drives, but the server isn't even seeing the drive...

     

    Any ideas?

     

    Log snippet included below incase it contains any clues :sad:

     

    Many thanks!

     

    Information,System,09/04/2014 14:58,SYSTEM,System successfully registered [86.3.250.202] to [myserver.myDS.me] in DDNS server [synology].
    Information,System,09/04/2014 14:58,SYSTEM,System successfully registered [86.3.250.202] to [myserver.no-ip.biz] in DDNS server [NoIP.com].
    Error,System,09/04/2014 12:47,SYSTEM,System failed to register [0.0.0.0] to [myserver.myDS.me] in DDNS server [synology] because of [ ].
    Information,System,09/04/2014 12:37,SYSTEM,System successfully registered [86.3.250.202] to [myserver.myDS.me] in DDNS server [synology].
    Information,System,09/04/2014 12:37,SYSTEM,System successfully registered [86.3.250.202] to [myserver.no-ip.biz] in DDNS server [NoIP.com].
    Error,System,09/04/2014 12:04,SYSTEM,System failed to register [0.0.0.0] to [myserver.myDS.me] in DDNS server [synology] because of [bad parameter].
    Information,System,09/04/2014 12:04,SYSTEM,System successfully registered [0.0.0.0] to [myserver.no-ip.biz] in DDNS server [NoIP.com].
    Error,System,09/04/2014 11:24,SYSTEM,Volume [2] was crashed.
    Information,System,09/04/2014 11:24,SYSTEM,Windows file service was started.
    Information,System,09/04/2014 11:24,SYSTEM,Windows file service was stopped.
    Warning,System,09/04/2014 11:23,SYSTEM,Disk [2] was removed.
    Error,System,09/04/2014 11:23,SYSTEM,"System volume [swap] was degrade, current disk status [1/12], please repair it."
    Error,System,09/04/2014 11:23,SYSTEM,System volume [Root] was crashed.
    Information,System,09/04/2014 11:08,SYSTEM,System successfully registered [86.3.250.202] to [myserver.myDS.me] in DDNS server [synology].
    Information,System,09/04/2014 11:08,SYSTEM,System successfully registered [86.3.250.202] to [myserver.no-ip.biz] in DDNS server [NoIP.com].
    Information,System,09/04/2014 09:14,SYSTEM,System successfully registered [86.3.250.202] to [myserver.myDS.me] in DDNS server [synology].
    Information,System,09/04/2014 09:14,SYSTEM,System successfully registered [86.3.250.202] to [myserver.no-ip.biz] in DDNS server [NoIP.com].
    Error,System,09/04/2014 09:09,SYSTEM,System failed to register [0.0.0.0] to [myserver.myDS.me] in DDNS server [synology] because of [bad parameter].
    Information,System,08/04/2014 11:08,SYSTEM,System successfully registered [86.3.250.202] to [myserver.myDS.me] in DDNS server [synology].
    Information,System,08/04/2014 11:08,SYSTEM,System successfully registered [86.3.250.202] to [myserver.no-ip.biz] in DDNS server [NoIP.com].

  8. Aha :smile:

     

    If you don't mind me asking, how do you know that?

     

    Also, is there anyway to tell it not to bother? - lol

     

    Because when I was trying to get HA working, you could see it was failing with that error

     

    So I gather when the REAL Synologies are setup in HA mode....then the LCD's change to reflect the STATUS or Name or IP Address or Master / Slave etc of the HA setup.

     

    .

    That makes sense except.... what is "HA mode" ? :oops: - lol - Thanks :smile:

     

    I see this is x-posted on the Synology forum :lol:

     

    Yup, as I was unsure as to whether it was an XPenology issue, or an underlying Synology issue - Turns out it was Synology :razz:

  9. Just in case anyone is following this, I have now solved it :smile:

     

    It seems that the 'QuickConnect' option had been turned on for DSAudio ("Control Panel" --> "Quick Connect").

    However it seems that THAT requires Cloud Station to be installed, which I do not have.

    Disabling the 'QuickConnect' option for DSAudio has stopped the error in the messages log, and my drives now seem to spin down as they are supposed to :smile:

     

    However, now that the 'noise' is gone from my messages log, I can see these entries:

     

    Feb 24 11:42:26 scemd: write to uart2 error, error=(5)Input/output error
    Feb 24 11:59:12 scemd: write to uart2 error, error=(5)Input/output error
    Feb 24 12:39:14 scemd: write to uart2 error, error=(5)Input/output error
    Feb 24 13:11:53 scemd: write to uart2 error, error=(5)Input/output error
    Feb 24 17:37:50 scemd: write to uart2 error, error=(5)Input/output error
    Feb 24 19:01:34 scemd: write to uart2 error, error=(5)Input/output error

     

    Presumably that is a side-effect of running the DSM on an N54L (which I don't believe has any UARTS, but what is it trying to do, (or how would I go about finding out?)

     

    Thanks :smile:

  10. It seems the number in the square brackets is a red herring, as it is now a different number, seems the only relevant bit is the '563' which I presume is the line number generating the error.

     

    I have now killed and restarted the deamon in debug mode (synorelay -k, closely following by synorelayd -d and I get the following:

     

    synorelayd -d
    success -> starting
    Feb 22 17:13:30 2014 daemon.cpp:379 daemon start
    success -> login
    Feb 22 17:13:30 2014 register.cpp:57 register clear previous data
    Feb 22 17:13:30 2014 register.cpp:287 check: audio_http
    Feb 22 17:13:30 2014 register.cpp:287 check: audio_https
    add request: https://ukc.synology.com:443/Serv.php [{"auth":{"mac":"<>","serial":"<>","timezone":"Dublin","token":"<>"},"command":"register","version":1},{"command":"update_network","ddns":"<>","gateway":"192.168.22.1","interface":[{"ip":"192.168.22.10","mask":"255.255.255.0","name":"eth0"}],"mode":"","version":1},{"command":"update_service","service_add":[{"id":"audio_http","port":5000},{"id":"audio_https","port":5001}],"service_rm":[],"service_update":[],"version":1}]
    Feb 22 17:13:30 2014 synorelayd.cpp:874 select 10...
    Feb 22 17:13:30 2014 jobqueue.cpp:201 queue check done jobs. running: 1 (1)
    tunnel[0]:
    Feb 22 17:13:30 2014 synorelayd.cpp:874 select 10...
    Feb 22 17:13:30 2014 jobqueue.cpp:201 queue check done jobs. running: 1 (1)
    tunnel[0]:
    Feb 22 17:13:30 2014 synorelayd.cpp:874 select 10...
    Feb 22 17:13:30 2014 jobqueue.cpp:201 queue check done jobs. running: 1 (1)
    tunnel[0]:
    Feb 22 17:13:30 2014 synorelayd.cpp:874 select 10...
    Feb 22 17:13:30 2014 jobqueue.cpp:201 queue check done jobs. running: 0 (1)
    ===> register response: (0)[{"version":1,"command":"register","errno":2,"errinfo":"RegDS.php:230"}] [AUTH]err_auth
    Feb 22 17:13:30 2014 synorelayd.cpp:203 save php session
    Feb 22 17:13:30 2014 synorelayd.cpp:563 regist command auth error
    err_auth -> login
    Feb 22 17:13:30 2014 synorelayd.cpp:704 auth expired: 1, server chagned: 0
    Feb 22 17:13:30 2014 register.cpp:57 register clear previous data
    Feb 22 17:13:30 2014 register.cpp:287 check: audio_http
    Feb 22 17:13:30 2014 register.cpp:287 check: audio_https
    err_auth -> stoped
    tunnel[0]:
    Feb 22 17:13:30 2014 synorelayd.cpp:874 select 10...
    Feb 22 17:13:40 2014 jobqueue.cpp:201 queue check done jobs. running: 0 (1)
    tunnel[0]:
    Feb 22 17:13:40 2014 synorelayd.cpp:874 select 10...
    Feb 22 17:13:50 2014 jobqueue.cpp:201 queue check done jobs. running: 0 (1)
    tunnel[0]:
    Feb 22 17:13:50 2014 synorelayd.cpp:874 select 10...
    Feb 22 17:14:00 2014 jobqueue.cpp:201 queue check done jobs. running: 0 (1)
    tunnel[0]:
    Feb 22 17:14:00 2014 synorelayd.cpp:874 select 10...
    Feb 22 17:14:10 2014 jobqueue.cpp:201 queue check done jobs. running: 0 (1)
    tunnel[0]:
    Feb 22 17:14:10 2014 synorelayd.cpp:874 select 10...
    Feb 22 17:14:20 2014 jobqueue.cpp:201 queue check done jobs. running: 0 (1)
    tunnel[0]:
    Feb 22 17:14:20 2014 synorelayd.cpp:874 select 10...
    Feb 22 17:14:30 2014 jobqueue.cpp:201 queue check done jobs. running: 0 (1)
    tunnel[0]:

     

    Looks like the particular bit of interest is this:

     

    ===> register response: (0)[{"version":1,"command":"register","errno":2,"errinfo":"RegDS.php:230"}] [AUTH]err_auth
    Feb 22 17:13:30 2014 synorelayd.cpp:203 save php session
    Feb 22 17:13:30 2014 synorelayd.cpp:563 regist command auth error
    err_auth -> login
    Feb 22 17:13:30 2014 synorelayd.cpp:704 auth expired: 1, server chagned: 0

     

    Other than the 'built-in' spelling mistakes, it looks like it is when the server is trying to do some kind of registration, but I have no idea what this is.

    I've changed my DDNS at sinology and noip to be every 30 mins, and yet this 'error' still occurs every 10 minutes...

     

    Any idea on what the server is trying to do every ten minutes? I did check /etc/crontab but I couldn't see anything listed in there.

     

    Thanks for any information :smile:

  11. Does anyone know what synorelayd is, or what it might be trying to do on my system?

     

    I realised that my drive(s) didn't seem to be spinning down anymore, and checking /var/log/messages reveals pages and pages of the following entry:

     

    Feb 14 00:04:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 00:14:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 00:24:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 00:34:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 00:44:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 00:54:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:04:29 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:14:29 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:24:30 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:34:30 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:44:30 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:54:30 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 02:04:30 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 02:15:28 scemd: write to uart2 error, error=(5)Input/output error
    Feb 14 02:19:50 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 02:35:23 synorelayd[7871]: synorelayd.cpp:577 regist stop: relayd_err: 2 (52)
    Feb 14 02:35:42 scemd: write to uart2 error, error=(5)Input/output error
    Feb 14 02:45:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 02:55:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:05:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:15:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:25:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:35:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:45:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:55:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:05:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:15:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:25:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:35:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:45:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:55:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 05:05:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 05:15:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error

     

    I'm not sure what the uart errors are about, but I'm presuming that the original DS hardware has something connected to it via serial that is not available on the N54L.

     

    However the major issue here does seem to be the synorelayd entries.... but I have no idea what they are referring to, so don't know what I can do about it.

     

    Any ideas anybody?

     

    Also this obviously refers to a particular line in a source file of the DSM system... but where can I get the source? I wouldn't mind a look through it myself.... :smile:

     

    Thanks again!

  12. Does anyone know what synorelayd is, or what it might be trying to do on my system?

     

    I realised that my drive(s) didn't seem to be spinning down anymore, and checking /var/log/messages reveals pages and pages of the following entry:

     

    Feb 14 00:04:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 00:14:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 00:24:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 00:34:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 00:44:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 00:54:28 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:04:29 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:14:29 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:24:30 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:34:30 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:44:30 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 01:54:30 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 02:04:30 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 02:15:28 scemd: write to uart2 error, error=(5)Input/output error
    Feb 14 02:19:50 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 02:35:23 synorelayd[7871]: synorelayd.cpp:577 regist stop: relayd_err: 2 (52)
    Feb 14 02:35:42 scemd: write to uart2 error, error=(5)Input/output error
    Feb 14 02:45:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 02:55:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:05:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:15:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:25:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:35:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:45:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 03:55:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:05:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:15:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:25:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:35:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:45:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 04:55:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 05:05:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error
    Feb 14 05:15:23 synorelayd[7871]: synorelayd.cpp:563 regist command auth error

     

    I'm not sure what the uart errors are about, but I'm presuming that the original DS hardware has something connected to it via serial that is not available on the N54L.

     

    However the major issue here does seem to be the synorelayd entries.... but I have no idea what they are referring to, so don't know what I can do about it.

     

    Any ideas anybody?

     

    Also this obviously refers to a particular line in a source file of the DSM system... but where can I get the source? I wouldn't mind a look through it myself.... :smile:

     

    Thanks again!

  13. Ok - I apologies if this is a stupid question, and I can't believe I don't already know this, but....

     

    I have connected an external USB drive to my N54L, which then shows up as a share folder "usbshare1" when I navigate the N54L from my Windows laptop across the network.

     

    If I use my Windows laptop to COPY files from the external USB drive (connected to the N54L) TO another shared folder (on the N54L) how is the data actually transferred?

    Is the process intelligent enough to realise that the data is already on the correct machine, or will it route Off the external drive (connected to the N54L), onto the network connection, via wireless to my laptop, which will then redirect it back across the wireless, back through the network to the N54L and onto its shared folder?

     

    The whole point of me connecting the USB drive directly to the server was to remove the 'slow' wireless link from the equation, but if the above routing happens then I've gained nothing (in fact may have made it worse as it now goes from server to laptop, and back again!).

     

    I presume if I log into the web interface and use File Station to do the copying then it will do it directly, but I was unsure if I could do it by using Explorer on the laptop (which is somewhat more user friendly).

     

    Thanks :smile::oops:

  14. Ok - I apologies if this is a stupid question, and I can't believe I don't already know this, but....

     

    I have connected an external USB drive to my N54L, which then shows up as a share folder "usbshare1" when I navigate the N54L from my Windows laptop across the network.

     

    If I use my Windows laptop to COPY files from the external USB drive (connected to the N54L) TO another shared folder (on the N54L) how is the data actually transferred?

    Is the process intelligent enough to realise that the data is already on the correct machine, or will it route Off the external drive (connected to the N54L), onto the network connection, via wireless to my laptop, which will then redirect it back across the wireless, back through the network to the N54L and onto its shared folder?

     

    The whole point of me connecting the USB drive directly to the server was to remove the 'slow' wireless link from the equation, but if the above routing happens then I've gained nothing (in fact may have made it worse as it now goes from server to laptop, and back again!).

     

    I presume if I log into the web interface and use File Station to do the copying then it will do it directly, but I was unsure if I could do it by using Explorer on the laptop (which is somewhat more user friendly).

     

    Thanks :smile::oops:

×
×
  • Create New...