We are using an asynchronous FPolicy engine to collect file audit events from ONTAP. As shown in the logs below, when FPolicy server goes down, ontap exhausts all 20 of its configured reconnect attempts in just 39 seconds (from 09:41:48 to 09:42:27). Once these retries are exhausted, the engine transitions to a permanent disconnected state (TCP Connection to FPolicy server failed) and  does not auto-reconnect when the server comes back online even after a minute.  Event logs in the diagnostic mode -  Time Node Severity Event ------------------- ------------------------- --------- --------------------------- 7/15/2026 09:42:27 FsxId04eda4994b6009ffe-01 ERROR fpolicy.server.connectError: Node failed to establish a connection with the FPolicy server "x.y.z.z" of policy "cloud_poc_policy" for Vserver ntfs-fsx (reason: "TCP Connection to FPolicy server failed."). 7/15/2026 09:42:27 FsxId04eda4994b6009ffe-02 ERROR fpolicy.server.connectError: Node failed to establish a connection with the FPolicy server "x.y.z.z" of policy "cloud_poc_policy" for Vserver ntfs-fsx (reason: "TCP Connection to FPolicy server failed."). 7/15/2026 09:41:48 FsxId04eda4994b6009ffe-01 ERROR fpolicy.server.disconnect: Connection to the FPolicy server "x.y.z.z" of policy "cloud_poc_policy" is broken for Vserver ntfs-fsx ( reason: "Connection to FPolicy server is broken(EPIPE) received." ). 7/15/2026 09:41:48 FsxId04eda4994b6009ffe-02 ERROR fpolicy.server.disconnect: Connection to the FPolicy server "x.y.z.z" of policy "cloud_poc_policy" is broken for Vserver ntfs-fsx ( reason: "Connection to FPolicy server is broken(EPIPE) received." ). Engine Config -  vserver fpolicy policy external-engine show -vserver ntfs-fsx -engine-name cloud_poc_engine -instance Vserver: ntfs-fsx Engine: cloud_poc_engine Primary FPolicy Servers: x.y.z.z Port Number of FPolicy Service: 32200 Secondary FPolicy Servers: - External Engine Type: asynchronous SSL Option for External Communication: no-auth Timeout for Canceling a Request: 20s Timeout for Aborting a Request: 40s Interval for Sending Status Requests: 30s Max Reconnect Attempt: 20 Maximum Outstanding Requests for FPolicy Server: 500 Timeout for Disconnecting Non-responsive Server: 100s Interval for Sending Keep-Alive Messages: 2m FQDN or Custom Common Name: - Serial Number of Certificate: - Certificate Authority: - Receive Buffer Size: 262144 Send Buffer Size: 1048576 Session ID Purge Timeout During Reconnection: 10s Is Resiliency Feature Enabled: true Maximum Notification Retention Duration: 10m Directory for Notification Storage: /data/ External Engine Format: xml Policy config -  Vserver: ntfs-fsx Policy: cloud_poc_policy Events to Monitor: cloud_poc_event FPolicy Engine: cloud_poc_engine Is Mandatory Screening Required: false Allow Privileged Access: no User Name for Privileged Access: - Is Passthrough Read Enabled: false Persistent Store Name: - Documentation https://docs.netapp.com/us-en/ontap/nas-audit/plan-fpolicy-external-engine-config-concept.html#what-the-advanced-external-engine-options-are  doesn't have any info on this.    ... View more

If you are a new NetApp customer or have colleagues who are, check out the Solution Series. These webinars with NetApp experts give you information on getting the most from your NetApp purchase. This month, the topics are:    October 5th 9am PST- ActiveIQ Unified Manager October 19th 9am PST - System Manager Demo   Use this handy link to register. Once you register, you'll get details on how to join the meeting.          ... View more

Hi All,    i want to start a Post for 9.19.1RC1 Feedbacks from you all. Here you can post all things you discovered which could be done better in GA Release.   i noticed ssh-rsa is still listed for ssh. the ssh.sshrsa.defDisabledFuture error was brought in 9.16.1 -  imho this should be removed in 9.19.1.    hhos1::> security ssh show Is ssh-rsa Max in Publickey Auth Login Key Exchange MAC Host Key Algorithms Retry Grace Vserver Ciphers Algorithms Algorithms Algorithms Enabled Count Time -------------- ------------ -------------- -------------- -------------- ------------ ----- ----- hhos1 aes256-ctr, diffie- hmac-sha2-256, ecdsa-sha2- true 6 30 aes192-ctr, hellman-group- hmac-sha2-512, nistp256, aes128-ctr, exchange- hmac-sha2-256- ssh-rsa, aes128-gcm, sha256, etm, ssh-ed25519 aes256-gcm ecdh-sha2- hmac-sha2-512- nistp256, etm, umac-64, ecdh-sha2- umac-128, nistp384, umac-64-etm, ecdh-sha2- umac-128-etm nistp521, curve25519- sha256 hhos1vs1 aes256-ctr, diffie- hmac-sha2-256, ecdsa-sha2- true 6 30 aes192-ctr, hellman-group- hmac-sha2-512, nistp256, aes128-ctr, exchange- hmac-sha2-256- ssh-rsa, aes128-gcm, sha256, etm, ssh-ed25519 aes256-gcm ecdh-sha2- hmac-sha2-512- nistp256, etm, umac-64, ecdh-sha2- umac-128, nistp384, umac-64-etm, ecdh-sha2- umac-128-etm nistp521, curve25519- sha256 2 entries were displayed.   BR  Hannes   ... View more

Introducing a new FAS into a Hyper-V 2019 cluster, ONTAP 9.15.1P8, SVM joined to AD domain and configured with SMB, shares set up for Hyper-V usage, options and permissions configured per NetApp instructions. Everything seems to work, VMs are running, but if I try to edit (expand) a VHD using failover cluster console running on a host different from the one hosting the VM, I get the following message:   ----------------------------- Unable to edit virtual disk \\svm\share\path\disk.vhdx   Failed to get the disk information.   Account does not have permission to open attachment.   Failed to get the disk information:   ": account does not have permission required to open attachment '\\svm\share\path\disk.vhdx'. Error: 'General access denied error' (0x80070005). (Virtual machine ID ) -----------------------------   This does not happen if I RDP into the the host that is running the VM and use the same console there. Delegation is enabled in AD between hyper-v hosts, and SMB delegation is also enabled from the filer's computer object in AD to the hyper-v computer host objects. Referral is enabled in the SVM CIFS options. Filesystem permissions seem fine; both the user making the changes and the hyper-v servers themselves have full control defined at the share/volume root. This happens both to new VMs and VMs migrated from previous storage. Anything I'm missing here? ... View more