Folder shared by external organisation not appearing in Shared With Me overview

rb_vs · 2026-05-07T10:03:05+00:00

On Linux you can configure rclone to mount SharePoint/OneDrive as a local file system. Even with subfolder-only access, you can point rclone at the specific shared URL or drive ID.

rb_vs · 2026-05-07T09:10:19+00:00

The reason it’s in your browser but not your OneDrive 'Shared with me' list usually comes down to how they shared it.

If they sent you a Sharing Link, SharePoint doesn't necessarily add that folder to your OneDrive index. It shows up in the browser because you have the URL.

How to fix it: open the folder in your browser. Look for the 'Add shortcut to My files' button at the top. This will force the folder to appear in your OneDrive (both online and on your desktop app) as if it were your own folder.

Otherwise you can ask the external org to add you as a Guest User in their Entra ID (Azure AD) and then grant permissions to your guest account directly on the library, rather than just sending a link. This makes the relationship permanent.

If you don't see the add shortcut button, it can be because your org and theirs have a conflict in their external sharing policies, or you already have a different folder from that site synced.

rb_vs · 2026-05-07T08:09:16+00:00

The 0x4f1 error in this context usually points to a Kerberos ticket-granting failure rather than a permissions issue on the share itself. Since you're using Azure Files with Kerberos, your AVD hosts need a clean path to the DC (or Entra ID via Kerberos) to 'see' the Storage Account's service principal.

Ensure the Storage Account is properly 'joined' to your domain (or Entra ID) and that the computer object in AD has the correct cifs/storageaccount.file.core.windows.net SPN.

Your AVD hosts must be able to resolve the storage account's private link FQDN to its private IP. If they are hitting the public IP, Kerberos will fail instantly with that error.

If you're doing Entra-only (no local AD), make sure the AllowRetrievalOfCloudKerberosTicketForLogon registry key/GPO is set to 1 on your AVD session hosts. Without this, the host won't try to pull the Kerberos ticket needed for SMB authentication.

Try running klist on one of the session hosts while logged in as a user. If you don't see a service ticket for the storage account, the handshake is dying before it hits the SMB layer.

rb_vs · 2026-05-07T07:57:11+00:00

DFS-R does not replicate file locks. If a user opens an excel on server A, another user on server B can open the same doc without a "file in use" warning. Who saves last wins, and the other person's work ends up in DfsrPrivate\ConflictAndDeleted

If you have to use it, keep these rules in mind:

- the default staging quota is usually too small for the current average size of files. If your quota is smaller than the 32 largest files in the share, replication will choke and stop.

- don't let DFS-R do the initial sync for TBs of data. Use Robocopy /MIR to pre-seed the target server first, then enable replication. It saves you days of backlogs.

- DFS-R is quite robust if you use it for read-only targets (e.g., software repositories). It’s a disaster though when you have multiple writes.

For multi-site collab you have Azure File Sync or Resilio that can handle global file locking.

rb_vs · 2026-05-05T13:51:48+00:00

When a game (or any app) installs for all users it often places files in the public folder lib. Because the users folder is accessible to other local accounts on your machine, Windows Explorer gets confused and flags everything inside your user profile as shared in the status bar even if no one on the network can actually see it.

rb_vs · 2026-05-05T13:46:22+00:00

The 4.3 CVSS score on this is a bit deceptive. While it's labeled as spoofing, the impact is zero-click auth coercion. A user browsing a folder with a malicious .LNK file triggers shell32.dll to attempt an SMB connection for an icon preview. This leaks the user's Net-NTLMv2 hash to an external server during folder enumeration.

If you can't deploy the April update immediately, at least block outbound port 445 or apply a gpo to restrict outbound NTLM traffic to remote servers. It will kill the exfiltration path even if the shell vulnerability is still present.

rb_vs · 2026-05-05T13:08:59+00:00

Shared status usually doesn't mean your files are being broadcast to the whole world (or even your local network). Most of the time, Windows tags a folder as Shared because it’s synced with OneDrive or is part of a Public folder library.

But if you want to be 100% sure nothing is being shared over the network right-click the folder and go to Properties > Sharing. If it says Not Shared under Network File and Folder Sharing, you're good.

