CGR21

Update: I was able to get it working by setting the docker to use host networking. Through trial and error I found that: 1 - the sftp port setting in the docker for sftpgo doesn't change the listening port. ergo, the port you thought you set it to isn't the real port. 2 - the unraid docker dashboard doesn't show the docker listening on the ipv6 address of the host when the host is configured for ipv6 and the docker is set to host, even though it is. This seems like an unraid or docker bug?

Using 7.1.4 here. My unraid has ipv6 connectivity. My VMs have IPv6 connectivity. Everything I've tried so far gives only IPv4 connectivity to dockers. Specifically, I'm trying to give the sftpgo docker IPv6 connectivity. Searches have shown that docker has or HAD extremely poor IPv6 support, so I don't know if this is an unraid or docker issue. I've found reports that IPv6 traffic is dropped going to br0, but it was fixed early in unraid 7 with a docker update. I've tried giving my docker static IPv6 through br0, and it still only gets an IPv4 address. I've tried giving my docker host networking, and it doesn't respond to IPv6 requests. Any help would be appreciated!!

After upgrading from 7.0.1 to 7.1.1, and then 7.1.2, I discovered my pihole docker no longer starts. It no longer starts because something is listening on port 53. netstat shows 192.168.122.1 listening on port 53. I'm double puzzled about this because: a) I don't know why this subnet exists now. It didn't before. Looks like something related to virbr0, but I don't know what/where virbr0 is and why it now exists b) pihole docker looks to be binding to my host IP of 192.168.0.201. I don't follow why something listening on port 53 on 122.1 would cause a problem with a docker listening on 0.201. Searching shows that virbr0/192.168.122.1 relates to natting on unraid. I haven't intentionally enabled natting anywhere. To all appearances this started on its own when I upgraded to 7.1.2. Thus far I haven't found where virbr0 is defined in unraid, but it runs and ties up port 53 anyhow. I also have a wireless wlan0 appearing in my network config that I didn't have before. It's disabled, so I don't know why it would be enabling any natting or enabling something listening on dns port 53. But this wlan0 appeared about the same time I started having this problem. I'd appreciate any advice on how to proceed. Thanks! nas-diagnostics-20250522-1652.zip

7 years later, can we get the docs updated to reflect this? The official docs still says of=/dev/mdX for 6.2 or higher, which leads to being forced to pushing the power button on the server, pulling the drive(s) you want to remove, and doing a rebuild. Granted, it's "legacy" documentation, but it's all we have for info on how to shrink an array.

I had the same problem here with Monterey as in: It appears some part of the initial install hadn't finished. The "vm_ready_notify" script never finishes for me. I no longer get this error; instead the VM sits forever on the Apple screen. It appears Monterey doesn't work yet? Thanks.

In a normal file system, you can not have a folder and a file with the same name in the same location? root@NAS:/mnt/user/Temp# touch folder root@NAS:/mnt/user/Temp# ls folder root@NAS:/mnt/user/Temp# mkdir folder mkdir: cannot create directory ‘folder’: File exists root@NAS:/mnt/user/Temp# Clearly it's possible in an unraid type setup if you are accessing the disks directly through /mnt/disk, but I'm not sure why you'd want to, as it clearly confuses the mapper! I rarely access drives directly; if so it's to move an entire folder structure from one drive to another. I'm very puzzled as to how this file got created on disk6.

Problem found and fixed! Somehow a FILE called 2015 existed on disk6 in the same place a FOLDER called 2015 existed on disk3. Hence "not a directory", although I could CD to the folder. Thanks for your help.

The folder only exists on disk3 now. The problem moved along with the directory from disk2 to disk3. I guess that rules out a disk issue. I'm going to copy it now to disk6, then remove it from disk3, and hope the problem doesn't "copy", only "moves".

