RandoUser

Interestingly, I've had this exact same symptom happen twice recently. I am on 7.3.1. The GUI, the console, and ssh all become unresponsive. Only a hard reboot works. I'll try to capture and share my syslog if it happens again.

FIXED! It was a client-side issue. I had a custom configuration in /etc/nsmb.conf that had something in it that was causing the problem. I just deleted the whole file which reset MacOS back to its defaults and that resolved the issue. Here's my "bad" /etc/nsmb.conf file in case someone sees something specific that would have caused it. [default] # Disable SMB signing (adds overhead) signing_required=no # Don’t use NTFS-style resource forks (prevents hidden AppleDouble files) streams=no # Force SMB3 only protocol_vers_map=3 # Avoid directory caching weirdness in Finder dir_cache=no dir_cache_off=yes # Disable file id lookups that slow large dirs file_ids_off=yes # Don’t query for file streams on each listing no_share_cache=yes port445=no_delayed_ack,no_netbios notify_off=yes

I have the Docker container running and don’t see anything obviously wrong, but when I attempt to configure Settings - Time Machine, it returns the error: The selected network backup disk does not support the required capabilities. Please be sure Time Machine capabilities are enabled on the server for this volume or choose a different network backup volume. Docker Launch Rundocker run -d --name='TimeMachine' --net='mynet' --ip='10.0.0.26' --pids-limit 2048 -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -e HOST_HOSTNAME="SERVER" -e HOST_CONTAINERNAME="TimeMachine" -e 'VOLUME_SIZE_LIMIT'='2 T' -e 'TM_USERNAME'='timemachine' -e 'PASSWORD'='timemachine' -e 'ADVERTISED_HOSTNAME'='timemachine' -e 'CUSTOM_SMB_CONF'='false' -e 'CUSTOM_USER'='false' -e 'DEBUG_LEVEL'='1' -e 'MIMIC_MODEL'='TimeCapsule8,119' -e 'EXTERNAL_CONF'='' -e 'HIDE_SHARES'='no' -e 'TM_GROUPNAME'='users' -e 'TM_UID'='99' -e 'SET_PERMISSIONS'='false' -e 'SMB_INHERIT_PERMISSIONS'='no' -e 'SMB_NFS_ACES'='yes' -e 'SMB_METADATA'='stream' -e 'SMB_PORT'='445' -e 'SMB_VFS_OBJECTS'='acl_xattr fruit streams_xattr' -e 'WORKGROUP'='TIMEMACHINE' -e 'TM_GID'='100' -e 'SHARE_NAME'='TimeMachine' -l net.unraid.docker.managed=dockerman -l net.unraid.docker.icon='https://upload.wikimedia.org/wikipedia/de/f/f4/Time_Machine_%28Apple%29_Logo.png' -v '/mnt/mediapool/timemachine/':'/opt/timemachine':'rw' --hostname timemachine 'mbentley/timemachine' a59f6ce6ea90f68d62c6d816375e70eb6999974546eada6617e5d41d39186b8aContainer Logschpasswd: password for 'timemachine' changed dbus-daemon[39]: [system] org.freedesktop.DBus.Error.AccessDenied: Failed to set fd limit to 65536: Operation not permitted Found user 'avahi' (UID 86) and group 'avahi' (GID 86). Successfully dropped root privileges. avahi-daemon 0.8 starting up. WARNING: No NSS support for mDNS detected, consider installing nss-mdns! Loading service file /etc/avahi/services/smbd.service. Joining mDNS multicast group on interface eth0.IPv4 with address 10.0.0.26. New relevant interface eth0.IPv4 for mDNS. Joining mDNS multicast group on interface lo.IPv6 with address ::1. New relevant interface lo.IPv6 for mDNS. Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1. New relevant interface lo.IPv4 for mDNS. Network interface enumeration completed. Registering new address record for 10.0.0.26 on eth0.IPv4. Registering new address record for ::1 on lo.*. Registering new address record for 127.0.0.1 on lo.IPv4. Server startup complete. Host name is timemachine.local. Local service cookie is 3653652982. Service "timemachine" (/etc/avahi/services/smbd.service) successfully established. INFO: CUSTOM_SMB_CONF=false; generating [global] section of /etc/samba/smb.conf... INFO: Creating /var/log/samba/cores INFO: Avahi - generating base configuration in /etc/avahi/services/smbd.service... INFO: Avahi - using timemachine as hostname. INFO: Avahi - adding the 'dk0', 'TimeMachine' share txt-record to /etc/avahi/services/smbd.service... INFO: Group users exists; skipping creation INFO: User timemachine doesn't exist; creating... INFO: Using default password: timemachine INFO: INFO: CUSTOM_SMB_CONF=false; generating [TimeMachine] section of /etc/samba/smb.conf... INFO: Samba - Created Added user timemachine. INFO: Samba - Enabled user timemachine. INFO: Samba - setting password INFO: SET_PERMISSIONS=false; not setting ownership and permissions for /opt/timemachine INFO: Avahi - completing the configuration in /etc/avahi/services/smbd.service... INFO: running test for xattr support on your time machine persistent storage location... INFO: xattr test successful - your persistent data store supports xattrs INFO: Detected filesystem for /opt/timemachine is zfs INFO: entrypoint complete; executing 's6-svscan /etc/s6' dbus socket not yet available; sleeping... nmbd version 4.22.6 started. Copyright Andrew Tridgell and the Samba Team 1992-2025 smbd version 4.22.6 started. Copyright Andrew Tridgell and the Samba Team 1992-2025 become_local_master_stage2: ***** Samba name server TIMEMACHINE is now a local master browser for workgroup TIMEMACHINE on subnet 10.0.0.26 Time Machine client logs2026-01-23 15:00:44 Limiting logging for limit: aFewTimes key: "map auto_home" 2026-01-23 15:00:44 Bonjour took 0.2 seconds to resolve 'smb://timemachine@timemachine._smb._tcp.local/TimeMachine' to 'smb://[email protected]/TimeMachine' 2026-01-23 15:01:39 Limiting logging for limit: aFewTimes key: "map auto_home" 2026-01-23 15:01:44 Limiting logging for limit: aFewTimes key: "map auto_home" 2026-01-23 15:01:52 Choosing destination volume 2026-01-23 15:01:54 Prepare destination 2026-01-23 15:01:54 mountNetworkURL: smb://timemachine._smb._tcp.local./TimeMachine airDiskFlags: 0x82 2026-01-23 15:01:54 NetAuth session for 'smb://timemachine._smb._tcp.local./TimeMachine' will use options: { AuthType = Time AuthType = TimeMachine; 2026-01-23 15:01:54 Reporting preparation progress message: 'Mounting “TimeMachine” from “timemachine.local”…', fractionDone: nil 2026-01-23 15:02:01 NAOpenSessionAsync reports sessionStatus: 0, sessionInfo: { 2026-01-23 15:02:01 Mounting share 'TimeMachine' with options: { TimeMachineMoun TimeMachineMount = 1; 2026-01-23 15:02:01 NAMountAsync reports mountStatus: 0, mountInfo: { MountPath = "/V MountPath = "/Volumes/TimeMachine"; 2026-01-23 15:02:01 Reporting preparation progress message: 'Checking capabilities of “TimeMachine” from “timemachine.local”…', fractionDone: nil 2026-01-23 15:02:01 Backup images not supported or failed to configure reconnect settings for '/Volumes/TimeMachine' 2026-01-23 15:02:01 Mountpoint '/Volumes/TimeMachine' is still valid 2026-01-23 15:02:01 Unmounting '/Volumes/TimeMachine' 2026-01-23 15:02:01 Reporting preparation error: Error Domain=com.apple.TimeMachine.SettingsExtension Code=3 "The selected network backup disk does not support the required capabilities." UserInfo={NSLocalizedDescription=The selected network backup disk does not support the required capabilities., NSLocalizedRecoverySuggestion=Please be sure Time Machine capabilities are enabled on the server for this volume or choose a different network backup volume.} 2026-01-23 15:02:01 Unmounted '/Volumes/TimeMachine' 2026-01-23 15:02:01 Limiting logging for limit: aFewTimes key: "map auto_home" 2026-01-23 15:02:02 Limiting logging for limit: aFewTimes key: "map auto_home"/etc/samba/smb.conf from the container:[global] access based share enum = no hide unreadable = no inherit permissions = no load printers = no log file = /var/log/samba/log.%m logging = file max log size = 1000 security = user server min protocol = SMB2 ntlm auth = no server role = standalone server smb ports = 445 workgroup = TIMEMACHINE vfs objects = acl_xattr fruit streams_xattr fruit:aapl = yes fruit:nfs_aces = yes fruit:model = TimeCapsule8,119 fruit:metadata = stream fruit:veto_appledouble = no fruit:posix_rename = yes fruit:zero_file_id = yes fruit:wipe_intentionally_left_blank_rfork = yes fruit:delete_empty_adfiles = yes [TimeMachine] path = /opt/timemachine inherit permissions = no read only = no valid users = timemachine vfs objects = acl_xattr fruit streams_xattr fruit:time machine = yes fruit:time machine max size = 2 T

