July 10, 20169 yr Yeah your indeed right. If you set your ip adres to static there is some trouble with dns. If I set the DNS to 192.168.10.1 that is the adres of my router Docker is not working. If I add the google DNS server to the network settings it's working but slow. If everything is set to automatic (DHCP) it's working okay.
July 10, 20169 yr Yeah your indeed right. If you set your ip adres to static there is some trouble with dns. If I set the DNS to 192.168.10.1 that is the adres of my router Docker is not working. If I add the google DNS server to the network settings it's working but slow. If everything is set to automatic (DHCP) it's working okay. So keep it at DHCP and set the static address within the router.
July 10, 20169 yr I have the update done, but now i can't access my shares anymore from Windows. I can Ping it, i can connect via website, but no more from explorer... What is wrong? All my shares are still ok from the website....
July 10, 20169 yr Author I have the update done, but now i can't access my shares anymore from Windows. I can Ping it, i can connect via website, but no more from explorer... What is wrong? All my shares are still ok from the website.... Give windows a little time to come to it's senses. You should be able to type "\\tower" right in the explorer address bar to see your shares. (Of course use your own server name if changed from 'tower'.)
July 10, 20169 yr nope, i've rebooted both systems a few time... tried with the \\192.168.1.3 and then unraid is asking for a login... when i give the root access, unraid is asking again for root access...
July 10, 20169 yr nope, i've rebooted both systems a few time... tried with the \\192.168.1.3 and then unraid is asking for a login... when i give the root access, unraid is asking again for root access... sounds as if Windows may have some cached credentials causing a problems. Try using Windows Credentials Manager to remove any existing credentials for the unRAID server.
July 10, 20169 yr nope, i've rebooted both systems a few time... tried with the \\192.168.1.3 and then unraid is asking for a login... when i give the root access, unraid is asking again for root access... sounds as if Windows may have some cached credentials causing a problems. Try using Windows Credentials Manager to remove any existing credentials for the unRAID server. nope, when i tried to connect with a new windows, the same problem occurs... what happened?
July 11, 20169 yr It would be nice to be able to delete parity check history entries. In 6.1, I just went into my flash drive and edited the file in notepad. However, with 6.2 it seems to regenerate the last entry no matter what. Even deleting the entire parity history file it creates a new one within seconds with the same information. "2016 Jul 10 19:20:03|22|Unavailable|-4" So on my dashboard I show a 22 second incomplete parity check when I just did a full parity check yesterday.
July 11, 20169 yr - docker: fix update to always request manifest.v2 information Updates Always Available (and subsequent pulls of 0B) are still happening on Dolphin (aptalca/docker-dolphin:latest). Happens on a virgin docker.img file. Hmmm, not able to reproduce here. I added this container on a test machine here (with rc1) after which it showed 'up-to-date'. Did a Check for Updates but still remained 'up-to-date'. ... Actually, this is what I was seeing: "aptalca/docker-dolphin:latest": { "local": null, "remote": "sha256:9cc5f3d41b09b915a2024eef870c23f219d6036d9bc01aa03cab6ce3cbf6a08a", "status": "undef" } But I looked very closely at the my* template after you couldn't reproduce and the problem was somehow there was some trailing spaces in the repository entry. It would pull correctly but messed up the updates. Might not be a bad idea to do trim's on all the entries in dockerMan Ah that makes sense now. The next release will trim leading/trailing spaces from a few of the Docker input boxes.
July 11, 20169 yr Has anyone worked out how to get the unraid console to show the cpu frequency again in the load statistics? I had it in versions older then 23.
July 11, 20169 yr Has anyone worked out how to get the unraid console to show the cpu frequency again in the load statistics? I had it in versions older then 23. No this has ben changed from frequency to cpu/core load as of 6.2 beta
July 11, 20169 yr Hello, is RC the final build of 6.2 ? ) There's at least one bug (relatively minor) found already so count on an RC2.
July 11, 20169 yr [fuse/shfs does support symlinks but not hard links. Are you sure? I don't know a lot about FUSE and I've just heard about SHFS. I have read that SHFS stopped development in 2004 and has been superseded by SSHFS. In my searching for a solution or workaround I've seen numerous pages mentioning hard link support for FUSE and SSHFS. If that's the case replacing SHFS with SSHFS (if possible) should allow hard linking. 'shfs' is limetech-proprietary fuse-based user share file system - has nothing to do with other projects out there that might also be named 'shfs'. Ah, that makes sense then. Well, in that case, what is the limiting factor in adding hard link support? I know FUSE itself supports it. Since hard linking works on the disk shares and the user share will honor those hard links, is it possible to have shfs intercept system calls to hard link from a user share and redirect them to the appropriate disk share? Is it unreasonable to add a feature request for this ('cause I already did)?
July 11, 20169 yr Hello, is RC the final build of 6.2 ? ) There's at least one bug (relatively minor) found already so count on an RC2. RC = Release candidate. One step closer to final release, but not quite there.
July 11, 20169 yr I'm afraid I may have hosed docker. After the upgrade, emhttp wasn't responding for 15-20 minutes. I could see the process running. I issued a "reboot" command over ssh, and the server gracefully shut down. Once it came back up, emhttp was working okay, but the Docker tab is missing. The syslog seems to mount my old docker image from /mnt/vms/docker.img, but it also seems to fail a subsequent mount command: Jul 11 20:01:31 storage emhttp: shcmd (76): set -o pipefail ; /usr/local/sbin/mount_image '/mnt/vms/docker.img' /var/lib/docker 20 |& logger Jul 11 20:01:31 storage kernel: BTRFS: device fsid 52c0aba5-9923-418c-9465-89971a7367f3 devid 1 transid 1124822 /dev/loop0 Jul 11 20:01:31 storage kernel: BTRFS info (device loop0): disk space caching is enabled Jul 11 20:01:31 storage kernel: BTRFS: has skinny extents Jul 11 20:01:31 storage root: Resize '/var/lib/docker' of 'max' Jul 11 20:01:31 storage kernel: BTRFS info (device loop0): new size for /dev/loop0 is 21474836480 Jul 11 20:01:31 storage emhttp: shcmd (78): /etc/rc.d/rc.docker start |& logger Jul 11 20:01:31 storage root: starting docker ... <snip> Jul 11 20:01:43 storage emhttp: shcmd (102): set -o pipefail ; /usr/local/sbin/mount_image '/mnt/vms/docker.img' /var/lib/docker 20 |& logger Jul 11 20:01:43 storage root: /mnt/vms/docker.img is in-use, cannot mount Jul 11 20:01:43 storage emhttp: shcmd: shcmd (102): exit status: 1 I can see that the image is mounted at /var/lib/docker, but lsof says that nothing is using that folder and docker is not running. I'm worried that I interrupted the container update process, or somehow confused unraid with the reboot. If I change the image location to /mnt/user/system/docker/docker.img and let unraid create a new image file, Docker starts okay. But if I move my /mnt/vms/docker.img into that location, I get the same behavior. I guess I broke my docker.img file?
July 12, 20169 yr I'm afraid I may have hosed docker. After the upgrade, emhttp wasn't responding for 15-20 minutes. I could see the process running. I issued a "reboot" command over ssh, and the server gracefully shut down. Once it came back up, emhttp was working okay, but the Docker tab is missing. The syslog seems to mount my old docker image from /mnt/vms/docker.img, but it also seems to fail a subsequent mount command: Jul 11 20:01:31 storage emhttp: shcmd (76): set -o pipefail ; /usr/local/sbin/mount_image '/mnt/vms/docker.img' /var/lib/docker 20 |& logger Jul 11 20:01:31 storage kernel: BTRFS: device fsid 52c0aba5-9923-418c-9465-89971a7367f3 devid 1 transid 1124822 /dev/loop0 Jul 11 20:01:31 storage kernel: BTRFS info (device loop0): disk space caching is enabled Jul 11 20:01:31 storage kernel: BTRFS: has skinny extents Jul 11 20:01:31 storage root: Resize '/var/lib/docker' of 'max' Jul 11 20:01:31 storage kernel: BTRFS info (device loop0): new size for /dev/loop0 is 21474836480 Jul 11 20:01:31 storage emhttp: shcmd (78): /etc/rc.d/rc.docker start |& logger Jul 11 20:01:31 storage root: starting docker ... <snip> Jul 11 20:01:43 storage emhttp: shcmd (102): set -o pipefail ; /usr/local/sbin/mount_image '/mnt/vms/docker.img' /var/lib/docker 20 |& logger Jul 11 20:01:43 storage root: /mnt/vms/docker.img is in-use, cannot mount Jul 11 20:01:43 storage emhttp: shcmd: shcmd (102): exit status: 1 I can see that the image is mounted at /var/lib/docker, but lsof says that nothing is using that folder and docker is not running. I'm worried that I interrupted the container update process, or somehow confused unraid with the reboot. If I change the image location to /mnt/user/system/docker/docker.img and let unraid create a new image file, Docker starts okay. But if I move my /mnt/vms/docker.img into that location, I get the same behavior. I guess I broke my docker.img file? Sounds like it, no massive issue to recreate it though, unless you had a lot of dev work going on in there....
July 12, 20169 yr I am getting a fair bit better performance on this new update i was starting to get some inconsistent performance which has been solved
July 12, 20169 yr I'll mention this here. I don't think it's a bug per se, but rather an unexpected behavior of the new shares. You might want to warn people. As part of this upgrade, I'm doing a p2v transition for my desktop PC. The OS disk is 239 GB, and I made a backup. Now that unraid has the new shares, I'm trying to use them. So I put my disk image and backup in /mnt/disk1/domains/myvm. My cache disk is a 128 GB SSD, so I didn't bother trying to put them into /mnt/cache/domains/myvm. I didn't realize that the "prefer" setting for the share would attempt to move the VM images to the cache drive, filling it up and hanging the mover. It would be nice if the mover was smart enough to not shoot itself in the foot with regard to the "prefer" option, for the scenario where the file exists in the array but not in the cache. You might also want to warn people about this. Previously, I was putting my VMs and docker data on a separately mounted SSD. Since we don't have a supported RAID 0 way to combine SSDs to increase the cache size, if I want to use the new shares with SSD performance, I'll have no choice but to buy an SSD that's twice the size, replacing my previous two SSDs. For now I've done the obvious thing and modified the share settings to prevent the domains share from using the cache drive. P.S. Is the mover safe to use on vdisk1.img files while the VM is running?
July 12, 20169 yr In the VM settings page, the handy little directory chooser for the ISOs isn't working. I can still paste the full path though. Is it just me?
July 12, 20169 yr I'll mention this here. I don't think it's a bug per se, but rather an unexpected behavior of the new shares. You might want to warn people. As part of this upgrade, I'm doing a p2v transition for my desktop PC. The OS disk is 239 GB, and I made a backup. Now that unraid has the new shares, I'm trying to use them. So I put my disk image and backup in /mnt/disk1/domains/myvm. My cache disk is a 128 GB SSD, so I didn't bother trying to put them into /mnt/cache/domains/myvm. I didn't realize that the "prefer" setting for the share would attempt to move the VM images to the cache drive, filling it up and hanging the mover. It would be nice if the mover was smart enough to not shoot itself in the foot with regard to the "prefer" option, for the scenario where the file exists in the array but not in the cache. You might also want to warn people about this. Previously, I was putting my VMs and docker data on a separately mounted SSD. Since we don't have a supported RAID 0 way to combine SSDs to increase the cache size, if I want to use the new shares with SSD performance, I'll have no choice but to buy an SSD that's twice the size, replacing my previous two SSDs. For now I've done the obvious thing and modified the share settings to prevent the domains share from using the cache drive. P.S. Is the mover safe to use on vdisk1.img files while the VM is running? use -dconvert=raid0 -mconvert=raid1 to make your cache pool a raid0/job device - I did this and got 2 120s to show up as a single 240 - I know its not protected - but I keep it backed up. Myk
July 12, 20169 yr I read here that this will be reverted by unRAID after a reboot? Or is that no longer the case? The feature request is also not answered. I'm terrified about it reverting after a reboot, and losing all my cache data... Especially since I have a vdisk1.img file that is larger than both of the SSDs.
July 12, 20169 yr In the VM settings page, the handy little directory chooser for the ISOs isn't working. I can still paste the full path though. Is it just me? Works for me. Maybe clear your browser cache or try another browser? BTW, the work you guys have done on the VM creation and management is pure awesomeness! Everything I have tried and played with has worked perfectly. I must have created a dozen VM's yesterday trying different options with and without hardware pass through and it works flawlessly. Thanks! Gary
Archived
This topic is now archived and is closed to further replies.