TomS.

Intel's AHCI 1.3 specification [1] states that an AHCI controller must support 32 devices. The Supermicro support page for the AOC-SAS2LP-MV8 Linux driver source link [2] references a mv94xx. On my installation, "find / -iname mv*" returns a listing for an mvsas.ko, but no mv94xx. I don't how to determine version info for kernel modules to see if that module has proper support for your card. Looking at your mainboard, out of the 4 PCI-E slots, only 1 & 2 are x8 link capable even though the slots are full x16 length. You state " the 3rd controller is basically not recognized by the BIOS." Since the storage HBA is PCI-E x8, might that be relevant to your troubleshooting? Best of luck, Tom S. [1] http://www.intel.com/content/www/us/en/ ... /ahci.html [2] ftp://ftp.supermicro.com/driver/SAS/Mar ... al_source/

The first two lines "UDP failed to set…" appear related to an installed program, "Transmission". I'm inclined to agree with your judgment on the kernel lines starting @ 09:31. I'm definitely not a developer or hardware debugger, so don't put too much faith in that agreement. Perhaps you could do a little research on the Intel mainboard you have and the chipset, particularly the southbridge. Compare that with your dmesg output. See if there are more recent drivers than what shipped with the last boot update. //TS

Wonderful, glad it worked. I suspect you'll experience much improved disk performance. I've verified that you do have the latest BIOS for that board. Don't see anything else to change in that regard. With no add in cards, I wonder why those 3ware lines were in the messages log? Doesn't seem relevant now. Best of luck on your new system. //TomS.

Same with me. I'm at my very beginning starting with https://docs.docker.com/engine/getstarted/.

I see a couple of potential investigation points: Starting with the Linux ATA wiki [1], ata-piix is for an Intel ICH in IDE emulation mode. ata_qc_issue, from your 1st message log, is preparing a command to issue to a device from [2] I'd address the IDE emulation issue first. Verify that the BIOS is set to SATA native (AHCI) for all storage controllers and not any of the legacy or compatibility modes. * * Caution: changing controller modes is a _destructive_ action. It will invalidate all disk contents. You _must_ repartition / reformat / reinstall DSM. If indeed the storage controllers were in Emulation, then changing the mode will change the driver to ahci from ata_piix. If the system was encountering a piix bug, now it has been avoided by using a different driver. Judging from your previous post, there is also a 3ware hardware RAID controller in this system. Because of the invalid superblock message in your previous post, it appears that at least some drives are connected to the 3ware controller? May I ask you to report the following info: Intel Motherboard model # and BIOS revision mainboard SATA controller mode from BIOS Manufacturer and model of any add-in controller card Add-in card firmware controller mode drive make, model, firmware revision and SATA connection point (mainboard port # or add-in port #) [1] https://ata.wiki.kernel.org/index.php/Main_Page [2] https://kernel.org/doc/htmldocs/libata/ ... issue.html

I don't know enough about Samba to tell whether the options are "right" or not. In the extensive output from smbd -b, I see --with Options: […] WITH_ADS […] WITH_DNS_UPDATES It looks like Synology kept Samba 4.x's internal DNS server as well as the option to use external BIND dynamic loading zones. > samba_upgradedns --help Usage: upgradedns [options] Options: -h, --help show this help message and exit --dns-backend= The DNS server backend, default SAMBA_INTERNAL I like the Docker container for the AD DC for three reasons: The ability to run a current, supported version of Samba >4.2.x. There are a lot of fixes between DSM's 4.1.18 and 4.4x. Microsoft and Samba recommend against File & Print services on the same host as a Domain Controller. With the DC in a container, and joining the DSM Samba to the container hosted AD, that separation is achieved. Additionally, one isn't performing tasks in the CLI that might get undone by the GUI. I was looking at it natively on DSM to get acquainted with Samba. How's your Docker container knowledge?

Greetings all, DSM 5.2.5967 Update 2 ships with Samba 4.1.18. >smbd -V Version 4.1.18 Synology Build 5967, Apr 26 2016 17:22:47 Samba 4.x is capable of acting as a standalone Active Directory Domain Controller, AD Directory Services in Windows Server Role terms. Build option indicate AD_DC is enabled >smmd -b Build environment: Built by: root@build1 Built on: Tue Apr 26 17:22:21 CST 2016 Built using: /usr/local/i686-pc-linux-gnu/bin/i686-pc-linux-gnu-ccache-gcc Build host: Linux build1 3.14.30-1-lts #1 SMP Fri Jan 30 13:27:48 CST 2015 x86_64 GNU/Linux SRCDIR: /source/samba-4.x/source3 BUILDDIR: /source/samba-4.x/source3 […] Build Options: AD_DC_BUILD_IS_ENABLED Attempting to provision the AD DC according to tha Samba wiki HOWTO yields python script errors that appear to involve directory locations. Like the BTRFS effort, it seems that there is a gap between features available, and those exposed in the web gui. I'm aiming to get the AD DC to work in DSM, or run a current Samba > 4.4 in a Docker container, and join the DSM instance to that AD. I'd love to hear any ideas. Thanks for any and all help. //TomS.

@holybabel, Thank you. Perfect information. Big difference in your Supports Wake-on: results: Supports Wake-on: pumbg I'm curious to see reports from Realtek and Broadcomm Nic's now. Look's like a NIC upgrade is in the future.