I was able to install the Docker solution, give it a custom network IP, and configure the mount point fine. I see the mount point and changed ownership to user:group 1000. The Mac sees the volume as a Time Machine destination (and I can even mount it as a volume and write files/folders to it) but when attempting to configure it in the Settings - Time Machine panel I get: The selected network backup disk does not support the required capabilities. Please be sure Time Machine capabilities are enabled on the server for this volume or choose a different network backup volume. I double-checked and don't think I missed a step. Any idea why this isn't working from a Mac running 15.7.3? Not Tahoe. I've tried mapping the Time Machine volume to both a btrfs and zfs pool.

I am using a Ubiquiti switch, which apparently is hardcoded to use: BONDING_XMIT_HASH_POLICY[0]="layer3+4" BONDING_LACP_RATE[0]="fast" However, adding those commands into the /boot/config/network.cfg file only applies the LACP Rate setting. The solution was to create a /boot/config/modprobe.d/bonding.conf file with the following line: options bonding xmit_hash_policy=1 lacp_rate=fast

You're running the container with bridge networking, so the IP address is 172.17.0.8 with port 3000. Your log shows Port 3210 is the default port for the web UI. It's not the port listening for API connections, which is 3000. I recommend you re-check your network configuration on the OpenFanController. Here's how to rule out a network issue or confirm the controller is listening correctly. From any device on the network, confirm that you can ping the IP address of the controller. If you want the controller to just use the IP address of the unRaid server as the destination, set the network type to host. You then just configure the OpenFANService to connect to the unRaid server IP address. If you want to use the fixed IP of 192.168.0.5 (which doesn't appear to be the IP of your unRaid server) then you need to change the network type to one configured for that network. Once you confirm that the network packets can be delivered to the controller, confirm the controller is listening on that port. From any device on the network, do a "telnet <ip of controller> <port>". If it's able to connect, you'll see the telnet session clear your screen showing that it connected. You can then do a ctrl-c or ctrl-] to exit the session. This will help you step through where it's failing. If the telnet works, then you at least have confirmed there's nothing on the network layer causing the issue. From what I can tell, you have a network issue and it's not the OpenFAN controller or service.

