I have a domain server mydomain.com and a DFS server which is part of mydomain.com. DFS server has a share with namespace //mydomain.com/Datashare, which points to a TestData folder inside the machine. TestData has a few files 1.txt, 2.txt. When I access my DFS share on a Windows machine it mounts the share and shows the folder TestData with files 1.txt and 2.txt. When I access the same share on my Mac machine it mounts the share and displays the TestData folder. however, it does not show any files inside this folder. Someone discussed a solution of setting the same search domain on a Mac machine as AD sets on Windows but that solution does not work for me.

When I mount a remote SMB volume with macOS's file sharing feature like as: osascript -e 'mount volume "smb://USER@MACOS_SERVER/VOLNAME" but it fails with Error -5014. What I tried were: - rebooting the client - restarting smbd with kill/launchctl on the server - on/off "File Sharing" at "Sharing" of Preferences app. Any ideas?

I'm trying to connect to samba shares on a debian machine in the same network from a Mac running Ventura 13.4.1. It all works perfectly fine if I do CMD+K, and input the credentials there (like smb://user@serverIP) However, trying to connect via double-clicking the share under "Network" on Mac results in the error "The operation can't be completed because the original item can't be found". I installed avahi-deamon after which the server started to be discovered by mac automatically but I can't connect to it double-clicking the auto discovered share. I'm absolutely out of ideas.