Okay, that ran faster than I thought it would. 7 minutes later it finished. Still getting 'Not a directory'. I'm going to move the data from that folder directly from /mnt/disk2 to another /mnt/disk and see if the problem disappears with the folder being removed from the drive.

Noted. I'm only running it on one share, which is arguably the largest. I have also seen random "permission denied" errors through smb in windows, that seem to work the next time I try it. Never something I can reproduce. I have to wonder if there's an underlying bug in here somewhere.

The share this folder belongs to is very high in the directory structure: /mnt/user/HeartsCenter. I can write to other folders, even ../2014, without a problem. I'm trying the New Permissions trick on the share. It will take a while, as there are many many terrabytes of data there. I don't think I was using Unraid at version 5, but it shouldn't hurt? Thanks.

Note: I do NOT use a cache drive.

Extended SMART test on the drive completed without errors. Yes, I'm unable to write to one specific folder, and all folders under that folder, when writing to it through the array's mapping. root@NAS:/mnt/user/HeartsCenter/HeartsCenter/3-Week-Full-Sync/Sanctuary Video/2015# touch somefile touch: cannot touch 'somefile': Not a directory root@NAS:/mnt/user/HeartsCenter/HeartsCenter/3-Week-Full-Sync/Sanctuary Video/2015# 'touch' demonstrates it. What does "Not a directory" mean, and what is causing it? This folder only exists on drive #2. I can only CD to it on drive 2. The below is disk1: root@NAS:/mnt/user/HeartsCenter/HeartsCenter/3-Week-Full-Sync/Sanctuary Video/2015# cd /mnt/disk1/HeartsCenter/HeartsCenter/3-Week-Full-Sync/"Sanctuary Video"/2015 bash: cd: /mnt/disk1/HeartsCenter/HeartsCenter/3-Week-Full-Sync/Sanctuary Video/2015: No such file or directory root@NAS:/mnt/user/HeartsCenter/HeartsCenter/3-Week-Full-Sync/Sanctuary Video/2015# Here is disk #2: root@NAS:/mnt/disk2/HeartsCenter/HeartsCenter/3-Week-Full-Sync/Sanctuary Video/2015# cd /mnt/disk2/HeartsCenter/HeartsCenter/3-Week-Full-Sync/"Sanctuary Video"/2015 root@NAS:/mnt/disk2/HeartsCenter/HeartsCenter/3-Week-Full-Sync/Sanctuary Video/2015# From within there, I can write files just fine with no errors. root@NAS:/mnt/disk2/HeartsCenter/HeartsCenter/3-Week-Full-Sync/Sanctuary Video/2015# touch somefile root@NAS:/mnt/disk2/HeartsCenter/HeartsCenter/3-Week-Full-Sync/Sanctuary Video/2015# rm somefile I can not write to it through /mnt/user (or /mnt/user0, whatever that is), but I can write to it directly through /mnt/disk2. This problem did not always exist, as the data in this folder was originally written to it through /mnt/user. Thanks.

Here are the diagnostics. Thanks for the clue to include it! ls -lah /mnt shows: total 0 drwxr-xr-x 11 root root 220 Jan 9 16:51 ./ drwxr-xr-x 21 root root 440 Jan 9 17:42 ../ drwxrwxrwx 11 nobody users 186 Jun 5 2022 disk1/ drwxrwxrwx 9 nobody users 119 Sep 20 2020 disk10/ drwxrwxrwx 8 nobody users 132 Jul 21 2020 disk2/ drwxrwxrwx 9 nobody users 148 Jul 22 2020 disk3/ drwxrwxrwx 7 nobody users 93 Jul 23 2020 disk4/ drwxrwxrwx 8 nobody users 132 Jul 27 2020 disk5/ drwxrwxrwx 8 nobody users 133 Sep 20 2020 disk6/ drwxrwxrwx 1 nobody users 186 Jun 5 2022 user/ drwxrwxrwx 1 nobody users 186 Jun 5 2022 user0/