Sure. I bought them for the limited scenario where the drives are getting up to 50C (but this seems reduced now that all of my data has been copied completely to Unraid). The Noctuas that I currently have are limited to 1500 RPM. I'm fine to burst the fan speeds for short periods of time. Yes, they're loud but my Unraid system is in a place where period noise increases aren't a problem. It looks like the fan controller can do about 4000 RPM on these fans without exceeding the fuse limit. When these fans are at 1500 - 2000 RPM they aren't any louder to my ears.

It's one fan (with the plan to go to 3 for the drives in my case). I didn't populate out all 10 fans with that model. But, I'm not inclined to swap out fuses to force things beyond spec so I'll just find the max PWM the controller can handle with those fans.

Strangely, I bought a 6000 RPM fan and when either trying to manually set the fan to 100% PWM or MadMax (which should do the same), the 6000 RPM fan will just keep spinning up to about 4800 RPM then slow to about 2000 RPM then spin up again. It just does this repeatedly. It's Fan #3 in the log. The fan is a Delta model (https://www.delta-fan.com/qfr1212ghe.html). It is 12V 2.7A. Just wondering if the controller board can't sustain that amperage. Logs: Jun 28 2025 17:19:56.560 pid:7 webserver.py 145 INFO Request:STATUS Jun 28 2025 17:19:56.560 pid:7 FanCommander.py 24 DEBUG CMD:0 Data: None Jun 28 2025 17:19:56.560 pid:7 FanCommander.py 25 DEBUG Sending >00 Jun 28 2025 17:19:56.562 pid:7 FanCommander.py 31 DEBUG [0002537527][I][HCOMM] >00 Jun 28 2025 17:19:56.562 pid:7 FanCommander.py 31 DEBUG [0002537527][D][HCOMM] host_comm_tick: Start character found (Len=2) Jun 28 2025 17:19:56.562 pid:7 FanCommander.py 31 DEBUG [0002537527][D][HCOMM] host_comm_parse_package Jun 28 2025 17:19:56.562 pid:7 FanCommander.py 31 DEBUG [0002537527][D][HCOMM] A=00 H:0x00 Jun 28 2025 17:19:56.562 pid:7 FanCommander.py 31 DEBUG [0002537527][D][HCOMM] CMD_FAN_ALL_GET_RPM Jun 28 2025 17:19:56.562 pid:7 FanCommander.py 31 DEBUG <00|00:080B;01:07FD;02:059F;03:09AD;04:05B4;05:0000;06:0000;07:0000;08:0000;09:0000; Jun 28 2025 17:19:56.562 pid:7 FanCommander.py 33 DEBUG Response: '<00|00:080B;01:07FD;02:059F;03:09AD;04:05B4;05:0000;06:0000;07:0000;08:0000;09:0000;' Jun 28 2025 17:19:56.562 pid:7 FanCommander.py 46 DEBUG {0: 2059, 1: 2045, 2: 1439, 3: 2477, 4: 1460, 5: 0, 6: 0, 7: 0, 8: 0, 9: 0} Jun 28 2025 17:20:00.561 pid:7 webserver.py 145 INFO Request:STATUS Jun 28 2025 17:20:00.561 pid:7 FanCommander.py 24 DEBUG CMD:0 Data: None Jun 28 2025 17:20:00.561 pid:7 FanCommander.py 25 DEBUG Sending >00 Jun 28 2025 17:20:00.563 pid:7 FanCommander.py 31 DEBUG [0002541529][I][HCOMM] >00 Jun 28 2025 17:20:00.563 pid:7 FanCommander.py 31 DEBUG [0002541529][D][HCOMM] host_comm_tick: Start character found (Len=2) Jun 28 2025 17:20:00.563 pid:7 FanCommander.py 31 DEBUG [0002541529][D][HCOMM] host_comm_parse_package Jun 28 2025 17:20:00.563 pid:7 FanCommander.py 31 DEBUG [0002541529][D][HCOMM] A=00 H:0x00 Jun 28 2025 17:20:00.563 pid:7 FanCommander.py 31 DEBUG [0002541529][D][HCOMM] CMD_FAN_ALL_GET_RPM Jun 28 2025 17:20:00.563 pid:7 FanCommander.py 31 DEBUG <00|00:0804;01:07FD;02:0597;03:102B;04:05B0;05:0000;06:0000;07:0000;08:0000;09:0000; Jun 28 2025 17:20:00.564 pid:7 FanCommander.py 33 DEBUG Response: '<00|00:0804;01:07FD;02:0597;03:102B;04:05B0;05:0000;06:0000;07:0000;08:0000;09:0000;' Jun 28 2025 17:20:00.564 pid:7 FanCommander.py 46 DEBUG {0: 2052, 1: 2045, 2: 1431, 3: 4139, 4: 1456, 5: 0, 6: 0, 7: 0, 8: 0, 9: 0}