I am currently trying to look up the ip address of a mounted smb share for the purpose of accessing it via rclone. Ive tried many solutions, including the ones specified in [This Thread](https://apple.stackexchange.com/questions/10956/finding-the-remote-ip-address-used-by-a-mounted-smb-share) , but these didnt work as the commands couldnt identify the name:

-c 1 nas-smb.local

yielded

: cannot resolve bread._smb._tcp.local: Unknown host

and

lookup bread._smb._tcp.local

to resolve: filename too long

All i have is the local name bread._smb._tcp.local i know from mounting it via Finder - i tried pinging bread.local with the following result:

36 bytes from xyxyxyxy.t-ipconnect.de (unrelated IP): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 9c79   0 0000  3f  01 f817 192.168.1.189  192.168.100.10

I assumed the Destination 192.168.100.10 the IP im searching but trying to connect to that IP directly or mounting to it yielded no result either. How can I look up these IP addresses for .local on macOS?

Before you tell me all the security implications I am well aware and this is for convenience testing. I have a server running smbd on Debian 11 and it is configured correctly such that I can mount and use shares normally. However, I would like to share the server /root such that I can read and write files from my Mac which has the tools I like to use. As root on my Mac using the following command: mount_smbfs -f 666 -d 777 //root:xxxx@10.1.1.1/root /Volumes/root/ I can mount the root folder on the server and see and modify files as root on the Mac. But the volume root is not visible from the Finder with hidden items turned on. The files are accessible from the terminal and emacs but I would like to be able to use for example SQLPro to examine some databases on the server but the volume is not accessible or visible from the Open dialog.

My basic requirement is to use a macOS Monterey machine as a server (without running macOS Server, which is deprecated) to host SMB shares while using Active Directory as my network accounts source (an Ubuntu server running Samba4 AD DC), and have other macOS machine's user's loging in using the Kerberos SSO Extension (in other words, without having to enter credentials for the shares). Seemed simple enough :) For the server, I initially explored the built-in smb setup in Monterey (ie: enabling "File Sharing") with the machine bound (authenticated bind) to the AD DC, but when trying to login via SMB from the client machines (click on the server on the left of a finder window), "Network Users" cannot see shares created by a local admin user (though the Kerberos SSO Extension handled passing the SSO credentials flawlessly). If I logged into the macOS Monterey server machine with an Active Directory account, it created a local home folder and then I could auto-log-in with the Kerberos-SSO extension for that same user as expected from a client machine (but could only see the home folder for that network user as a share - still couldn't see the ones that the local admin account created). Searched for a long time, tried lots of suggestions, but gave up on that option. Figured I'd try installing samba from samba.org so I did a brew install samba on the Monterey server machine. I set it up similar to another SMB file server I have running on Ubuntu (eg: security = ads, configured realm = AD.DOMAIN.COM, etc.) but I seem to be unable to get it to talk to the AD DC server to validate user accounts. I get a lot of "NT_STATUS_NO_LOGON_SERVERS" in the debug log along with "winbindd not running" (which of course, doesn't appear to be available for macOS these days unless I've missed it). So - samba.org's implementation doesn't seem to pick up the methods Apple has used to get the kerberos authentication and domain binding working despite having done that AD authenticated bind on the server machine and seeing proper output from sudo ktutil list (even when configuring the smb.conf to include password server - dc.ad.domain.com), and I don't seem to be able to figure out what those underlying components are without spending significantly more time here. (did notice that homebrew's formula code for samba compiled it by default using --without-ads, which was problem #7 or #8 I stumbled upon - which told me that the formula trimmed samba down to the basics to get it to compile on a mac). I've spent quite a bit of time searching for others who may have documented this same setup (host SMB shares on a mac using AD as the source for network accounts and Kerberos SSO Extension as the macOS client's authentication method (though I'd settle for simply entering a username/password and saving that to the keychain)) to no avail. Searching for macos and samba bring up a lot of stuff all the way back to 2004 (making it harder to sift through, as some of the older items are no longer relevant) **Question:** Rather than troubleshooting my setup, config files, etc. (which might take a while), I'm wondering if anyone can point me to a documented setup like this that they've seen that someone has managed to get working? I've just about exhausted the ways in which I can search for this setup. (I realize this looks like an ask to do my searching for me, but I'm really just looking to see if someone already has this running and can share a few tricks they used to get it going that I may not have run across yet - if my pain sounds familiar). Failing that, perhaps I'll start a new post with lots of detail on my two approaches here (including what I've already tried over the last few weeks) to see if I've missed something. I know - trying to get a mac to host a robust samba file server is probably not the best idea (but I'll cling to that requirement for a while longer before I elect to go with another option). Thank you in advance!

I’m trying to write an Automator Workflow to reconnect macOS to some not-very-remote SMB shares (on a server beside the Mac). For some reason adding them to my login items doesn’t always work. Using an old answer at: https://apple.stackexchange.com/questions/3307/how-can-i-get-automator-to-mount-a-network-volume#answer-3308 I have two actions: - Get Specified Servers, where I list the shares - Connect to Servers The problem is that if the share is already mounted, I get a “Connect to Servers failed” error, and the script exits without trying the next one. Is there a way to test for the server first, or at least to ignore the error?

Why can't the macOS machine open any files in the shared folder that were **transferred from the Linux machine**? The permissions seem to be correct. **The shared folder is located on the macOS machine** / it owns the shared folder. --- I have a shared folder on macOS Catalina (It's just the default Public folder) that can be accessed by an Ubuntu machine. The share is set up using SMB. If the Linux machine copies over a photo, text file, whatever into the shared folder, the macOS machine cannot open it. I get a permissions error. If the macOS machine does the same, the Linux machine has no problems whatsoever. I have tried many settings on macOS to no avail including "Apply to enclosed items". Here's a screenshot of all the sharing settings on macOS so you can see what I have done. The first screenshot shows the error when the admin account on macOS tries to open any file that was transferred from the Linux machine. The account has read/write permissions to the shared folder. Even if I copy a file to the macOS desktop, the error persists. The second screenshot shows Sharing settings in System Preferences. The blacked out parts are just the folder name and the two users who have access to said folder. One user is the macOS admin account, the other user is login credentials for the Linux machine. The third screenshot is details of the shared folder by right clicking > Get Info. - macOS Catalina is the machine sharing the folder - Ubuntu 20.0.4 can see the shared folder and use it without issue - The machines are connected on a local network - The Linux machine has it's own login credentials to the shared folder that were set up on the mac. It is not using a "guest" account.

I have a few NAS/UNRAID servers that I connected to from my macOS (Ventura) client over SMB, but I'm currently swapping over to NFS. From the command line, things are fine and work as expected. However, on my Desktop, the custom icons I had for the shares/volumes are gone (replaced with the default), and I can't seem to put them back using the technique outlined here , for example. I've tried ICNS & PNG files, and these worked just fine with SMB (and still do). Are custom Volume icons not supported for NFS?

Using Finder, I have mounted an SMB share which resides on my NAS . When I use the mount command, the NAS is listed with the name it advertises (nas-smb). mbp:~ me$ mount /dev/disk0s2 on / (hfs, local, journaled) devfs on /dev (devfs, local, nobrowse) map -hosts on /net (autofs, nosuid, automounted, nobrowse) map auto_home on /home (autofs, automounted, nobrowse) //me@nas-smb._smb._tcp.local/myshare on /Volumes/myshare (smbfs, nodev, nosuid, mounted by me) Edit: Is there a way to translate this to the IP address of the NAS or otherwise learn this information? Is there any way to find out the IP address of the NAS which is used to mount this share? The tricky part is that my NAS can be reached on two different IP addresses (direct wired 1Gbps and wireless through my router). On different sessions from the transfer speeds alone I have concluded that either of the IP addresses were in use. So I can't definitely tell to which of the two addresses I am connected for the SMB sharing. The host command didn't works only with the wireless interface. I have also tried lsof -i -n but it shows no SMB related connections. I hoped that smbutil lookup nas-smb could tell me what I want, but it doesn't. When the speeds show that the wired interface is in use, it still returns the address of the wireless interface. Thanks!

I have some Ubuntu Servers running Samba with Winbind. Everything is fine, but Macs will randomly disconnect overnight, or at some irregular interval. On the servers, Samba logs this as two events: 1: ../source3/smbd/service.c:1050(close_cnum) 2: closed connection to service data By matching timestamps on the Macs I can see they log the drops as: kcm DEPRECATED USE in libdispatch client: Setting timer interval to 0 requests a 1ns timer, did you mean FOREVER (a one-shot timer)?; set a breakpoint on _dispatch_bug_deprecated to debug By analyzing timestamps I have determined that this is the only event logged on the Mac clients' side. Here is an example client that has a shell script writing to a text file on a share every ten seconds: You can see the connection was alive at 08:59:46 in the text file on the left, and in /var/log/system.log there's only a single relevant message. I asked on the Samba list serve about it and have been told the Macs are simply closing the connections. ---------- #Update: Wireshark analysis shows some additional information: Errors from above (Line 4): - STATUS_NETWORK_SESSION_EXPIRED - SATATUS_INVALID_PARAMETER - STATUS_NETWORK_NAME_DELETED Here is the final SMB2 message (second from bottom): Negotiate Protocol Response: As if to confound, there's an NT Status: STATUS_SUCCESS messages in there (see annotation). Here is what Microsoft says about the error: > If the Status field in the SMB2 header is > STATUS_NETWORK_SESSION_EXPIRED, the client MUST attempt to > reauthenticate the session that is identified by the SessionId in the > SMB2 header, as specified in section 3.2.4.2.3. If the > reauthentication attempt succeeds, the client MUST retry the request > that failed with STATUS_NETWORK_SESSION_EXPIRED. **If the > reauthentication attempt fails, the client MUST fail the operation and > terminate the session**, as specified in section 3.2.4.23. Is there a script I can run to just renew the session in a cron job? End update ---------- ---------- Other types clients will keep the connections open forever, so it does indeed seem like only Macs are doing this. The OS versions vary from OS X 10.12 to macOS Catalina, using various flavors of SMB2 to SMB3. Any idea how I can begin to understand why the macs are doing this, or any tips on getting them to keep the connections alive? The Mac clients are running jobs that rely on a persistent connection. ---------- **Highly relevant to know, but originally left out as I was looking for a workaround:** I have about a dozen of these servers (mostly Ubuntu 18.04; Samba 4.7.6) running fine for the past several years. Three of them had automatic updates installed, and these three have the issue of the Macs disconnecting. I'm holding back letting the other servers restart for the updates, and the Macs will not drop connections to the non-updated servers. As a test I setup a server to 16.04 to see if and older version of Ubuntu Server would pose the same issue. Surprisingly it has the same problem using a different version of Samba (4.3.11). I will have to do the test again, without letting 16.04 install the latest security updates, in order to confirm my suspicions that those are the cause of the problem. Though I suspect something in Ubuntu's core changed, I am asking here since only Macs are affected. ---------- On a number of Macs with OSes from 10.12 to Catalina I have tried testing them with their default settings, and all possible combinations of changes to /etc/nsmb.conf: [default] signing_required=no protocol_vers_map=[see manpage for nsmb.conf (linked below)] manpage for nsmb.conf I've also tried disabling all sleep and powersaving options, and even using a nice cafffinate wrapper, KeepingYouAwake , to enforce this. On the server I've tried following the advice of another sysadmin on the #macosx freenode channel , kode54, who shared how they eventually got a stable connection . The advice didn't help–well I haven't fully tried it as it requires installing a version of Samba from a PPA for a version of Samba maintained by the Linux for Schools Project –but informed me of vfs_fruit and the fact that there is a developmental effort of extending Samba through an extra package for, in part, dealing with Macs . It also led me to find a page on Samba's wiki discussing difficulties with Macs and server-side workarounds: *Configure Samba to Work Better with Mac OS X * It's difficult for me to try installing suggested Samba PPA because these servers are fileservers in part only, and are generally always being used for compute jobs that can take days to run (neuroimaging processing). They were built for compute jobs, and do storage almost as a side-effect of the dual-socket, high-memory density, server options also happening to be the servers with the large number of drive bays (16+). I'm hoping to try other options before becoming fully negatively disruptive. Since none of the server-side options are helping–I've been trying the flags in various combinations no to avail–I am hoping that the Apple community will have some workaround for me. Any way of keeping a persistent connection, despite where the issue may originate, would be incredibly valuable.