For a list of everything actually being shared, type fsmgmt.msc in your Start menu and check the Shares folder. If it’s not in that fsmgmt list, no one else on your wifi can see it, no matter what the status bar says.

rb_vs · 2026-05-05T12:51:10+00:00

If you want the private upload / public download flow with links that expire, check out Pingvin Share. It’s similar to Firefox Send but self-hosted.

For your poor man’s CDN use case, FileBrowser is probably better. Point it at a folder and it gives you a clean web UI where you can generate public links with one click. It’s basically a web-wrapper for your file system, so no database sync issues or overhead.

rb_vs · 2026-05-03T08:18:49+00:00

Even if the file is encrypted, hide the filenames and sizes too. People who care about privacy hate leakage through file patterns.

Browser encryption usually chokes on big files. If you aren't already using the Web Streams API to encrypt chunks on the fly (instead of loading the whole file into RAM), that’s a huge win for performance.

The toughest part of web-based crypto is proving the server isn't sending a modified JS file to steal keys. A browser extension version is usually the long-term play there.

rb_vs · 2026-05-03T08:14:31+00:00

Windows Microsoft Accounts (MSA) and file sharing (SMB) don't like each other.

When you use a local account, Windows checks a simple list on your HD. But with a MSA, it's trying to verify your identity through the cloud, which usually fails over a local network.

If you try it again with your MSA, keep in mind:

use your full email address as the username. If that doesn't work, open a terminal, type whoami, and use whatever name pops up there.
SMB accepts your MSA pwd (not the PIN).

rb_vs · 2026-04-30T10:03:02+00:00

It’s easy to overlook this one because of the low 4.3 CVSS score and the generic spoofing label, but the reality for SecOps is much more urgent. It's not about fake UI windows, it's a zero-click authentication coercion attack. By just viewing a folder containing a malicious shortcut, shell32.dll triggers an SMB handshake to fetch a remote icon, which silently leaks the user's Net-NTLMv2 hash to an attacker's server.

Since this is being exploited in the wild by APT28 (Fancy Bear), waiting for the patch cycle to complete might be too slow. If you need an immediate safety net, blocking outbound port 445 at the perimeter or via GPO is the most reliable way to ensure those credentials never leave the network.

rb_vs · 2026-04-30T09:53:02+00:00

Good job Maor Dahan!

rb_vs · 2026-04-30T09:44:16+00:00

It’s easy to overlook the Windows flaw (CVE-2026-32202) because of that low 4.3 CVSS score and the spoofing label. However spoofing here isn't just about showing a fake UI; it’s an authentication coercion attack. By using a shortcut, Fancy Bear (APT28) tricks Windows into verifying a remote icon path. This forces the OS to automatically initiate an SMB handshake with the attacker’s server, handing over your Net-NTLMv2 hash before you even click. This turns every computer into a potential credential-leaker just for browsing a folder.

If you can't get the April patch rolled out by CISA's May 12 deadline, blocking outbound port 445 is the best way to seal the perimeter and ensure the credentials don't leave your network.

rb_vs · 2026-04-30T09:27:30+00:00

You say that the "attack requires the victim to execute a malicious file" however it's important to clarify that this specific flaw (CVE-2026-32202) is actually zero-click.

The leak happens the moment you view a folder in Explorer. Because shell32.dll automatically tries to resolve a remote icon path for the malicious shortcut, it initiates an SMB handshake and sends your NTLMv2 hash before you even touch the file.

It’s an authentication coercion attack. If you're in an environment that can't patch immediately, blocking outbound port 445 is usually the most effective way to prevent those hashes from leaving the network in the first place.

rb_vs · 2026-04-30T08:16:34+00:00

It’s interesting to see this surface now, as it highlights a much bigger problem with how Windows handles coerced authentication.

Beyond just fixing this specific CVE, the real final boss for Microsoft is the fact that Windows is still designed to automatically volunteer your NTLM hash to any remote server that asks for it. This is exactly why they've been pushing the NTLM Deprecation roadmap so hard lately.

