bsim

Normally the request for an ip would use the same hostname used for the SMB. In this case, unraid requested an IP address using a different host name than the one using the SMB service (reverted to default tower). The incorrectly requested hostname conflicted with a windows box on the network. The router did have the unraid mac address registered to the tower hostname, resolving to the unraid box. The unraid server has been named something else for years, through many reboots. I do understand how wonky/slapdash the SMB as a protocol is, but the question is why would this have happened.

That's correct. The IP registered to tower in DHCP is also browse-able through SMB. Releasing and renewing the conflicting tower system and rebooting the server again caused everything to revert back to correct ip/hostnames. All I can guess at this point is that unraid went looney when it conflicted with the other system. Something between SMB and the dhcp client. I guess time will tell if it happens again. But to have a hostname change to default because of a conflicting network name? Very odd.

Running latest 6.2.4, have a DHCP lease for "Tower" even though unraid machine was renamed a LONG time ago. But because unraid is the SMB Master, I can still access the SMB through the renamed machine name. Is there a way to see if there are multiple instances of the smbd that is possibly using a default config? I do notice that the newly created (recent unraid update) "domain.cfg" file has a 'SERVICE="enable"' line...is this an smb service? adding "server string = NEWNAME" in my smb-extra.conf does not help. Also verified that "NAME="NEWNAME" is in my ident.cfg where is this DHCP request getting associated with "tower"?

I'm still getting a traced error when trying to clear a new 5tb drive. The error crashes the server completely even though the I've changed controller ports, I've changed controllers, it checks out fine on a windows system using the seagate diags (smart). Changed the drive over to an internal sata port on the motherboard, and so far it's preclearing fine. Sooo...researching sata_mv...it is a "rare bug" that I'm dancing around...From the sata_mv.c documentation...https://github.com/yandex/smart/blob/master/drivers/ata/sata_mv.c 44 * 80x1-B2 errata PCI#11: 45 * 46 * Users of the 6041/6081 Rev.B2 chips (current is C0) 47 * should be careful to insert those cards only onto PCI-X bus #0, 48 * and only in device slots 0..7, not higher. The chips may not 49 * work correctly otherwise (note: this is a pretty rare condition). So now the question is how do I tell if I have Rev B2 chips or C0 chips...I have the Revision 3 version of the cards, and can't see anything on the chips with those designations. The latest bios is 1.0b and they've all been updated. I'll have to check if the cards are able to be on bus #0....I'm thinking they are all on bus 3 from the startup drive checks. Has anyone had any experience with these cards?

Has anyone seen a bad controller port or a single port go bad on a backplane without affecting other ports? I swapped out what I thought was a bad drive, plugged it into a windows machine and used diskinternals app to read the contents, and it reads and works fine. Plugged in a new 5TB drive into the same bay and I am still having problems during the preclear. The preclear of the drive gives me a hard error that completely brings down the server (as before), requiring hard reboot. I will probably swap the SATA cable out for that bay just to be sure as well. Perhaps i will swap controller ports for that bay to verify a controller or backplane issue.

Wow...after digging for hours, finally ended up being a drive in the array that detects fine, sounds fine, but the onboard drive controller causes something in either the controller driver or something deeper that caused the hard error. I have never seen a drive cause that much havoc on a system without showing symptoms first. The problem had me worried my backplane, motherboard/mem/proc that was going or something crazy like a bad sata cable. With how many drives I have in the array, the easiest thing to do was pull half the drives, attempt boot, pull half of those, attempt boot....finally found it. In case it matters, it was a Seagate Barracude 3TB ST3000DM001 from 2013. The error does not have anything to do with the version of unraid as I tried with a fresh, 6.1.9, and finally have it up and running minus one drive on 6.2.1. Sucks to have so many variables changing with something so strange.

Been wrapping my head around this one...It all boils down to there being something that causes a problem supporting all three (2 work fine in any slot) of my SuperMicro AOC-SAT2-MV8 cards (PCI-X 64bit slots 100/133 mhz). To test, I backed up my flash, installed a fresh 6.2.1 with no modification, remove all three of my MV8s, configure the sd with my pro key...accepts fine and shows my two on boad old cache drives. Shutdown, install 1 card, boot fine, 2 cards boot fine, 3rd...get hard error. Even moving slots does not change the error and swapping in a spare MV8 does not change it. I've been running 6.2 for a while prior to the 6.2.1 upgrade and nothing but a reboot from the automatic update started the problem. It does not get far enough to dump an error file to the flash, the MV8 bios's show the detection of all drives as normal. The point that the issue happens is just after it appears unraid goes through each drive. I have a video of the problem and a screen shot of the final error with the second screen shot with the cards moved down a slot. I'm in the process of trying 6.1.9 just to verify, if it does work fine, I would love to find a direct link to make sure that the bug is after 6.2.

I've been running 6.1.9 for a while, but recently within the last few weeks, i've been getting slowdowns copying things to the array with a cache drive present over the network from a windows machine. Looking through the system log, I see several things that might point to a drive or a controller going bad? If i restart, the slow copy speeds are still there, but if i disable the cache drive writing, I go back up to 60 or 70 mb/s... Running the mover script works fine if i wait for the data to copy at the slow rate. Any ideas? unraid-syslog-20160624-0028.zip

So I got a new UPS (CP1500PFCLCD), Shows up in UPS Settings nicely, but I'm trying to figure out if the shutdown will call the powerdown (package 2.20) or will do a hard shutdown. Does powerdown already take over the default shutdown call? Is there somewhere that I can force it to use powerdown for graceful shutdown?