I've got a mac (OS X 10.8.2) that's accessing files on an Win7 SMB share. About half the time the Mac comes back from suspend it can't connect to the SMB share. The Win7 machine is on and the password hasn't changed. But when I try to connect to the SMB server it asks for the username/password. When I type it in, I get told it's wrong. Then I restart the machine (Mac) and it can connect to the SMB server fine. It's an annoyance really, especially when I've got 8 different terminal windows open and they're all named the way I like etc. Anyone got a suggestion/tips for re-connecting to an SMB drive after suspend?

I have an Linux VM running Openmediavault on a separate machine which has a usb3 external drive plugged in. I use this for file shares and time machine backups. It has worked perfectly for years. However, with Monterey 12.5 on my MBP I've noticed some samba issues with copying to the shares and time machine backups are failing. If I try to copy a folder to the smb share, I see: The operation can't be completed because you don't have permission to access some of the items. On my older macbook running Big Sur, the copies complete successfully as well as the time machine backups. On another MBP running Monterey 12.5, I see the same behavior as my main MBP so it seems as this is some Monterey bug. Google said to try to create a file at /etc/nsmb.conf on my Monterey MBP with this config: [default] protocol_vers_map=6 and rebooting. Same issue. I have tried changing the 6 to a 2 and rebooting, but I see the same issue. If I mount the Linux VM (running Openmediavault) and type smbutil statshares -a This is what is displayed: SERVER_NAME 192.168.1.48 USER_ID 501 SMB_NEGOTIATE SMBV_NEG_SMB2_ENABLED SMB_VERSION SMB_2.1 SMB_ENCRYPT_ALGORITHMS AES_128_CCM_ENABLED SMB_ENCRYPT_ALGORITHMS AES_128_GCM_ENABLED SMB_ENCRYPT_ALGORITHMS AES_256_CCM_ENABLED SMB_ENCRYPT_ALGORITHMS AES_256_GCM_ENABLED SMB_CURR_ENCRYPT_ALGORITHM OFF SMB_SHARE_TYPE DISK SIGNING_SUPPORTED TRUE EXTENDED_SECURITY_SUPPORTED TRUE UNIX_SUPPORT TRUE LARGE_FILE_SUPPORTED TRUE OS_X_SERVER TRUE DFS_SUPPORTED TRUE FILE_LEASING_SUPPORTED TRUE MULTI_CREDIT_SUPPORTED TRUE The Openmediavault forum said this was a Monterey issue, and not anything with their software. It does seem as if it is, as my old MBP with Big Sur works perfectly with the smb shares. Have you all seen this behavior with Monterey, and how did you fix it?

I have a problem with Jettison , that tries to remount a samba drive, that is protected by a password. It uses the following command line: /sbin/mount_smbfs //[user]@[server]/work /Volumes/work Of course it fails since the password is not present (nor the -N switch) I am aware that it should contain a password, but I do not want the app to know it. So my question is: Is there a way to request the password like this (I am aware this is not correct): /sbin/mount_smbfs //[user]: %keychain->[identified keychain]%@/work /Volumes/work

