elmuziko

Sorry if this is in the wrong area; Running Synology on ESXi 6.7. As we know this means not being able to access SMART data from Synology itself. I've got the SMART data out from bash, but what I'm curious to know is, is it possible to run a full SMART test at all? In Synology you can perform long tests, in Windows WDC has an app to perform a full scan, is there anything of this nature available to us for ESXi? And if so, does anyone know how to do it? Thanks

I'd still take a permanent fix to this any day of the week but getting around it for the time being using those steps albeit from the Synology site, to chmod wherever it is I'm going to, using winSCP as a standard user, then chmod back to what it was previously. It's not clean, nor is it straight forward, but it is a work around. Again, if someone has a more permanent fix I'd take it any day of the week. Thanks

Yo, has anyone got an idiots guide to enabling root on 6.2? I use winSCP to transfer files but can't do it any more since directories are locked down. i found a guide on YouTube however on my etc/ssh/sshd_config, PermitRootLogin is set to prohibit-password. Making the changes in the questions just makes the ssh service stop and won't come back up. Thanks

Ended up having to rebuild, a misplaced letter on a mdadm switch formatted the whole lot.

Morning all, DSM 5.2 user here - for the most part - works great, but when something happens to the Hyper-V host it often fails spectacularly. Today is one of those days. I'm not great at under the hood stuff but have Google'd around and come to the conclusion the whole thing is confused! I only have one RAID5 with 7 disks in total which seems to correspond to mdadm --detail /dev/md2. Can anyone give me any guidance on how to bring the volume back to life? SuperSyno> mdadm --detail /dev/md3 /dev/md3: Version : 1.2 Creation Time : Sun Apr 1 20:22:22 2018 Raid Level : raid5 Array Size : 3906971648 (3725.98 GiB 4000.74 GB) Used Dev Size : 976742912 (931.49 GiB 1000.18 GB) Raid Devices : 5 Total Devices : 4 Persistence : Superblock is persistent Update Time : Fri Dec 21 07:52:22 2018 State : clean, degraded Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K Name : SUPERSYNO:3 UUID : e3f844f6:4bd70c27:c40439c2:8d1a29e9 Events : 12216 Number Major Minor RaidDevice State 0 8 70 0 active sync /dev/sde6 1 0 0 1 removed 4 8 150 2 active sync /dev/sdj6 5 8 118 3 active sync /dev/sdh6 2 8 134 4 active sync /dev/sdi6 SuperSyno> mdadm --detail /dev/md0 /dev/md0: Version : 0.90 Creation Time : Sat Jan 1 00:04:42 2000 Raid Level : raid1 Array Size : 2490176 (2.37 GiB 2.55 GB) Used Dev Size : 2490176 (2.37 GiB 2.55 GB) Raid Devices : 12 Total Devices : 8 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Fri Dec 21 08:08:09 2018 State : clean, degraded Active Devices : 8 Working Devices : 8 Failed Devices : 0 Spare Devices : 0 UUID : 26aa5fea:f6cb55b4:3017a5a8:c86610be Events : 0.5720 Number Major Minor RaidDevice State 0 8 33 0 active sync /dev/sdc1 1 8 49 1 active sync /dev/sdd1 2 8 145 2 active sync /dev/sdj1 3 8 129 3 active sync /dev/sdi1 4 8 113 4 active sync /dev/sdh1 5 8 97 5 active sync /dev/sdg1 6 8 81 6 active sync /dev/sdf1 7 8 65 7 active sync /dev/sde1 8 0 0 8 removed 9 0 0 9 removed 10 0 0 10 removed 11 0 0 11 removed SuperSyno> mdadm --detail /dev/md1 /dev/md1: Version : 0.90 Creation Time : Thu Dec 20 22:46:39 2018 Raid Level : raid1 Array Size : 2097088 (2048.28 MiB 2147.42 MB) Used Dev Size : 2097088 (2048.28 MiB 2147.42 MB) Raid Devices : 12 Total Devices : 8 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Thu Dec 20 22:47:37 2018 State : active, degraded Active Devices : 8 Working Devices : 8 Failed Devices : 0 Spare Devices : 0 UUID : 3637e4b4:d5bb08ce:dca69c88:18a34d86 (local to host SuperSyno) Events : 0.19 Number Major Minor RaidDevice State 0 8 34 0 active sync /dev/sdc2 1 8 50 1 active sync /dev/sdd2 2 8 66 2 active sync /dev/sde2 3 8 82 3 active sync /dev/sdf2 4 8 98 4 active sync /dev/sdg2 5 8 114 5 active sync /dev/sdh2 6 8 130 6 active sync /dev/sdi2 7 8 146 7 active sync /dev/sdj2 8 0 0 8 removed 9 0 0 9 removed 10 0 0 10 removed 11 0 0 11 removed SuperSyno> mdadm --detail /dev/md2 /dev/md2: Version : 1.2 Creation Time : Sun Apr 1 20:22:22 2018 Raid Level : raid5 Array Size : 20478048192 (19529.39 GiB 20969.52 GB) Used Dev Size : 2925435456 (2789.91 GiB 2995.65 GB) Raid Devices : 8 Total Devices : 7 Persistence : Superblock is persistent Update Time : Thu Dec 20 22:34:47 2018 State : clean, degraded Active Devices : 7 Working Devices : 7 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K Name : SUPERSYNO:2 UUID : 7d8b04cf:aebb8d01:6034359b:c4bb62db Events : 280533 Number Major Minor RaidDevice State 9 8 53 0 active sync /dev/sdd5 1 8 69 1 active sync /dev/sde5 2 0 0 2 removed 7 8 149 3 active sync /dev/sdj5 8 8 117 4 active sync /dev/sdh5 5 8 133 5 active sync /dev/sdi5 4 8 101 6 active sync /dev/sdg5 3 8 85 7 active sync /dev/sdf5 SuperSyno> mdadm --detail /dev/md3 /dev/md3: Version : 1.2 Creation Time : Sun Apr 1 20:22:22 2018 Raid Level : raid5 Array Size : 3906971648 (3725.98 GiB 4000.74 GB) Used Dev Size : 976742912 (931.49 GiB 1000.18 GB) Raid Devices : 5 Total Devices : 4 Persistence : Superblock is persistent Update Time : Fri Dec 21 08:01:56 2018 State : clean, degraded Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 64K Name : SUPERSYNO:3 UUID : e3f844f6:4bd70c27:c40439c2:8d1a29e9 Events : 12218 Number Major Minor RaidDevice State 0 8 70 0 active sync /dev/sde6 1 0 0 1 removed 4 8 150 2 active sync /dev/sdj6 5 8 118 3 active sync /dev/sdh6 2 8 134 4 active sync /dev/sdi6

