Does this apply even when the multiprotocol dataset with NFS share was never used for Time Machine?
I use NFS and dabbled with multi protocol at one point just to test it, but my TimeMachine share has always been just SMB using the Multi-User Time Machine preset.
The way multi protocol handles permissions/ACLs confused me just enough that I didn’t want to deal with it just then, and I only enable NFS on generic datasets when it’s a dataset that (1) only gets used by BSD/Linux/MacOS clients where using SMB might create issues (e.g., mounting a database storage dataset for MariaDB, or Proxmox’s ISO dataset).
In my case I had another share that still had multi-protocol enabled. When I changed that share to something else then my time machine share started working.
That’s the reason for these forums. You’ve picked the most complex issue where there is significant change. The summary is:
Apps like NextCloud do not have configurable IP addresses until Fangtooth and an App catalog refresh in June. 25.04.1 timeframe. Just keep using CORE until then if you wish.
You can run Portainer and Dockge as an App and then manually configure IP addresses for custom Apps, including NextCloud. That is in 24.10.2 and 25.04-RC.1
The Jail-like technology is called Jailmaker and is being replaced with Incus-LXC in Fangtooth. This allow IP addresses to be configured and then do a manual install of NextCloud. That is in 25.04-RC.1.
Just update to the RC and nothing to declare. I discovered the Docker registry setup inside the apps and wish it would help with dockge not able to update image from private registry but it does not. I still have to login via ssh, login to my docker registry and pull the latest image… too bad it could have been great.
That’s … unfortunate. At least we’re well aware of it now, otherwise that could have driven a lot of people crazy. Not obvious what’s happening there when it’s going wrong.
Understood! @ essinghigh was so kind and just solved the problem for me in my liked thread anyway!
I installed Pi-hole and forgot about it which blocked my port!
I’ve discovered a bug with RC1’s implementation of Incus VMs. Sync writes are getting ignored. I filed a bug since this seems like a potentially big oops if someone is assuming the underlying ZFS will keep all their VMs safe. NAS-135028
Those of you running VMs, set your zvols to “sync: always” to guarantee data integrity in your VMs. Docker apps and LXC instances are not affected by this issue.
You’ve been told at least twice (by me) that you don’t need it–point HAProxy to the correct IP/port and you’re good to go. There’s simply no need, in 99+% of cases, for per-app IPs (although they are coming once iX drops support for migrating apps from 24.04, in well under the year+ that they said it would be supported).
This has been answered as well: create a sandbox under EE, or a container instance under Fangtooth, and you can install whatever you like in there–either of those is the rough equivalent of a jail under CORE. Or, of course, use a VM. But I’m not going to be writing a script for that scenario.
Have you tried rebooting your Windows client? If there were shares configured for NFS + SMB compatibility then we had to make a global SMB change to disable SMB2 leasing. There may be some caching of share configuration in the Windows client.
Is this data that is being concurrently accessed by local processes (or NFS clients)? It might be that something is breaking oplocks during your SMB and causing delays.