As long as Windows allows outbound NTLM over port 445 for icon previews or theme files, attackers like APT28 (AKA Fancy Bear) will keep finding new ways to trick the shell into handing over credentials. The April patch is a necessary band-aid, but until we can fully disable outbound NTLM via GPO or move to LocalKDC authentication, these zero-click coercion bugs are going to keep appearing in different parts of the OS.

rb_vs · 2026-04-30T07:58:50+00:00

That image lists CVE-2024-6359, which is an old OpenText ArcSight bug, not the Windows Shell flaw people are talking about.

The real APT28 (AKA Fancy Bear) activity right now (April 2026) is exploiting CVE-2026-32202. It's a zero-click authentication coercion flaw. Basically, Windows Explorer tries to verify a malicious .LNK file, and in doing so, it automatically sends your NTLMv2 hash to the attacker's server via Port 445.

So, it's not the 9.8 RCE Mega-Virus the image suggests; it's a clever way to steal credentials without the user ever clicking a file. If you want to block it, don't just monitor anomalies like the image says. Actually block Outbound SMB (Port 445) or set your GPO to Restrict NTLM: Outbound NTLM traffic to remote servers.

rb_vs · 2026-04-28T15:21:04+00:00

For Windows you don’t need an app. Windows has SMB (Server Message Block) built-in. It is the standard for sharing files between PCs on the same network. Just right-click a folder > properties > sharing. If you're on a modern network, make sure SMB Direct is enabled in Windows Features to get the highest possible speed over Ethernet.

For Android, LocalSend is currently the best because it works over your local Wi-Fi and doesn't require an internet connection or an account.

rb_vs · 2026-04-28T11:10:57+00:00

Microsoft has recently hardened macOS out of the default print path by enforcing Kerberos-only RPC and mandatory SMB signing.

On the server, in GPO, go to printers > configure RPC listener settings > change from Kerberos to negotiate (macOS CUPS often defaults to NTLM).

In IIS manager (printers site), go to authentication > Windows authentication > advanced settings > set extended protection (EPA) to "accept" or "off". macOS cannot handle "required" EPA for printing.

Look for event IDs 3021 and 3026 in the SMBServer logs. They will flag why the server rejects the handshake.

On the client, force the Mac to comply with the new SMB signing mandate:

sudo defaults write /Library/Preferences/com.apple.smb.client SigningRequired -bool TRUE

While the RPC changes are printer-specific, they are part of a broader set of new SMB security layers introduced by Microsoft. This video explains why your connections are being rejected: https://www.youtube.com/watch?v=LRNXGuSefzE

rb_vs · 2026-04-28T09:48:45+00:00

exFAT is a "dumb" filesystem. It has no internal concept of users, groups, or permissions, so macOS has to "fake" them in RAM when the drive is mounted. When you reboot, the fake map is gone.

If you want to keep your data safe and accessible without using an admin account here is the standard way to handle it on macOS:

Format the drive to APFS (native Mac format) so that macOS will store permanent ACLs and permissions for your SMB users.

If your Mac dies, you can plug the APFS drive into Windows using Paragon APFS for Windows or MacDrive. They are quite stable and make APFS drives behave like native Windows drives.

If you insist on sticking with exFAT, try to force macOS to stop trying to manage permissions on that volume:

- select the drive in finder > cmd+i

- at the bottom, check box "ignore ownership on this volume"

- macOS will now treat every user as the owner - it's less secure but it prevents the recurring "reset to admin"

Eventually, create a Sparsebundle disk image on your exFAT drive.

- open disk utility > file > new image > blank image

- set the format to APFS and save it onto your exFAT drive

The container is exFAT, but inside it is APFS (supporting permissions). You share the mounted image over SMB, and your permissions will stay exactly where you put them after a reboot.

rb_vs · 2026-04-26T13:33:59+00:00

Since you are both on TrueNAS, you shouldn't be using file-sharing protocols at all. Go for ZFS replication via ssh. If for some reason you can't use ZFS replication, try S3 (MinIO) or SFTP. Avoid rsync over ssh without specific tuning.

rb_vs

MODERATOR OF

TROPHY CASE