chancedonmillion

I was running into the same issue. Docker Version "not available" In my case Fix Common Problems plugin was reporting "Unable to communicate with GitHub.com". This issue surfaced after setting unbound Pi-hole as the DNS on my home network. My workaround was as follows. 1. disable VM and docker in unraid settings 2. change the DNS in unraid IP settings to 1.1.1.1 (use whatever DNS you'd like) rather than my home router IP / Pi-hole 3. re-enable VMs and docker in unraid settings 4. toggle advanced view and force update containers in the docker tab of unraid After the following the above steps all contains show as up to date and are auto updating again.

This was my issue. Thank you for explaining.

diagnostics zip file unraid-diagnostics-20200526-0828.zip

Even though /mnt/user/media/shows/ now points to both disk2 and disk5 why is unraid copying files from disk2 to disk2 when disk2 is 100% used and disk5 is 4% used? root@unraid:~# tree -d -L 2 /mnt/disk2 | grep -E 'media|shows|downloads' ├── downloads └── media └── shows root@unraid:~# tree -d -L 2 /mnt/disk5 | grep -E 'media|shows' └── media └── shows root@unraid:~# df -h | grep -E 'disk2|disk5' /dev/md2 3.7T 3.7T 32G 100% /mnt/disk2 /dev/md5 3.7T 137G 3.6T 4% /mnt/disk5

I may have found a workaround. I made a few changes to my /mnt/user/media/ share settings and I'm now using the unBALANCE plugin to move files between disk. The changes that I made were as follows: Allocation method: from high-water to Most-free Minimum free space: from 0KB to 10GB The previous settings may not have directly contributed to the issue but I think that the new configuration fits my needs better than the defaults. Whatever unBALANCE is doing in the background, we now see the /mnt/user/media/shows/ sub directory present on disk5. root@unraid:~# ls -la /mnt/disk5/media/ total 8 drwxrwxrwx 5 nobody users 67 Jan 7 11:19 ./ drwxrwxrwx 3 nobody users 19 May 22 15:33 ../ drwxrwxrwx 9 nobody users 4096 May 23 01:52 Scooby\ Doo/ drwxrwxrwx 10 nobody users 4096 May 25 12:37 movies/ drwxrwxrwx 3 nobody users 48 May 25 22:36 shows/

Krusader is failing to copy files from one share to another (/mnt/user/downloads/ to /mnt/user/media/) with the following error: There is not enough space on the disk... (see screenshot for more details) I get a similar failure using Windows file explorer. Taking a look a the file system I noticed that the "shows" sub directory in the /mnt/user/media/ share only points to disk2 which is 100% full. Why is this? Shouldn't sub directory /mnt/user/media/shows/ be present on all the same disk as other sub directories under /mnt/user/media/ such as /mnt/user/media/movies/ ? Might this be a bug or more likely something that I've failed to configure correctly? I've got plenty of space on the array, disk2 thru disk5 are used for my media. Thank you in advance for any help that your able to offer. root@unraid:~# df -h Filesystem Size Used Avail Use% Mounted on rootfs 7.3G 723M 6.6G 10% / tmpfs 32M 568K 32M 2% /run devtmpfs 7.3G 0 7.3G 0% /dev tmpfs 7.4G 0 7.4G 0% /dev/shm cgroup_root 8.0M 0 8.0M 0% /sys/fs/cgroup tmpfs 128M 452K 128M 1% /var/log /dev/sda1 30G 468M 29G 2% /boot /dev/loop0 9.2M 9.2M 0 100% /lib/modules /dev/loop1 7.3M 7.3M 0 100% /lib/firmware tmpfs 1.0M 0 1.0M 0% /mnt/disks /dev/md1 3.7T 800G 2.9T 22% /mnt/disk1 /dev/md2 3.7T 3.7T 939M 100% /mnt/disk2 /dev/md3 932G 103G 829G 12% /mnt/disk3 /dev/md4 932G 983M 931G 1% /mnt/disk4 /dev/sde1 112G 19G 93G 17% /mnt/cache shfs 13T 4.7T 8.2T 37% /mnt/user0 shfs 13T 4.7T 8.2T 37% /mnt/user /dev/loop2 20G 8.0G 12G 41% /var/lib/docker /dev/loop3 1.0G 17M 905M 2% /etc/libvirt /dev/md5 3.7T 113G 3.6T 4% /mnt/disk5 shm 64M 0 64M 0% /var/lib/docker/containers/64ebb28d73ef3a670a2f4961b99c745bd8475c5190fbfe6b1ba13c34c65c1015/mounts/shm root@unraid:~# tree -I 'backups|documents|isos|pictures|system' /mnt/disk1 /mnt/disk1 0 directories, 0 files root@unraid:~# tree -d -L 2 /mnt/disk2 /mnt/disk2 ├── downloads │ ├── complete │ ├── incomplete │ ├── torrents │ └── unzipped └── media ├── ROMS ├── books ├── games ├── movies ├── music ├── openvpn ├── other └── shows root@unraid:~# tree -d -L 2 /mnt/disk3 /mnt/disk3 └── media └── movies root@unraid:~# tree -d -L 2 /mnt/disk4 /mnt/disk4 0 directories root@unraid:~# tree -d -L 2 /mnt/disk5 /mnt/disk5 └── media ├── Scooby Doo └── movies 3 directories

likewise sh-5.0# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=56 time=26.0 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=56 time=26.0 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=56 time=25.9 ms 64 bytes from 8.8.8.8: icmp_seq=4 ttl=56 time=25.7 ms 64 bytes from 8.8.8.8: icmp_seq=5 ttl=56 time=26.1 ms ^C --- 8.8.8.8 ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 25.713/25.957/26.145/0.147 ms sh-5.0# ping goolge.com ping: goolge.com: Temporary failure in name resolution

I noticed that my qBittorrent web UI was down so I came to this thread and saw the discussion regarding the "cannot allocate 4611686018427387903 bytes" issue. I tailed the containers logs and sure enough, that is what I was seeing. 2020-03-30 20:49:11,570 DEBG 'start-script' stderr output: pgrep: cannot allocate 4611686018427387903 bytes I upgraded to the latest which fixed the "cannot allocate 4611686018427387903 bytes" issue. However the container is still failing to start. This is what I am seeing at in the logs currently. 2020-03-30 21:13:47,329 DEBG 'start-script' stdout output: [info] Attempting to curl http://209.222.18.222:2000/?client_id=adb8c2b559fdde17f847119ecdeb1c8fda5b852953313e0488ef16f2bdb45a52... 2020-03-30 21:13:47,429 DEBG 'start-script' stdout output: [warn] Response code 000 from curl != 2xx [warn] Exit code 56 from curl != 0 [info] 12 retries left [info] Retrying in 10 secs... ... 2020-03-30 21:15:38,565 DEBG 'start-script' stdout output: [warn] Response code 000 from curl != 2xx [warn] Exit code 56 from curl != 0 [info] 1 retries left [info] Retrying in 10 secs... 2020-03-30 21:15:48,670 DEBG 'start-script' stdout output: [warn] Response code 000 from curl != 2xx, exhausted retries exiting script... 2020-03-30 21:15:48,670 DEBG 'start-script' stdout output: [warn] PIA VPN port assignment API currently down, terminating OpenVPN process to force retry for incoming port... Google tells me that code 56 is known to occur when the network adapter has a conflict with the third-party VPN installed on your system. I would really appreciate any insight as to why the adapter has a conflict with the third-party VPN and what I may be able to do as a workaround. I also tried deleting the image and reinstalling the container, same issue.

Thanks!

Can anyone point me towards documentation and/or examples of how to use the "Supported parameters" of the "Run external program on torrent completion" option in qBittorrent? The documentation on the qBittorrent GitHub wiki is pretty sparse regarding the subject. What I’m trying to accomplish is this. I would like to copy completed torrents from my "/mnt/user/downloads/complete" directory to either "/mnt/user/media/movies" or "/mnt/user/media/shows" using the category parameter specified when adding a torrent to the client. Also, I plan on using a bash script, where in the file structure of the container should I keep the script that I’ll be referencing?

Without further research/testing I cant say for sure but it seems like Windows initially will attempt to log into a SMB share using the credentials of the Windows user. In this case my Windows user credentials happened to match my Unraid user credentials so I was never prompted to enter a user or password. Thanks for the help trurl! I'm liking Unraid so far and Ill probably be buying a key.

At no point (that I am aware of) did I access a public share on the Unraid NAS from any device in my network. The shares that I created were originally created as private.

OK, quick update. Previously I was only testing with PCs in the same work group as the Unraid NAS. Furthermore the usernames and passwords of those Windows 10 PCs matched the usernames and passwords defined in Unraid (I know not best practice, but easy for the family). When testing with another device (my Windows 10 work labtop w/ no workgroup defined & non matching user/pass) I AM prompted for a password. Any idea where the logs pertaining to share access are located? Id like to take a look at exactly what happened with the initial access before I place the NAS into prod and they roll over.

Thanks for the quick follow up. To be clear I was never prompted to log in when accessing these shares. Initially I accessed these shares as follows: File Explorer > Network > "Refresh Network" After refreshing the network I could see and access my private shares without ever being prompted for a user or password. I get he same behavior when navigating to the shares via IP "\\192.168.1.10\documents" and I have no saved Unraid credentials in Credentials Manager. I created the users prior to creating the shares. Just spit balling here but perhaps the SMB service needs to be restarted?

I recently setup an Unraid NAS for testing. It was a super easy setup and the GUI is slick. I am however running into some unexpected behavior. I have set up several shares that I can read from and write to without issues. However, I am NOT prompted for password when accessing my SMB shares. The shares in question have security set to private. What am I missing here? Server: Unraid Version: 6.7.2 Client: Windows 10 build 17763.615 An example of how I have one of the shares setup: