Can Two VLANs Access the Same SMB Share With Different Permissions?

Yes, but use network policy to control which clients can reach SMB and user or group ACLs to control what authenticated users can do; VLAN membership alone is not file authorization.

This becomes a real compatibility question when trusted and guest or IoT VLANs need different access to one NAS share without duplicating the stored files. Start with a disposable path or account, keep the previous working state available, and judge the design by the original workload rather than by a one-time connection test.

Define the Scheduling and Lifecycle Contract

The supported branch is firewall reachability combined with identity-based share and filesystem ACLs. The competing branch is source-address rules treated as a substitute for user authentication. Record versions, identities, addresses, mount paths, permissions, and the current observable state before changing either branch.

The relevant Samba host access rules defines the first compatibility boundary. Use it to constrain the claim, then verify the same behavior on this exact home server instead of treating a documented feature as proof that the full design works.

Write the decision rule before testing: success must produce each identity receives the same permissions regardless of route while the disallowed VLAN cannot open an SMB session; failure includes a user gains rights by changing networks, cached credentials mask the test, or filesystem ACLs contradict the share policy. This prevents a partial connection or clean command exit from being misread as end-to-end compatibility.

Execute the Job With Production Identity

Use one controlled discriminator: create two test users, connect from one client in each VLAN, verify firewall paths, then attempt read, create, rename, and delete operations. Hold the client, workload, file set, account, and timing constant so the changed component is the only plausible explanation.

Use SMB permission layers to choose the second observation that matters for this path. Capture both sides of the transaction: resolver or route, negotiated protocol, process identity, exit status, latency, transferred bytes, and any recovery event.

Repeat the test after the lifecycle event named in the title—recreation, reconnect, remount, restart, failover, or client change. A design that works only while old sockets, caches, or credentials remain warm has not passed.

smbclient -L //nas -U testuser
# repeat read/create/rename/delete from one client per VLAN

Interpret Overlap, Failure, and Exit State

PASS: each identity receives the same permissions regardless of route while the disallowed VLAN cannot open an SMB session. Save the exact versions and topology that produced this state, because the conclusion applies to those conditions rather than every implementation of the protocol.

FAIL: a user gains rights by changing networks, cached credentials mask the test, or filesystem ACLs contradict the share policy. Check shared dependencies such as DNS, MTU, identity, firewall state, storage latency, and cached sessions before declaring either primary branch responsible.

EXCEPTION: disconnect sessions, clear cached credentials, restore the last ACL set, and separate network reachability from file authorization. Do not widen privileges, delete source data, weaken transport security, or replace working storage until a repeatable observation identifies which boundary failed.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verify the Next Scheduled Run, Not Just the First

Apply only the action matched to the observed branch, then rerun the original workload. Keep the design only when each identity receives the same permissions regardless of route while the disallowed VLAN cannot open an SMB session across two relevant lifecycle cycles and under the expected concurrent load.

Use the VLAN access boundaries to verify the closest dependent workflow. Its access, timing, and recovery behavior must remain unchanged while the new design is active.

Stop and return to the saved state if a user gains rights by changing networks, cached credentials mask the test, or filesystem ACLs contradict the share policy. Escalate with timestamps, exact versions, route or mount evidence, and the smallest reproduction rather than adding another workaround.

Cross-check the result against the SMB session continuity so risk is not merely moved into another network, identity, backup, or storage layer.

For VLAN-aware SMB permissions, the qualified answer is therefore the opening judgment—not an unconditional yes. The observable pass state is the acceptance line; the fail state is the rollback line.

FAQ

Can hosts allow create read-only access for one VLAN?

It controls connection sources, not per-file rights; use authenticated ACLs for read and write differences.

Why does a denied user still open files?

An existing session or cached credential may remain active; disconnect it before testing the new policy.

Should the NAS join a directory service?

Only when centralized identity reduces household complexity enough to justify the dependency; local groups can be sufficient.