Scott O.

Checking through SnapLogic docs, this is a known challenge when connecting a Linux-based Groundplex to a Windows SMB share. The error ERR_MOUNTERROR typically points to one of several root causes. Here's a structured checklist to work through: ✅ 1. Verify Your SMB Account Configuration This is the most common cause (as confirmed by community reports). In SnapLogic Manager, check your SMB Account and make sure all three fields are correct: FieldNotesDomainMust be the Active Directory / NetBIOS domain name of the Windows host. This field is often left blank and causes mount failures on Linux.UsernameThe Windows account username (without domain prefix)PasswordThe correct password for that account

💡 Even if smbclient works from the Linux command line, SnapLogic uses its own Java-based SMB library (JCIFS), which handles authentication differently — hence why it can work from CLI but fail in Snap.

✅ 2. Check the SMB URL Format Make sure the Directory field in your File Poller uses the correct format:

smb://<server_name_or_IP>/<share_name>/<optional_subfolder>/

Example:

smb://my_server/my_share/my_dir/

✅ 3. SMB Protocol Version Mismatch (Very Common on Modern Windows) Modern Windows servers (2012+) often disable SMBv1 by default. SnapLogic's JCIFS library may attempt SMBv1 negotiation by default, which would result in a mount error. You can force a higher SMB version via JVM options in your Groundplex Node Properties (in SnapLogic Manager → Snaplex → Update → Node Properties → Global Properties): KeyValuejcc.jvm_options-Djcifs.smb.client.minVersion=SMB202 -Djcifs.smb.client.maxVersion=SMB300

⚠️ If you already have a jcc.jvm_options value, append these flags rather than replacing the existing value. Restart the Groundplex node after applying.

✅ 4. Network & Port Connectivity Even though smbclient works from the Linux machine, verify that:

✅ 5. Linux System Packages (Less Common) While SnapLogic uses Java/JCIFS internally (not OS-level mounting), ensure the Linux Groundplex host isn't missing dependencies that could affect Java's native library resolution:

# Check if cifs-utils / samba-client are installed (optional but useful for diagnostics)
rpm -qa | grep -i samba
apt list --installed | grep -i cifs

🔁 Summary Checklist #CheckAction1SMB Account Domain fieldFill in the Windows AD domain name2URL formatUse smb://server/sharename/subdir/3SMB versionAdd JVM options for SMBv2/v34Port 445 reachabilityTest from Groundplex host5DNS resolutionTry IP if hostname fails Start with items 1 and 3 as they are the most frequent culprits for this exact error on Linux Groundplexes connecting to modern Windows servers.

Hi Andrei - There are several approaches depending on what type of "account" you're referring to. Let me clarify the options available: Disabling an Account in SnapLogic The approach depends on what type of account you want to disable: 👤 User Account (preventing login/access) SnapLogic doesn't have a single "disable" toggle for user accounts, but you can effectively prevent a user from accessing the platform using one of these methods:

⚙️ Triggered Task (preventing execution) If you want to prevent a Triggered Task from being executed:

ℹ️ This prevents the Task from being triggered without deleting it.

🔑 Snap/Integration Account (e.g., REST, Salesforce, DB credentials) SnapLogic does not have a built-in disable option for Snap accounts (credential accounts). Your options are:

💡 Recommendation: If your goal is to keep a user account intact but prevent any access, the safest approach is to revoke all application access via Admin Manager. The account remains in the system and can be re-enabled at any time.

