I am switching our file server from Windows to Linux (Ubuntu Server 12.04) and am using Samba. I was able to successfully set up all the folders needed with the same name that was on Windows. However, there are two folders on the Windows share that is being used by an internal application. We need to point to the that folder, and it's called something like \servername\foldername$ . I create that foldername$ folder on Ubuntu and set it up in smb.conf to be browsable=no as it was not browseable when it was on Windows share. When I try to connect to the new linux folder from a windows machine, I get an error message saying "windows cannot access \servername\foldername$ . I can access all the other folders without the dollar symbol on the end. How do I get around that without needing to make changes to the application that needs to access that folder?

Thanks,
Rick

Dani AI

Generated

A short, practical summary and checklist based on the thread (notes for and thanks to for the pointer):

Windows treats a trailing dollar sign as a hidden share (it simply hides the name from browse lists; an explicit UNC path should still work), and Samba’s browse settings only control whether the share appears in browsing—not whether it can be reached directly. If typing the UNC by hand sometimes works (as observed) but your application fails with "Windows cannot access ...", that usually means an authentication, client policy, automounter, or server-access problem rather than a Samba "browse" bug. (learn.microsoft.com)

Quick, ordered troubleshooting steps to try now:

  • From the server or another Linux host, validate the Samba config and list/connect to the share (this rules out Samba-side syntax or advertise problems). Use testparm and smbclient -L / smbclient //server/SHARE -U user for direct tests. If these succeed, Samba has exported the share correctly. (web.mit.edu)

  • Check filesystem ownership/permissions and any POSIX ACLs on the real directory the share points to (ls -ld /path/to/share and getfacl), and examine Samba logs while you reproduce the failure (/var/log/samba/log.smbd or per-client logs). Increasing Samba loglevel briefly helps capture the failure cause. (uw714doc.xinuos.com)

  • On Ubuntu, confirm AppArmor isn’t blocking smbd’s access to that path (smbd profiles may need the shared path added or to be set to complain mode). (manualzilla.com)

  • If the share relies on anonymous/guest access, modern Windows clients may refuse insecure guest logons by default. Either configure Samba to require proper credentials (preferred) or, with full understanding of the security risk, enable insecure guest auth on the Windows side for that client. (learn.microsoft.com)

Other gotchas and workarounds

  • Some automounters and third‑party clients have bugs or URL-encode the $ (so the mount fails). There are reported autofs/third-party issues with trailing $. If an automounter or tool is involved, test mounting manually and consider exposing a second, non-hidden share name that points to the same filesystem path as a temporary workaround. (bugzilla.redhat.com)

If tests above still show failure, post the failing smbclient output and the relevant smbd log lines (with timestamps). Those two outputs usually make the underlying cause obvious (authentication vs permissions vs client policy vs automounter bug).

I believe you don't have to make it browsable=no, as Windows shares with $-signs at the end are not browsable by windows, but you can still find them with other OS's.

I made a share like //server/folder$ on my Samba installation, which I was unable to see from windows, but I could access it by typing //server/folder$ in windows explorer...

Just make sure the correct owner, group and folder rights are used.

Martin

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.