I wouldn't do that, that would take the package out of the update chain through the mirrors. Just link to the mirror list or list multiple locations in the package request.

Yes, the www site shows the listing, but the download still stalled and died, any download from the utah site dies. I found a meta4 file that had a list of mirrors for the download. i downloaded the infozip, moved it to where the install script was saving it to, installed the package, installed the unraid package and everything went through flawlessly. The script should find a way to access the mirrors instead of relying on one server.

I don't know if they are down temporarily or being hit hard, but the v5 to v6 upgrade script tries to download infozip from slackware.cs.utah.edu and it is just retrying over and over...even attempting to go directly to http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/slackware/a/infozip-6.0-i486-1.txz or http://slackware.cs.utah.edu/pub/slackware/slackware-13.37/slackware/a/infozip-6.0-i486-1.txz gives me a download that stalls to a standstill. I can't find any other location for this file, so I'm guessing manual upgrade (windows flash extraction of 6.0.1 zip file) will be my only method...I will try again tomorrow in case they are just down for maint. Terminal Message: --2015-08-02 23:13:06-- (try:16) http://slackware.cs.utah.edu/pub/slackware/slackware-13.1/slackware/a/infozip-6.0-i486-1.txz Connecting to slackware.cs.utah.edu (slackware.cs.utah.edu)|155.98.64.87|:80... failed: Connection timed out. Resolving slackware.cs.utah.edu (slackware.cs.utah.edu)... 155.98.64.87 Connecting to slackware.cs.utah.edu (slackware.cs.utah.edu)|155.98.64.87|:80... failed: Connection timed out. Retrying.

After doing a bit of playing...something wonky and intermittent the command line smbpasswd is changing /etc/samba/private/smbpasswd and /etc/samba/private/passdb.tdb the password location in unraid seems to be /boot/config/smbpasswd and /boot/config/shadow /usr/bin/smbpasswd -a username -D 1 -c /boot/config/smbpasswd entering new password, (after changing the wrong location), cp'ing it to the flash location then update the password through the web interface to the new password updates /boot/config/shadow and /boot/config/smbpasswd I'm guessing that the command line is changing something necessary other than the smbpasswd that is not being updated by the webgui. Both changes seem necessary for Win7 clients to login to shares. Could an in place update previously have caused some incompatibility?

alpha numeric 12 characters password... flash drive definitely not read only, i'm able to change my smb shares config through a flash drive share. Is there a way to do it manually beyond what i've already tried?

Running 5.0.6 and when attempting to change a (non root) user password through the web interface, after typing the correct password twice and applying, it shows the smb restarting, but the password for the user is not being changed. I tried straight smbpasswd -a USER from the console, but it doesn't save either. Any ideas?

I understand ext3 is not xfs...just attached the quotes of file systems and their free spaces from around the net. I'm guessing that I will migrate to XFS after 6 goes stable. I have heard of a lot of odd bugs occurring in btrfs and everyone loving xfs until btrfs stables out. Hopefully, there won't be too bad of an upgrade path going to 6.

From other documentation, it looks like XFS may be around 5%, but I'm still researching... Quoting from my research... "My experience is that 'ext3' requires at least 10% free space to perform decently over time (the 5% default is the absolute minimum that should be done)" "Traditionally, filesystems reserve 5-10% of the total space as a mechanism to prevent fragmentation. With today's gigantic disks and arrays, that could be a bit excessive, however setting it to zero is a very bad idea." "Not if you use xfs, set the "minimum free space" and run "xfs_db -rc frag ..." every night ;-)"

Do either have the same free space requirements as Reiser? Would it ever be recommended to go to something like ext3/4 or another file system altogether?

Is there any way to change the reiser timeouts or forcing it to do housekeeping in the background? Does unraid support BTRFS and any idea if XFS is better than BTRFS?

I used to have a problem a long time ago, and the answer I got was that I had to keep the disks in the array above 10-20% to keep the SMB service from locking up intermittently. We went through almost every possible step to make sure it was the problem from swapping NICs, attempting safe mode, disabling memory above 4gb. Finally, I did add quite a bit more new drives into the array, and 95% of my problem went away. But now, I've come to the same issues after dropping to around 15% free on a few of my drives (most free first storage mode). Can anyone tell me if this is still the case with Unraid 6 and if there are any fixes that have happened in the last year for my problem? (unraid pro 5.0.4)

I was thinking more along the lines of a cache drive...

Wondering if anyone has tried to compare the SSHD drives (ST4000DX001) to a similar 7200 Drive. Is the speed really going to happen with something like unraid? Will unraid actually support the SSHD drives yet?

http://www.amazon.com/gp/product/B005T3GRLY/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1 99$ & I shipped with my prime and will get it by friday... I also see the 3TB RX drive on newegg for 99$ as well.

thanks for the help...it looks like it should, i will give it a try...actually bought it at a garage sale for 5 bucks!, works beautifully and has 2 internal fans.

Is there a way to determine if an unmanaged switch supports jumbo frames without being able to find the specs anywhere!? My entire gigabit network (including another switch) for sure supports 9K, but I have a 3COM SC16479 16 port Gigabyte switch and I can't find product documentation anywhere. I do see that this model is whiteboxed for a few big companies (with poor documentation), but I have the true 3com version. Is my only option to try jumbo frames file transfer testing with and without the switch in question?