Jump to content

page3

Members
  • Content Count

    125
  • Joined

  • Last visited

Community Reputation

2 Neutral

About page3

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ok, makes sense. Thanks for the explanation, it really is appreciated.
  2. Thank you. That at least points me in a direction to investigate. Assume the issue with the drive firmware is only apparent with the latest kernel on Unraid 6.8. Taken a long read of the issue, and to be honest it’s way above what I understand. There does not appear to be an updated firmware version for the drive and it isn’t obvious how to contribute to the discussion (or even if it is allowed). A possible way of mitigating the issue is suggested in the thread - rate limit the transfer. This can be done in Borg by doing the following https://github.com/borgbackup/borg/issues/661 which I’ll try to see if it helps. In the meantime, if anyone is able to shed light on if this issue would affect my backups I’d be grateful. They do appear to still be working. Thanks again and obviously close the thread if you feel it is no longer an Unraid issue, although I’d welcome any further help!
  3. Hi Had 6.8 RC3 running beautifully for a few days, but have noticed I'm getting the following log entries when backing up to sda: Oct 22 03:15:01 Tower root: Starting Borg Backup - movies Oct 22 03:15:10 Tower kernel: sd 0:0:0:0: [sda] Unaligned partial completion (resid=78, sector_sz=512) Oct 22 03:15:12 Tower kernel: sd 0:0:0:0: [sda] Unaligned partial completion (resid=78, sector_sz=512) Oct 22 03:15:14 Tower kernel: sd 0:0:0:0: [sda] Unaligned partial completion (resid=78, sector_sz=512) Oct 22 03:15:16 Tower kernel: sd 0:0:0:0: [sda] Unaligned partial completion (resid=78, sector_sz=512) Oct 22 03:15:18 Tower kernel: sd 0:0:0:0: [sda] Unaligned partial completion (resid=78, sector_sz=512) Oct 22 03:15:20 Tower kernel: sd 0:0:0:0: [sda] Unaligned partial completion (resid=78, sector_sz=512) Oct 22 03:22:57 Tower root: Started Borg Pruning - movies [sda] is an external WD MyBook 8Tb drive connected via USB3 and mounted via Unassigned Drives (XFS formatted). Backup is via Borg Backup (1.1.10) and has been working without these messages prior to 6.8. The drive appears to pass smart and the backup appears to work. The backup logs also reports success. 6.7 does not give these log entries. I've googled the issue, but to be honest it's a bit beyond me. Suggestions / advice would be helpful.
  4. Hi all, I've recently started getting martian reports in the Unifi USG logs, such as: Sep 29 04:54:35 UniFiUSG kernel: IPv4: martian source 107.201.130.93 from 172.17.0.4, on dev eth1 Sep 29 04:54:35 UniFiUSG kernel: ll header: 00000000: 78 8a 20 40 b8 ed 70 10 6f 3e 03 08 08 00 x. @..p.o>.... 172.17.0.4 is the bridge IP address of the Unifi Controller docker. In trying to track this down (and understand what it is telling me) I thought it possibly a good idea to change the docker from host mode to custom (eth0) with a fixed IP and all ports left as the are. Is this a sensible configuration? I have Pihole configured like this and it works well. All other dockers are in bridge mode. Clearly i'd also need to change the controller IP etc from within the Unifi controller settings. I have asked on the UniFi forum, but this is more docker/unraid specific as a first step in helping identify the issue.
  5. page3

    Martians!

    Hi all, I have an UnRAID box running 6.7.2 with a number of dockers - Plex, UniFi Controller, PiHole to name a few. Recently, on the UniFi USG logs I am seeing martian messages: Sep 28 10:10:59 UniFiUSG kernel: IPv4: martian source 51.255.195.31 from 172.17.0.4, on dev eth1 Sep 28 10:10:59 UniFiUSG kernel: ll header: 00000000: 78 8a 20 40 b8 ed 70 10 6f 3e 03 08 08 00 x. @..p.o>.... Sep 28 10:30:23 UniFiUSG kernel: IPv4: martian source 98.118.121.62 from 172.17.0.4, on dev eth1 Sep 28 10:30:23 UniFiUSG kernel: ll header: 00000000: 78 8a 20 40 b8 ed 70 10 6f 3e 03 08 08 00 x. @..p.o>.... The MAC address is that of my UnRAID box. eth1 is my LAN port. However, 172.17.0.4 is not in use by the server, or by any of the dockers which has left me confused! The UniFi Controller docker uses 172.17.0.4. Tautulli uses 172.17.0.2 but that's it according to the dockers page details. Anyone got any suggestions for tracking this down further?
  6. My Raspberry Pi install of Pihole failed last night due to a corrupted SD card, but I was able to get Pihole back up and running within 5 minutes using this docker. Thank you! The instructions on page 1 of this thread (and also the cron post further down) are a bit confusing in light of version 2. Apart from installing and configuring the docker, is there any other set-up/maintenance necessary? Is the cron still necessary? Are updates done via the docker update mechanism or from within the docker with PiHole -up?
  7. That an interesting observation and one I hadn’t considered. I swap between external drives, taking one offsite so the window of attack is lessoned, if not eliminated. I’ll have to consider if I change my backup practice, or if I’m willing to take the (small imho) risk. Thanks for the clarification.
  8. Essential plugin that's given me years of hassle-free use... I have an external (USB) Segate drive that I use with Duplicati for backups. It is mounted via Unassigned Devices and spins up when a backup is executed and down again after. All is well. I have a new WD MyBook (8tb USB) drive I want to use in the same way. However, it is being temperamental in spinning down when not required. By default the WD has its own power management and APM is set to off. If I use hdparm to set the timeout and enable APM it works for a bit, then resets itself (seemingly randomly after an hour or so, I know it would on server reboot). If I use the built in WD power management it spins down as instructed, but up again at random times. The drive is not being accessed as I only use it for backups at 4am. If I go to the web UI "main" page at any time I always get a pause on the Unassigned Devices section while the drive spins up. The Segate drive behaves perfectly and doesn't do this. Anyway, I'm not expecting a magical solution to this, but with a bit of help I think I have a workaround. If I unmount the device it seems to stay spun-down. I've searched but cannot find a way to mount (and unmount) via the command line. I'm sure it must be possible. I could then add a pre (and post) Duplicati script to mount before a backup and unmount after, which should sort things. Any help with the command I could use to mount (a previously configured drive in Unassigned Devices) would be really helpful. Thanks.
  9. I don't get this comment. It's a backup. It may not be offsite, but it's definitely a backup! Anyway, I have a WD MyBook USB drive attached to my box for on-site backups. It's mounted via Unassigned Devices and backup is via Duplicati (with one backup kicking off each night). I want it spun down the rest of the time. I've found the following works: hdparm -B 127 /dev/sdb hdparm -S 12 /dev/sdb First command switches on power-management. Second sets spin down to 2 minutes. I've had the put these commands in /boot/config/go as they don't persist after a reboot. I've also found that viewing the webUI 'main' screen spins the disk back up, which is a shame but liveable with unless anyone can suggest a way to avoid this. Interestingly I have another drive attached in exactly the same way (Segate external) and this does spin down without any of this. It also doesn't spin up as the WD does when I view the web ui so the WD must be responding to something Unassigned Devices is sending. I hope this is helpful to the OP.
  10. Have I done something stupid? I was running 5.8.30 fine. UnRAID did it's usual weekly update earlier today and now I get the following error on running the controller: "We do not support upgrading from 5.8.30." Any ideas? UPDATE: RESOLVED. Repository had reverted to stable branch. Re-added "unstable" and all is well.
  11. Wow, quick response! Unfortunately, the other docker only keeps logs within the appdata folder, everything else must be within the docker image which seems a bit unusual. This is why I'm keen to move to the Linuxserver.io one. I'm hoping I can do a config back from within the UniFi controller app (.unf file). I can then hopefully import that once I get to the Set-up screen on the UniFi controller on this docker. *** UPDATE *** Just for information. I installed the Linuxserver.io docker. Restored the .unf file from my previous docker and all is up and running in under 5 minutes. I now have my config on my cache in an accessible place, rather than from within the docker image.
  12. Hello all. If I wanted to move from the other UniFi controller docker to this one, is there a "simple" migration path? Can I simply backup my old config from within the UniFi controller app, install this docker, disable the old docker, run up this one and import my config? I'm trying to avoid having to set everything up from scratch again as it was a right pain last time! Many thanks
  13. Excellent. Thank you. One more question if I may. I have automatic backups ON. The backup goes to a backup location within the docker (see below). The docker currently maps: /var/lib/unifi -> /mnt/cache/appdata/unifi/ I thought I could simply add a new route for the backup to expose an external location to the docker, eg: /usr/lib/unifi/data/backup/autobackup -> /mnt/cache/appdata/unifi/autobackup (note the /usr rather than /var) The /var/lib/unifi seem to contain the server.log only. The /usr/lib/unifi seems to contain everything else! When starting the docker with the new path added, the UniFi controller had lost all my settings. Removing this mapping fixed things, but obviously auto backups are back to being within the docker image. I believe the question was asked back in April (by lchichiarelli) but I can't find what the resolution was. ps. Happy Christmas!
  14. A question about the UniFi Controller docker if I may. I've just purchased a USG and Pro access point. Totally new to Unify stuff so took it slowly. Installed Docker. Ran through set-up of Controller software. Followed UniFi instructions to SSH on to the USG and change the IP address to be on the same subnet as my Unraid server. Adopted the USG. Disconnected old router. Adopted access point. All great and working brilliantly. Then I was an idiot. Saw in Unraid there was a docker upgrade. Hit Upgrade. Upon returning to the controller software it appeared to be a fresh install? Wanted me to run set-up again or restore from backup. Backup? I am an idiot - no backup yet. Ok, can "transfer" to new controller using admin login/password. Idiot 2™. Safari auto-fill has screwed up my admin password so it wasn't accepted. Ok. Factory reset of both USG and Access Point. Re-install of docker. Would it adopt? Course not. After two hours SSHing in to USG, changing IP and trying to adopt I eventually restored my old router and followed the instruction AGAIN right from the beginning. Adoption fine. Hurrah. Absolutely no idea why my old router was needed, assume routing wasn't correct without it. Made a backup. Quite a few actually. So my question (see, there is one eventually) is What is the recommended update process for the UniFi controller docker? Is it backup -> update -> restore or should the controller remember its settings? I'd just like not to go through this again! Ps. Thanks for the docker. It's excellent. It's just this user who was an idiot.