I store my iTunes library (now Music.app) on a Samba server. The server's DNS name has changed, but the volume/share name has not. The share is called Media and is mounted at /Volumes/Media However, I am unable to sync my iPhone or play music in Music.app because it somehow still tried to connect to the old DNS name, even though from what I can tell the path names coded in the library don't contain the Samba server name. However when i try to sync my iPhone I get a message > *There was a problem connecting to the server "_old.server.dns.name_" This happens even if I first use *Go > Connect to server...* in the finder and connect to the server, so my music *is* available at the desired path /Volumes/Media/music... I don't want to delete my library and re-import because I'll lose all my star ratings and play counts. How can I resolve this? How can I update the Samba server path for the music in my Music.app library?

I am new to osx but am very experienced with Linux and Windows. I need to mount a subdirectory of a shared drive so the user can access it without being confused by seeing higher levels in the smb path. I've read around and it appears that Lion only mounts the root of a smb share. I hope this is incorrect so am asking for some tips. Ideally I would mount smb://path/to/the/directory and this would appear for the user to access. The stuff above the directory would not appear. Thanks.

Running Big Sur 11.5 and trying to use File Sharing to access my drive on my local network. I only wish to allow the primary user access so I set the permissions accordingly ("everyone" has no access). However, after ~1 day (hard to figure out exactly when), the permissions will revert, allowing anyone read access which is the default setting. This occurs without rebooting, the only operations being connecting to the SMB share and waiting some amount of time. Is there something I'm doing wrong with the configuration? I've looked into alternative network file sharing servers (even just brew install samba) but can't find anything with good documentation besides the native SMB file sharing.

I have a Mac running 10.14 as a file server. I have been copying files to it and today I noticed some very strange caching/buffering behavior. The drive is an external USB 2 HDD, so it tops out at around 40MB/s (and transfers to the share are the same). Today the network speed suddenly went up to around 100 MB/s (maxing out ethernet), then it just stops. Looking at iStat menus on the server, I notice that smbd doesn't actually start writing data to the disk until what I assume is its write buffer getting filled up, then it begins writing the data. This causes the transfer on my end to freeze (obviously) but it also causes the entire share to freeze for my computer, so interacting with it in any way results in a beachball. Not only that, but because this delays the actual write-back to the disk, it takes far longer, as it spends time doing nothing waiting for this buffer to fill up, then blocks the transfer and slowly writes the data it could (should) have been writing all along. Then it cycles again, it stops writing, waits for the buffer to fill, then starts writing again. The buffer is somewhere above 1.6 GB or so, as that was the smallest file I had and it copied all of it before it even started writing to the disk. I have not changed anything, I have been copying data to it for a few days now and I've never seen this behavior before (nor have I *ever* seen this behavior at any point in the past, even with small transfers it would immediately write them to the disk, on this computer or any other, I find it odd that anything would allow that much data to remain unwritten). It doesn't seem to matter if I use Finder or cp on the client, nor does it seem to matter if I use SMB or AFP. Speaking to the unwritten data part, while power outages are not the biggest concern, the fact that my data isn't actually being written to the disk until much later is concerning as well. Edit: Now all of my transfers over about 5GB are failing, with this error: > The operation can’t be completed because an unexpected error occurred (error code 100035). I don't know what to do at this point.

I've tried accessing my macOS 15.3 SMB shares from Windows 10 without success. "Windows sharing" is enabled in macOS. I get a login prompt but it says the credentials are wrong every time. I know they're not. What I tried: - Username with and without workgroup, i.e: WORKGROUP\username and username - Connecting using smb://{ip address, mDNS hostname}, \\netbiosname, netbiosname in Explorer's address field... Every variation I could think of. - Connected to other SMB shares on the network, e.g. \\rpi.local, which worked - Connecting in the other direction (from macOS) which I could not make work either What else is there to try?

I have a smb folder on my Mac mini. That is perfectly reachable from my MacBook Finder app but not from my iPad Pro Files app. I am completely puzzled. I use the same user/password from both devices trying to reach the same location. All three devices are in the same (WLAN) network. Calling for help to debug or a solution.