Looks like it crashed. Turned it off and on again, it sat at BUSY Re-Scanning disks for twenty minutes, then moved on to starting services for an hour, then finally back in. Hooorah!

Hi everyone. So I've had a bit of a nightmare with my Xpenology and would welcome any advise to get things up and running again. About 2 weeks ago my DSM wanted to data scrub. I left it going over night and the next day found errors. It transpired the system did an update during the scrub and rebooted itself. Sigh. I repaired the RAID, only it transpired a disk had become unhappy, so I bought a replacement. Whilst trying to track down which one was dead I noticed the SATA card on my windows 10 machine (I run Hyper-V) was using basic drivers, so I updated that and the drive re-appeared. Problem is when the disk reappeared, it screwed up the order of all the disks on my Hyper-V machine, so I had to remove them all, then re-add them. Now, 48 hours later (to the hour), my DSM is still sat at the error message below... re-scanning disks. I have 22TB of available space (SHR so I have redundancy too) so there's a part of me that believes (hopes) it's just doing a pre OS scan and making sure everything is healthy. But 48 hours seems a long time to be sat at this screen with no signs of any other services. It's not showing up on my router, short of this image I wouldn't think it was doing anything. Is it safe to turn off and on? Should i turn it off and on? Any help would be appreciated. Thanks

