September 29, 201411 yr I don't see any mention of it but I can't access my disk shares via SMB with beta10 or other shares in which the SMB security is set to Private and my Windows account user has R/W access - No issue with access on beta9. If you don't have a cache drive, check the shares and change the use cache drive to no. The disk1, disk2, etc shares do not utilize a cache drive. Changing it on the one regular share that wouldn't let me access made no difference.
September 29, 201411 yr Author I don't see any mention of it but I can't access my disk shares via SMB with beta10 or other shares in which the SMB security is set to Private and my Windows account user has R/W access - No issue with access on beta9. Works for me.
September 29, 201411 yr I don't see any mention of it but I can't access my disk shares via SMB with beta10 or other shares in which the SMB security is set to Private and my Windows account user has R/W access - No issue with access on beta9. Works for me. If I change the security on the SMB share from "private" to "secure" or "public", then I can access the disk share but I receive an access denied error on trying to create a file. ETA: After running the new permissions script, I can create directories & files if the share is public but still can't if it's not even if my account has access. Also tried resetting the password on my "john" account, no go.
September 29, 201411 yr There definitely is a bug with Xen. We have tracked it down and are working to fix. It affects autostart and shutting down the VMs at array stop. Okay - great. So no need for me to post a log?
September 29, 201411 yr Author There definitely is a bug with Xen. We have tracked it down and are working to fix. It affects autostart and shutting down the VMs at array stop. Okay - great. So no need for me to post a log? No.
September 29, 201411 yr Is this something fixable with powerdown Kxx and Sxx scripts in the mean time? I ask because I already had a K script sitting around (forgot to remove it) and while my VM indeed is not autostarting, it did seem to close smoothly when I stopped my array.
September 29, 201411 yr Is this something fixable with powerdown Kxx and Sxx scripts in the mean time? Err .... beta10a is already available!
September 29, 201411 yr Yup just saw that. I also see that the changelog doesn't address the Xen problem even though it does seem to have actually done that. If this xenMan: restored 'x' bit in event scripts is it, then it is a bit cryptic. NO? ;-) 10a is also not noted in the front page banner.
September 29, 201411 yr Yup just saw that. I also see that the changelog doesn't address the Xen problem even though it does seem to have actually done that. If this xenMan: restored 'x' bit in event scripts is it, then it is a bit cryptic. NO? ;-) 10a is also not noted in the front page banner. The x bit is exactly what was causing the Xen and a few other issues.
September 29, 201411 yr Some feedback from my side: Updated my Test&Backup Server today from b9 to b10 with the old method. Went very well, so thanks to Tom and the team No error messages in the syslog but I saw the Powerdown package twice and unRAID b10a was shown as stale. I manually deleted the powerdown script 2.07, the stale directory and the related plg file. All fine now and only on question please - do these packages all belonging to stock unRAID? I can't remember having all these packages installed myself Installing new package /boot/packages/powerdown-2.09-noarch-unRAID.tgz Skipping package libvirt-python-1.2.8-x86_64-1_SBo (already installed) Installing new package /boot/packages/tcl-8.6.1-x86_64-1.txz Installing new package /boot/packages/expect-5.44.1.15-x86_64-2.txz Installing new package /boot/packages/webvirtmgr-site-packages-x86-64-1.txz Installing new package /boot/packages/pysetuptools-3.6-x86_64-1ponce.txz Installing new package /boot/packages/git-1.8.4-x86_64-1.txz I then updated the other server and saw some AFP related messages: Sep 29 09:51:10 Tower avahi-daemon[8481]: Service "Tower-AFP" (/services/afp.service) successfully established. Sep 29 10:01:06 Tower afpd[12194]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 10:03:02 Tower afpd[12194]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 10:13:35 Tower afpd[12194]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 10:42:45 Tower afpd[12194]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 10:56:02 Tower shfs/user: shfs_rmdir: rmdir: /mnt/disk1/TMO/Olivers iMac.purgeable/bands (39) Directory not empty Sep 29 10:56:23 Tower afpd[8475]: child[12194]: asev_del_fd: 4 Sep 29 11:00:45 Tower sshd[10118]: Received disconnect from 192.168.178.30: 11: disconnected by user Sep 29 11:01:20 Tower cnid_metad[8476]: set_dbdir: mkdir failed for /mnt/user/TMO/.AppleDB/ Sep 29 11:01:20 Tower afpd[7795]: read: Connection reset by peer Sep 29 11:48:23 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 11:49:49 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 11:49:49 Tower afpd[9093]: afp_createfile("67e"): CNID error Sep 29 12:04:24 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 12:21:41 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 12:32:32 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 12:33:09 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 12:39:14 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 12:39:14 Tower afpd[9093]: afp_createfile("a58"): CNID error Sep 29 12:47:27 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 13:20:41 Tower kernel: mdcmd (37): spindown 1 Sep 29 13:36:49 Tower afpd[22316]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 13:36:49 Tower afpd[22316]: afp_createfile(".dat822c.002"): CNID error Sep 29 13:50:32 Tower kernel: mdcmd (38): spindown 6 Sep 29 13:50:32 Tower kernel: mdcmd (39): spindown 7 Sep 29 13:55:15 Tower afpd[22316]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 13:57:29 Tower afpd[22316]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 14:00:17 Tower shfs/user: shfs_rmdir: rmdir: /mnt/disk1/TMO/Olivers iMac.purgeable/bands (39) Directory not empty Sep 29 14:00:17 Tower shfs/user: shfs_rmdir: rmdir: /mnt/disk1/TMO/Olivers iMac.purgeable/bands (39) Directory not empty I have to admit that I haven't rebooted the server since my update from b9. When the messages that you see above appeared, Time Machine stopped with an error message. I deleted the old TM volume and started fresh with a new TM file. Time Machine is running since 2h now, having 24GB out of 640GB [EDIT] That wasn't helping: Sep 29 16:46:10 Tower afpd[4172]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 16:46:10 Tower afpd[4172]: afp_createfile("10e3"): CNID error Sep 29 16:56:30 Tower afpd[4172]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 16:56:30 Tower afpd[4172]: afp_createfile("117b"): CNID error Sep 29 17:00:52 Tower afpd[4172]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 17:00:52 Tower afpd[4172]: afp_createfile("11bf"): CNID error Sep 29 17:11:34 Tower afpd[4172]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 17:11:34 Tower afpd[4172]: afp_createfile("11fd"): CNID error Sep 29 17:12:13 Tower afpd[4172]: transmit: Request to dbd daemon (volume TMO) timed out.
September 30, 201411 yr Some feedback from my side: Updated my Test&Backup Server today from b9 to b10 with the old method. Went very well, so thanks to Tom and the team No error messages in the syslog but I saw the Powerdown package twice and unRAID b10a was shown as stale. I manually deleted the powerdown script 2.07, the stale directory and the related plg file. All fine now and only on question please - do these packages all belonging to stock unRAID? I can't remember having all these packages installed myself Installing new package /boot/packages/powerdown-2.09-noarch-unRAID.tgz Skipping package libvirt-python-1.2.8-x86_64-1_SBo (already installed) Installing new package /boot/packages/tcl-8.6.1-x86_64-1.txz Installing new package /boot/packages/expect-5.44.1.15-x86_64-2.txz Installing new package /boot/packages/webvirtmgr-site-packages-x86-64-1.txz Installing new package /boot/packages/pysetuptools-3.6-x86_64-1ponce.txz Installing new package /boot/packages/git-1.8.4-x86_64-1.txz I then updated the other server and saw some AFP related messages: Sep 29 09:51:10 Tower avahi-daemon[8481]: Service "Tower-AFP" (/services/afp.service) successfully established. Sep 29 10:01:06 Tower afpd[12194]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 10:03:02 Tower afpd[12194]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 10:13:35 Tower afpd[12194]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 10:42:45 Tower afpd[12194]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 10:56:02 Tower shfs/user: shfs_rmdir: rmdir: /mnt/disk1/TMO/Olivers iMac.purgeable/bands (39) Directory not empty Sep 29 10:56:23 Tower afpd[8475]: child[12194]: asev_del_fd: 4 Sep 29 11:00:45 Tower sshd[10118]: Received disconnect from 192.168.178.30: 11: disconnected by user Sep 29 11:01:20 Tower cnid_metad[8476]: set_dbdir: mkdir failed for /mnt/user/TMO/.AppleDB/ Sep 29 11:01:20 Tower afpd[7795]: read: Connection reset by peer Sep 29 11:48:23 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 11:49:49 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 11:49:49 Tower afpd[9093]: afp_createfile("67e"): CNID error Sep 29 12:04:24 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 12:21:41 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 12:32:32 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 12:33:09 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 12:39:14 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 12:39:14 Tower afpd[9093]: afp_createfile("a58"): CNID error Sep 29 12:47:27 Tower afpd[9093]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 13:20:41 Tower kernel: mdcmd (37): spindown 1 Sep 29 13:36:49 Tower afpd[22316]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 13:36:49 Tower afpd[22316]: afp_createfile(".dat822c.002"): CNID error Sep 29 13:50:32 Tower kernel: mdcmd (38): spindown 6 Sep 29 13:50:32 Tower kernel: mdcmd (39): spindown 7 Sep 29 13:55:15 Tower afpd[22316]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 13:57:29 Tower afpd[22316]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 14:00:17 Tower shfs/user: shfs_rmdir: rmdir: /mnt/disk1/TMO/Olivers iMac.purgeable/bands (39) Directory not empty Sep 29 14:00:17 Tower shfs/user: shfs_rmdir: rmdir: /mnt/disk1/TMO/Olivers iMac.purgeable/bands (39) Directory not empty I have to admit that I haven't rebooted the server since my update from b9. When the messages that you see above appeared, Time Machine stopped with an error message. I deleted the old TM volume and started fresh with a new TM file. Time Machine is running since 2h now, having 24GB out of 640GB [EDIT] That wasn't helping: Sep 29 16:46:10 Tower afpd[4172]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 16:46:10 Tower afpd[4172]: afp_createfile("10e3"): CNID error Sep 29 16:56:30 Tower afpd[4172]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 16:56:30 Tower afpd[4172]: afp_createfile("117b"): CNID error Sep 29 17:00:52 Tower afpd[4172]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 17:00:52 Tower afpd[4172]: afp_createfile("11bf"): CNID error Sep 29 17:11:34 Tower afpd[4172]: transmit: Request to dbd daemon (volume TMO) timed out. Sep 29 17:11:34 Tower afpd[4172]: afp_createfile("11fd"): CNID error Sep 29 17:12:13 Tower afpd[4172]: transmit: Request to dbd daemon (volume TMO) timed out. So are you running 10a or 10? What does it say in the top right corner of the webGui?
September 30, 201411 yr I'm running 6.0-beta10a. After the required reboot my Mac transferred approx. 350GB of data and stopped then (not further CNDB errors). TM was asking me to start over again. My wife's Mac is doing fine and transferred 40GB without any hassle. We both are running Mac OSX 10.9.5. and the dedicated TM shares are both on one single disk /mnt/disk1/ with exactly the same settings. Only difference is the amount of data....
October 1, 201411 yr I'm running 6.0-beta10a. After the required reboot my Mac transferred approx. 350GB of data and stopped then (not further CNDB errors). TM was asking me to start over again. My wife's Mac is doing fine and transferred 40GB without any hassle. We both are running Mac OSX 10.9.5. and the dedicated TM shares are both on one single disk /mnt/disk1/ with exactly the same settings. Only difference is the amount of data.... I think you may need to create a share for each of you separately. TM doesn't like sharing a single folder amongst multiple devices typically.
October 1, 201411 yr .... and the dedicated TM shares are both on one single disk /mnt/disk1/ with exactly the same settings Sorry for my english, this is what I meant. We have separate shares for TM. TMO for my backup, TMA for my wife's backup.
October 1, 201411 yr .... and the dedicated TM shares are both on one single disk /mnt/disk1/ with exactly the same settings Sorry for my english, this is what I meant. We have separate shares for TM. TMO for my backup, TMA for my wife's backup. We will have to look into this. Can you post a syslog? Please create this as a new thread under general support so we can track/manage it correctly. Thanks!!
October 2, 201411 yr I have two mac servers, I just created a 2nd TM share and backing the 2nd one up to it now. Will post results on the new thread once it's created.
October 2, 201411 yr I have "re-used" another thread, so we may want to continue there? Here you are: http://lime-technology.com/forum/index.php?topic=35309.0 The syslog can be found in my Reply #3. Thanks a lot.
October 2, 201411 yr I have "re-used" another thread, so we may want to continue there? Here you are: http://lime-technology.com/forum/index.php?topic=35309.0 The syslog can be found in my Reply #3. Thanks a lot. Well hold on, is this an issue with AFP in unRAID 5 or unRAID 6. The thread you just linked me to is in the 5.x support forums.
October 3, 201411 yr Oh - I thought that the AFP thread is independently relevant for v5 & v6 I can see how that is confusing. We are planning to rearrange the forum a bit to make this better. The AFP version in v6 is different than v5.
October 23, 201411 yr Where can I find instructions for updating my plugins to work better with the plugins tab?
Archived
This topic is now archived and is closed to further replies.