Hi Karan – This is a good question, and here's a thorough breakdown based on SnapLogic's task architecture and available documentation: 🔍 Understanding the Two Fields When you use the SnapLogic Read Snap with Asset type = TASK, the output document contains both fields because SnapLogic stores scheduling information at two different layers: 📌 schedule Field This is the SnapLogic-level, UI-friendly representation of the task's scheduling configuration. It reflects what you configured in the Create Task dialog, including: Property Example Start date/time 2025-01-01T09:00:00 Repeat frequency Every 1 day, Every 15 minutes Time zone America/New_York End conditions Never, After N runs, On Date/Time Blackout dates Defined time periods Cron expression Human-readable Cron pattern Think of schedule as the source of truth for the SnapLogic platform — it's what the UI reads and writes. 📌 trigger Field This is the underlying scheduling engine's configuration — SnapLogic uses Quartz Scheduler internally. The trigger field contains the low-level Quartz trigger definition, which may include: Property Description Quartz cron expression The engine-level cron format (may differ from UI representation) Misfire instructions What happens if a trigger is missed (grace period behavior) Next fire time When the trigger is next expected to fire Trigger state Active, paused, etc. Think of trigger as the runtime execution engine's instruction set — it's what actually fires the pipeline. ⚖️ Why Both Exist? They serve different purposes and are maintained somewhat independently: [ SnapLogic UI Schedule Config ] → "schedule" field ↓ (translated/compiled into) [ Quartz Engine Trigger Config ] → "trigger" field In normal operation (creating/editing a task via the UI), SnapLogic keeps these in sync automatically. However, when you read the raw metadata, you see both layers separately. ⚠️ Impact of Updating via Metadata Update Snap This is where you need to be very careful. The official SnapLogic documentation explicitly notes: ⛔ Known Limitation: Trying to use the SnapLogic List Snap along with the Update Snap to alter Task field values causes a 400 HTTP error and doesn't update the Tasks as intended. Here's a summary of risks: Action & Risk Update schedule only The Quartz trigger may become out of sync, potentially causing unexpected firing behavior Update trigger only The SnapLogic UI will display incorrect/stale schedule info; the actual execution may differ from what's shown in Manager Update both High risk of inconsistency unless both are carefully coordinated and formatted correctly Using Metadata Update for Tasks May result in a 400 HTTP error per known limitations of the Metadata Snap Pack ✅ Best Practices & Recommendations

💡 Pro Tip: When using the SnapLogic Read Snap for tasks, avoid checking the Normalized checkbox, as it strips internal fields that are necessary for creating or updating assets correctly.

Checking SnapLogic docs, here's a thorough breakdown of what's happening and the known limitations: 🔍 "Do Not Start a New Execution If One Is Already Active" — Known Limitations ✅ How It's Supposed to Work When this option is enabled on a Triggered Task, SnapLogic should:

⚠️ Known Limitation: Pipeline Execute Snap Scenario The official SnapLogic documentation explicitly calls out the following limitation: "For Cloud Triggered Tasks in scenarios where multiple pipelines are triggered via the Pipeline Execute Snap, the Do not start another execution checkbox setting is not enforceable." This means if your task is being invoked (directly or indirectly) through a Pipeline Execute Snap, the concurrency guard will not work reliably. 🧩 Why You May See Concurrent Executions (~1 second apart) A few factors could explain the behavior you observed: Pipeline Execute Snap If the trigger chain involves a Pipeline Execute Snap, the setting is explicitly not enforced. Race condition at the control plane When multiple requests arrive nearly simultaneously (~1 second apart), the control plane may not have registered the first execution as "active" before the second and third requests are evaluated. Cloud URL throttling Cloud Triggered Tasks go through the control plane, which has a default concurrent API limit of 10. The concurrency check and the "do not start" check are separate mechanisms. Ultra Snaplex behavior Ultra Tasks/Snaplexes are designed for high-throughput, always-on execution. The "do not start" setting is primarily documented in the context of standard Triggered and Scheduled Tasks — behavior on an Ultra Snaplex may differ. 📋 Additional Considerations

🛠️ Recommended Workarounds

Hi Alan - Here is what SnapGPT recommended, to get you some things to consider quickly: This covers three important areas: secure PEM storage, Python JWT libraries in Script Snap, and wiring it all together. Let me break this down thoroughly. 🔐 1. Secure PEM Storage — Recommendations Here's a ranked comparison of your options: ✅ Option A: SnapLogic Secrets Management (Most Secure — Recommended) If you're on a Groundplex, this is the gold standard:

✅ Option B: SnapLogic File System (SLFS) (Good for Groundplex/Cloudplex)

⚠️ Option C: Pipeline Parameter (Convenient but Less Ideal)

❌ Avoid: Hardcoding in Script Never embed the PEM directly in the Script Snap code — no encryption, fully visible in pipeline config. 🐍 2. Python Libraries Available in Script Snap for JWT/RS256