Afternoon all, Anyone have any ideas on how to bring a volume back to life after a crash during drive expansion? I'm using 5.2 on Hyper-V. I was adding a new hard drive, it got to about 10% then I lost power to the Hyper-V host. When my machine came back up it said it'd crashed. I didn't panic so much, it started an integrity check that took just over 24 hours. Once it completed it didn't come back to life. I took the extra disk out, tried again, nothing. When I reboot, I get: "The system has detected one or more crashed storage spaces. Please check the following expansion units and hard disks are connected properly and functioning normally: [Disk 5, Disk 8, Disk 10, Disk 11]. When I got into Storage Manager I get: "Unable to use this volume. The data in the volume may be crashed. Please try to back up the data before removing the volume." I literally have no idea where to start. When I use my own account to SSH into the box it drops off immediately. I enabled my admin account and can now get into the box via Putty. My folder structure still exits in Volume1/@eaDir, but it literally is just the folder structure. Any help would be massively appreciated. If there's any log files I need to provide, just say so! Edit: SUDO apparently isn't installed.

By the looks of things it seems I'm one of the few (maybe the only one?) that hasn't found Salah troll like at all. Uncouth perhaps, and hasn't figured out how to use edit rather than reply, but not a troll. This post suggests a method around the QuickConnect kick yes? Surely that's helpful? I use VPN myself so don't know if such a thing has actually happened. And even if said person is a Synology employee, wouldn't we want that kind of inside information on the board? To give us a heads up on the direction they're taking?

If you have a few pennies available to you, get a new router, one that supports VPN. I uses an ASUS myself, most of the options in there are easy to understand so you can make your network fairly hardy. As for Syno security, have a look at: https://www.synology.com/en-uk/knowledg ... nology_NAS Even with all that in mind I still wouldn't set your Syno up to face the internet (as in open ports on your firewall and be able to log in from the outside world). A few years back there was a nasty program called SynoLocker that smashed through DSM ransomware style. ( https://forum.synology.com/enu/viewtopic.php?t=88770 ) It's better not to take the risk and instead connect to your machine via a VPN. There's this to look at too. It won't do a thorough scan of your network but it'll graze over the top in the same way a none targeted hacker would looking for an easy catch : https://pentest-tools.com/

No, not really. The best responses on StackOverFlow are the ones that come with an explanation into what each step does. Perhaps the manner in which the question was asked may have come across rude but remember we all have a common goal on here, to further progress Xpenology. The ones that deserve so little of the developers time are the selfish a******* that come on here as just an IP address, download what they need and contribute naff all, not even a thank you. Anyone signing up to the forum to comment (short of the spammers!) at the very least recognises the hard work Trantor and co have put into getting this up and running, even if it's just to say "it don't work innit". But anyway... I certainly don't mean to sound argumentative so apologies if it comes across that way.

Wouldn't package updates or even DSM updates go via this?

Can You write a sort of howto? i think will be usefull Agreed. There was a guy on here, can't remember his name for the life of me, that spent a lot of time building his own website with tutorials and videos on how to get DSM 5 onto just about any machine you wanted. https://cyanlabs.net/tutorials/ Although it's probably going a little far asking for videos, fluent guides with easy to understand steps pave the way for more people to get involved.

Maybe that's because there is almost no documentation about how to make a bootloader. If there are some good docs on how to build an image, maybe more volunteers will show up. Uhm... That's not true. The current loaders are nothing more than Syno's own boot solution (which you can easily reverse engineer if you buy a syno product and take a look around its inside working), paired with Grub (which has plenty of documentation), and a custom solution to get around their protection (which again, if was documented, Syno would patch in no time). No offense, but being spoon-fed all the information is not the way to become a developer. I'd argue otherwise. My job is almost entirely PowerShell based and the only reason I'm any good at it is because of StackOverFlow, Technet and tearing other people's scripts to pieces. We all have to start somewhere; as a Hyper-V user I, and the many Hyper-V users on site, feel overlooked in our quest to get on DSM 6+. Having some documentation and how to guides to at least get acquainted would make heller difference. Also, I can't imagine a world where Syno aren't already aware of how their protection isn't broken. If notepad ++ can check changes between documents, you can be sure as s*** Syno have already tore Jun's loader to shreds and found every change down to the last byte. More importantly you'd want them to, so they can build a better and more protected system. Which again means more developers working against the product would make it easier to unlock the next release.

I have an all mighty custom built rig with Windows 10 pro on top, Hyper-V and DSM sitting inside. At it's very basic this allows me to run Kodi from Windows 10 which in turn accesses all media from DSM. I also have several VM's making up a domain for work related purposes. There's no reason why I have DSM at all, I don't really need it since Sab, Sick, PHP can run from Windows. But it's a force of habit and I like it.