I recommend referring to this thread as it has both a discussion and a solution that is working for people.

Wow. I just found this post after spending some hours resolving yesterday. My Configuration In my environment, I typically host my Docker containers on the same network (10.0.0.0/24) that all of my devices are configured on - including the Unraid server at 10.0.0.10. I created a macvlan based custom Docker network on that same network, and each Docker container has an explicitly assigned IP address in the same network. My unRaid has a dual 10GB network card with the interfaces bonded with 802.3ad on two aggregated ports on a Unifi 10GB switch (interface br1) with the 10.0.0.10 statically assigned. For some reason, my Docker containers on the same network could not communicate with the unRaid host and vice versa. The final solution I found worked was to manually create a second interface called "br1.macvlan0" on its own IP that explicitly bridged with the br1 interface. After that, the Docker containers and host (Unraid server at 10.0.0.10) could not communicate seamlessly. I installed User Scripts and added one to run the following explicitly at array start but you can have it start whenever appropriate for your situation. #!/bin/bash ip link add link br1 name br1.macvlan0 type macvlan mode bridge ip addr add 10.0.0.2/24 dev br1.macvlan0 ip link set dev br1.macvlan0 up The main difference from the OP (which I will try next as it's cleaner) is that I had added a second IP address as the bridge.

It appears I'm not understanding the process to move data within Unraid. Let me lay out another scenario, which appears the same to me. 1. Have a pool called "Cache" with two mirrored 1TB drives (M.2). 2. It shows a combination of data stored on it from different shares, but is consuming approximately 910GB of the 1TB. 3. There is a share called MEDIA that is set to Primary of Array, which means no Secondary and Mover is configurable. 4. When I do a Compute on the MEDIA volume, it shows 858GB on the "Cache" pool and 9.2TB on the "Datapool" and the rest spread across the disks in the Array. What's the process to move / consolidate the data to the array?