⚠️ Critical caveat: The Script Snap runs on Jython 2.7.x (JVM-based Python), not CPython. This has major implications for library availability.

What's available natively (Jython + JVM): LibraryAvailable?Notesjava.security / javax.crypto✅ YesFull JVM crypto — can do RSA signingorg.bouncycastle✅ Likely (if on Groundplex)Powerful crypto librarybase64, hashlib, hmac✅ Yes (Jython stdlib)Basic crypto primitivesjson✅ YesStandard JythonPyJWT❌ NoCPython-only, not installable in Jythoncryptography (Python pkg)❌ NoRequires CPython C extensionspython-jose❌ NoCPython-only ✅ Recommended Approach: Use Java Crypto via Jython Since Jython has full access to the JVM, you can use Java's built-in RSA signing directly:

from com.snaplogic.scripting.language import ScriptHook
import java.security.KeyFactory as KeyFactory
import java.security.Signature as Signature
import java.security.spec.PKCS8EncodedKeySpec as PKCS8EncodedKeySpec
import java.util.Base64 as Base64
import json

class JWTScript(ScriptHook):
    def __init__(self, input, output, error, log):
        self.input = input
        self.output = output
        self.error = error
        self.log = log

    def base64url_encode(self, data):
        encoder = Base64.getUrlEncoder().withoutPadding()
        if isinstance(data, str):
            data = data.encode('utf-8')
        return encoder.encodeToString(data).rstrip('=')

    def sign_jwt(self, header, payload, pem_key_str):
        # Strip PEM headers and decode
        pem_clean = pem_key_str \
            .replace("-----BEGIN PRIVATE KEY-----", "") \
            .replace("-----END PRIVATE KEY-----", "") \
            .replace("-----BEGIN RSA PRIVATE KEY-----", "") \
            .replace("-----END RSA PRIVATE KEY-----", "") \
            .replace("\n", "").strip()

        key_bytes = Base64.getDecoder().decode(pem_clean)
        key_spec = PKCS8EncodedKeySpec(key_bytes)
        kf = KeyFactory.getInstance("RSA")
        private_key = kf.generatePrivate(key_spec)

        header_enc = self.base64url_encode(json.dumps(header))
        payload_enc = self.base64url_encode(json.dumps(payload))
        signing_input = "%s.%s" % (header_enc, payload_enc)

        signer = Signature.getInstance("SHA256withRSA")
        signer.initSign(private_key)
        signer.update(signing_input.encode('utf-8'))
        sig_bytes = signer.sign()

        signature = self.base64url_encode(sig_bytes)
        return "%s.%s" % (signing_input, signature)

    def execute(self):
        while self.input.hasNext():
            data = self.input.next()
            pem_key = data.get("pem_key")  # passed in from pipeline param or SLFS

            header = {"alg": "RS256", "typ": "JWT"}
            payload = {"sub": "service-account", "iss": "your-client-id", "iat": 1234567890}

            token = self.sign_jwt(header, payload, pem_key)
            self.output.write({"jwt_token": token})

hook = JWTScript(input, output, error, log)

💡 Note: If your PEM is in PKCS#1 format (BEGIN RSA PRIVATE KEY), you may need BouncyCastle to parse it. PKCS#8 format (BEGIN PRIVATE KEY) works directly with Java's KeyFactory.

🔗 3. Recommended End-to-End Architecture

[Pipeline Param / SLFS] 
        ↓ (PEM key injected)
[Script Snap — Jython RS256 JWT signing]
        ↓ (outputs JWT token)
[Mapper Snap — builds Authorization header]
        ↓
[HTTP Client Snap — REST call with Bearer token]

📋 Summary Recommendations ConcernRecommendationPEM StorageSecrets Management (Groundplex) > SLFS > Pipeline ParamJWT Signing LibraryUse Java Signature (SHA256withRSA) via Jython JVM interopPEM FormatConvert to PKCS#8 for easiest Java compatibilitySecure Python ModeBe aware of scripting.python.security.enabled — if enabled on your Snaplex, some modules may be blockedNewlines in PEMWhen passing via Pipeline Execute, use explicit \n characters