Greetings all, For those with working Wake-On-LAN (WOL), has anyone configured their NAS to wake on a unicast packet instead of the default magic packet? ethtool -s eth0 wol u The above command returns to the prompt with no feedback for my nForce 430. A look at the adapter status shows that wol is unchanged at Ma"g"ic Packet. nas-ftw> ethtool eth0 Settings for eth0: Supports Wake-on: g Wake-on: g Link detected: yes I suspect other wake modes have not been implemented in forcedeth, Nvidia's nForce 4 driver for Linux because of the "Supports.. line. Other OS, same NIC, will wake up on unicast. e.g. Windows | Device Manager | nforce nic | Wake on Lan | Allow this device to wake the computer, and _not_ checking only allow a magic packet to wake. I'd appreciate any reports of the output from below for other NIC hardware. ethtool & ethtool -i for NIC standard information and driver version. This is a home system. My goal is to let it sleep after some inactivity, ACPI S3 suspend to RAM, wake up within 30sec when any client attempts a transaction (media, file, print), then fall back asleep. For longer periods of inactivity, it already hibernates properly. Thank you in advance.

@berwhale +1 for IBM article.

Wow, how right you were! I did as you suggested: Thanks, luck sure helps. What does parted's "align opt "n"" where n is each of the labels on the disk report? In particular does it agree that the partitions is aligned? @berwhale, do you know why parted reports sector sizes of 512 bytes physical / 512 bytes logical for the HGST NAS drives when they are Advanced Format Disks, 4096 bytes physical / 512 logical? A pure guess is all I can offer. A quick search indicates that it was a past practice for drivers to allocate /dev/hd(x) to parallel ATA drives and /dev/sd(x) to SCSI & SATA drives. Current practice is apparently to allocate all fixed disks as /dev/sd(x). I'm guessing that there are many dependencies on /dev/hda, so it is aliased to /dev/sda and retained for compatibility.

Ilciumba, On my XPE box, uname -rs returns "Linux 3.10.35" and parted returns "GNU Parted v3.1". Both values are more than sufficient for Advanced Format Drive support. I'm not up to par on *nix and *nix like OS, but have a fair amount of experience on other platforms. There are a number of posts on askubuntu about Gparted bugs and AFD disks, no real good answers too much blame. I just started searching the gnu bug-parted mailing list @ http://lists.gnu.org/arc.hive/html/bug-parted/. Maybe you'll have better luck finding an answer than I have so far. I belive one key answer from a developer may be that parted gets the logical & physical sector values from the kernel. It doesn't query the drive itself. Yes, I did note your output from /sys/class/block/sda/queue/physical_block_size at 4096 bytes. I don't know how parted queries the kernel for its information. May I ask you to please repeat your parted output, (print list) for sda-f, but setting the units to bytes (units B) to eliminate rounding? That way we can divide starting sector by 4096 and at least confirm good alignment if it returns integers. Would you also consider the output of parted's align, e.g. align opt 1, for each partition on each sample disk? These are my results from a 250GB x2 quick disk setup creating 1 volume, SHR with data protection, no disk groups in Storage Manager. (parted) unit B unit B (parted) print list print list Model: SAMSUNG SP2504C (scsi) Disk /dev/hda: 250059350016B Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1048576B 2551054335B 2550005760B primary raid 2 2551054336B 4698537983B 2147483648B primary raid 3 4831838208B 250052100095B 245220261888B extended lba 5 4840079360B 249945178111B 245105098752B logical raid Model: SAMSUNG SP2504C (scsi) Disk /dev/sda: 250059350016B Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1048576B 2551054335B 2550005760B primary raid 2 2551054336B 4698537983B 2147483648B primary raid 3 4831838208B 250052100095B 245220261888B extended lba 5 4840079360B 249945178111B 245105098752B logical raid Model: SAMSUNG SP2504C (scsi) Disk /dev/sdb: 250055122432B Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1048576B 2551054335B 2550005760B primary raid 2 2551054336B 4698537983B 2147483648B primary raid 3 4831838208B 250052100095B 245220261888B extended lba 5 4840079360B 249945178111B 245105098752B logical raid Model: Linux Software RAID Array (md) Disk /dev/md0: 2549940224B Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0B 2549940223B 2549940224B ext4 Model: Linux Software RAID Array (md) Disk /dev/md1: 2147418112B Sector size (logical/physical): 512B/512B Partition Table: loop Disk Flags: Number Start End Size File system Flags 1 0B 2147418111B 2147418112B linux-swap(v1) Error: /dev/md2: unrecognised disk label Model: Linux Software RAID Array (md) Disk /dev/md2: 245104050176B Sector size (logical/physical): 512B/512B Partition Table: unknown Disk Flags: Just a quick glossary note: Advanced Format Drives are 4096 physical sector, but report 512 logical sector, aka 512e or 512 emulation drives. 4k Native report 4096 physical and 4096 logical.

Absolutely agree. The datasheet for the HGST https://www.hgst.com/products/hard-drives/nas-desktop-drive-kit drives in question are silent on the topic though. There is an HGST Advanced Format Technology Brief https://www.hgst.com/sites/default/files/resources/AFtechbrief.pdf that discusses HGST drives and relevant operating system support. It emphasizes that Gparted 2.1 or later be used. I must gently disagree. For all operating systems and disk arrangements, sector size matters. For single disks, the minimum file system allocation unit must be a multiple of the sector size. Otherwise, misaligned allocation units will cause two sectors to be read / modified / written whenever a file system allocation unit crosses a 4k sector boundary. For multiple disk arrangements, the array stripe size must be a multiple of the drive physical sector size. I believe there should also be a relationship between stripe size and file system allocation unit size as well. I can't recall it offhand. Fundamentally, make sure the start of each label / partition / volume, whatever the OS calls it is 4k aligned.