It's not, but that might be my "fault". I honestly do not recall if I also did an rsync on the files on Datapool to the array. If we can assume I did not do a manual rsync, should the process I described have moved all of the data to the array and free up the space on the Datapool? I guess my core question is, is the right procedure to set the array as primary then ensure Mover is enabled and wait? Then I know it's done when the utilization on Datapool goes to 0%? The reason this is my core question is I've done this with other shares and even after quite some time (days, even) when I do a Compute on a share with the Array configured as the Primary storage and no Secondary defined I still see data is sitting on other storage (especially the SSD Cache pool I created).

I'm not sure if this is the same problem, but I'll post this reply just in case it perhaps helps someone discover the solution for this particular issue. I don't use VLANs but it might be similar. My Configuration In my environment, I typically host my Docker containers on the same network (10.0.0.0/24) that all of my devices are configured on - including the Unraid server at 10.0.0.10. I created a macvlan based custom Docker network on that same network, and each Docker container has an explicitly assigned IP address in the same network. My unRaid has a dual 10GB network card with the interfaces bonded with 802.3ad on two aggregated ports on a Unifi 10GB switch (interface br1) with the 10.0.0.10 statically assigned. For some reason, my Docker containers on the same network could not communicate with the unRaid host and vice versa. The final solution I found worked was to manually create a a second interface called "br1.macvlan0" on its own IP that explicitly bridged with the br1 interface. After that, the Docker containers and host (Unraid server at 10.0.0.10) could not communicate seamlessly. I installed User Scripts and added one to run the following explicitly at array start but you can have it start whenever appropriate for your situation. #!/bin/bash ip link add link br1 name br1.macvlan0 type macvlan mode bridge ip addr add 10.0.0.2/24 dev br1.macvlan0 ip link set dev br1.macvlan0 up To be fair, I'm not sure what - if any - technical network security issues this could create but I can't easily think of them as if I wanted that segregation I could explicitly create it. Hope this helps those above resolve what appear to be a similar issue. If you want more explanation of those commands, I suggest throwing them into one of the GPT LLMs (ChatGPT, Gemini, Claude, etc) and ask for more detailed explanations.

QUESTION: Before I remove a pool and reuse its disks, how can I confirm the Mover has completed moving all of the data off of it? BACKGROUND When I initially set up Unraid, I didn't have a proper understanding of how best to set up my system. Initially, I created a pool called "Datapool" with four 6TB disks. I then copied about 10TB of data to it. Ultimately, I realized that I really wanted an array. I created the array with two large parity drives (24TB and 18TB) plus four 10TB disks. I then went into all of my shares that were showing with data on "Datapool" and switched the primary storage to the array. Over time, the array utilization seemed to include the size of the "Datapool". Once the data appeared to be on the array, I tested by removing the "Datapool" and ejecting the disks temporarily. It appears that the data is now completely on the array as I was able to access it (but did only do some sample checking). I then reinserted the "Datapool" drives and recreated the pool. All of the data continued to appear there too. Before I remove the pool and reuse the disks, I want to ensure there's no data lost.