I'm syncing some local folders so they appear as albums "From my Mac" in my iPhone Photos app. It works, but the ordering is wrong. The files in the local folders are actually symlinks into nested folders on a backup drive (actually a Photos.app library) so the paths are mapped like this example: ~/Pictures/example/A75BB473-E7A7-4B52-A184-6BB6D60AFA41.jpeg -> /Volumes/drive/example.photoslibrary/originals/A/A75BB473-E7A7-4B52-A184-6BB6D60AFA41.jpeg Note that I am syncing **folders** not albums, and this is for good reason. Syncing albums is [broken](https://apple.stackexchange.com/questions/372176/why-wont-photos-import-from-iphone-after-upgrade) for photo libraries on network drives. The photos import no problem, but the order is weird. I can't align it with any ordering I can replicate in the finder. They are *roughly* time ordered based on the EXIF "Date Time Original" tag, but not quite. On the iPhone clicking a photo shows the correct date from the EXIF data, but this is seemingly not being used for ordering. Neither is the file name. The created, modified and access timestamps on the original photos are all the same, so this doesn't seem the principle ordering value either. How does the iPhone sync process determine the order these appear in the album? What can I do to ensure correct time ordering?

I have a little NAS at home which makes some volumes available through AFP. This all worked great. Until I shut it down for a while and reconnected it recently. I can see the device on the network and I can open it and select a share. But when I try to mount the share, I get the following error: "The operation can’t be completed because the original item for “Foo” can’t be found" I think this is because my little NAS changed to a new IP and OS X somehow cached the original (alias?) somewhere. The fact that I can successfully open these shares from another Mac, which had never seen these before, confirms that I think. Does anyone know where this is potentially cached? Is there anything I can reset or throw away to get past this error?

I know this is similar to other open questions about mounting network drives, but this one is slightly different. I have an AppleScript that runs at startup that looks like this: tell Application "Finder" mount volume "afp://192.168.1.105/file_server/user_name end tell Where user_name is specific to the sub folder under file_server. On one of my Macs, this works and mounts the sub-folder at user-name. On a different mac, it only mounts the file_server folder. The one that doesn't mount the full path is OSX 10.9.5. The one that works properly is OSX 10.10.1. Makes me think it's an OSX version difference.

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.

Finder does not recognize all sharepoints available, opens only 1 that was previously mouned by default; runing macOS Catalina 10.15.5 acting as client connecting to AFP File Server running Mac OS Server Sierra 10.12.6) On my server (Mac OS Server Sierra 10.12.6) my sharepoints look like this: I should have 4 available sharepoints (shared folders) to my user **jfb** on the system: FAMILY-ARCHIVE, jfb, PHOTOS-ARCHIVE, and VAULT (the other two you see in the picture are not accessible by my user **jfb**) However, when connecting to this server from a machine running macOS Catalina 10.15.5 (*intermitant), my client machine ***bypasses the sharepoint selection*** screen and goes directly to mount a single sharepoint that I previously have mounted This happens even though I DO NOT have the username/password stored in teh keychain-- I just connected to this sharepoint earlier in this finder session with it. If I disconnect the sharepoint (using the "Eject" next to the sharepoint in any finder window) and reconnect, the same thing happens. *Please note that this worked several times before and I have seen this symptom be intermittant.

I am having a problem copying certain directories and files from my Mac to my family file server via AFP. When I attempt to copy them by dragging them from a Finder window on my Mac to the corresponding Finder window on the file server, Finder displays a window saying, 'Copying 2 items to "other_folder"'. Then the copy hangs. - If I click the (X) icon to the right of the progress bar, the window adds a message, "Stopping…", but hangs forever. - If I attempt to eject the server volume from Finder, Finder refuses, saying, "The volume can't be ejected because it is currently in use." - The command ps up 670, where 670 is the process ID of the /System/Library/CoreServices/Finder.app/Contents/MacOS/Finder process, says that the state of the Finder process is U. This "marks a process in uninterruptible wait", according to man ps. - I have narrowed down the problem to the point where I can trigger it by trying to copy only one directory containing only one file. Both directory and file seem innocuous: not very large, created in a very ordinary way. Sometimes I can recover from this by relaunching the Finder process, and after a couple of minutes the Finder relaunches in a new process, without the server mounted. Sometimes the Finder does not relaunch, and I have to log out and back in again, or even restart macOS. If I connect to the family file server via SMB rather than AFP, Finder copies the very same files with no problem. But I prefer to connect via AFP, because I make heavy use of relative symbolic links between my project directories. Neither Apple's SMB software nor the server's SMB software present symbolic links as links. Instead, they present links as conventional directories. That messes up my workflow. I have used this file server for years, and this Mac and its predecessor with this server via AFP for years. I have not encountered this problem before. I have copied similar files from Mac to server before without problems. Connecting to this server via AFP works well in general, even though both Apple and the server vendor have deprecated AFP. Hypotheses: - There is something about these files which triggers a bug in the Mac's AFP code. - Something in a recent macOS upgrade broke this aspect of AFP support. - Something about the path length or other context is the actual trigger, not the files themselves. - It is not the visible file, but an invisible system file like .DS_Store, which triggers the problem. The Mac is running macOS Sonoma 14.7.4, and has an Apple M1 CPU. The server is running TrueNAS-13.0-U6.2 software, with AFP support via NetATalk. How can I fix this so that these file copy operations succeed when copying via Finder over AFP? How can I recover from the hung Finder file copy in a less invasive way than restarting macOS? Can I interrupt a process in state U? How can I diagnose what is triggering the problem, so that I know to avoid it?

When I use the command line rather than the finder to mount a network volume, and I want the mount point to be in /Volumes, do I need to create the mount point myself first? If so, how should I do that so i still can unmount from the UI without problems? The finder seems to ignore the actual share, so the mount point it creates is /Volumes/HOST._afpovertcp._tcp.local without a reference to the share.

I have seen forum posts out in the wild that suggest that AFP is "dead". I have seen this question and this post that states SMB is now the "default" protocol for Apple sharing. I am using FreeNAS and it allows you to select either AFP or SMB shares. I mostly use Mac clients, so it would seem that AFP would be the obvious choice, but if AFP is going away in future versions of macOS, then I don't want to be stuck with shares I cannot access and/or file systems I have to migrate from AFP to some other system. So what is fact and what is fiction about the future of AFP? Will it stop working in future versions of macOS? I don't see how this is possible since Time Machine requires it. Can I safely use AFP without worrying about it "dying" on me?

I just got a new NAS (Synology DS923+), and my Mac was able to see it and write data to it right away. The Mac is running Ventura 13.0. I do most of my work from the command line in a Terminal window. I have two problems when copying files to the NAS: 1. file modification times are not preserved 2. file permissions all show as rwxrwxrwx (mode 666). These problems show up both when copying files using cp -p, and extracting tarballs with tar x. (Oddly, some ways of propagating modtimes to files on the NAS, such as touch -r, *do* work.) I believe problem #1 is probably related to https://discussions.apple.com/thread/6681949 , although if (as suggested in that thread) it has something to do with a bug in MacOS, I'm surprised it still hasn't been fixed. I believe problem #2 is a limitation of SMB. So my main question is, is there a better way of mounting a fileshare from MacOS than SMB? I believe I've got all protocols enabled on the NAS, although it has a note saying that MacOS does not support AFP after Mojave. I'm not even sure I'm using SMB. Finder lists the shared folder as type "Sharepoint". And the actual low-level mount (as reported by df) is //user@host._afpovertcp._tcp.local/folder, which kind of suggests AFP might be involved after all. [Addendum: It turns out I *was* using AFP. See the [answer I just posted](https://apple.stackexchange.com/questions/463191/difficulties-with-file-metadata-mode-modtime-on-nas-under-smb/463380#463380).] If there's a better or at least a different way, how do I request it? For example, I'm pretty sure MacOS can do NFS, and obviously the NAS can, too. (I know NFS has some disadvantages, but if it'd get me modes and mtimes, I'd probably be willing to put up with lesser inconveniences.)

Back in 2020, when I updated my 2017 iMac to Catalina, I found that the Samba shares on an old Linux box (the same one that was our original automated backup controller) wouldn't mount because Catalina had removed support for that version of Samba. https://apple.stackexchange.com/q/386924/331833 Now that I've got the backup controller running on an old Mini , I've revisited the situation. I'm using the Catalina iMac, rather than my new Ventura Mini, as a Guinea pig for this, and I find that after adjusting the Applescript that automatically runs at sign-on to point to the correct IP address (and adding a third SMB/AFP share to the script, it always asks me for user-ID and password, and which directory to connect to, in spite of the fact that all that is explicitly specified in the script. The script entries are of the form: try open location "smb://uuuuuuuu:pppppppp@xxx.xxx.xxx.xxx/dddddddd" end try where uuuuuuuu is my user-ID, and pppppppp is my password, on the box hosting the SMB share, at local IP address xxx.xxx.xxx.xxx, and name dddddddd. Does anybody know what's wrong now? Or if there's an easier way to automatically connect to specific SMB/AFP shares on login?

I am trying to sync a local directory to my NAS that is mounted via the afp protocol as a drive. I am using rsync. When I run the command from the terminal, it works fine. However, when I try to run it from launchd, it always fails. This is my rsync command:

rsync -av --delete /Users/self/Pictures/ /Volumes/nas/Images

This is the plist file that contains the above command. It is located in ~/Library/LaunchAgents with user, groups, and permissions equal to the other (working) plists in that directory.

Label
	rsync_picture_to_nas

	ProgramArguments
	
		rsync
		-av
		--delete
		/Users/self/Pictures/
		/Volumes/nas/Images
	

	StandardErrorPath
	/Users/self/.log/rsync_picture_to_nas_err.log

	StandardOutPath
	/Users/self/.log/rsync_picture_to_nas_out.log

	WatchPaths
	
		/Users/self/Pictures

It always has complete permissions failure. The exact permissions errors will depend on whether I am running it from scratch or have previously run it successfully from the command line. Suffice to say, it is totally incapable of doing anything. It can't create or modify any files on the NAS at all. Here is a sample error:

rsync: recv_generator: mkdir "/Volumes/nas/Images/Lightroom Library.lrlibrary" failed: Operation not permitted (1)
*** Skipping everything below this failed directory ***

I need a little bit of help to troubleshoot our company network. We have 10+ Macs (different versions) and they are connected to a Mac Server providing a SMB/AFP network share. A few weeks ago, we enhanced our network and split some things up into different VLANs. The network of the Mac Server is now placed in a VLAN, keeping the same subnet. The VLAN is totally managed by switches/access points/firewall. Macs can connect to the server using an internal domain name like server.local domain, which points to the IP of the Mac Server. But, from time to time, users complain they cannot see the content of some folders and they need to reconnect or wait a few minutes until they can work again. Sometimes users also report that they don't see a file that other user put on the server a few minutes ago. It needs a network reconnect for the SMB/AFP to work again. These problems didn't happen before we split the network up in several VLANs - but the change shouldn't affect the connection between Macs and Server because they are in the same VLAN and subnet. The same problem occurs via SMB and AFP (so I think it isn't a problem directly with the network share ... but cannot tell it 100% for sure). I wasn't able to reproduce the issue. Everytime I tested it, it worked fine (via Wi-Fi or cable). **I got one chance to make some tests when a user that was experiencing the problem told me directly. I made some pings to the Mac server and it turned out that, when this happens, the ping to the server takes around 20 to 200 ms and sometimes packets are lost.** I don't know what the culprit is, because everytime I test it on different Macs or Windows/Linux computers everything works fine. Does someone have an idea where I can look for further troubleshooting or has someone had a similar problem and solved it? I would be very thankful for some hints that help solve this problem. Thank you for your help and best regards, Katharina

I'm having a problem getting file sharing to work between my MBPr and Mac Mini, here's a history of what I've tried: I have a MacBook Pro (Retina, 15-inch, Late 2013) running El Cap 10.11.1 (15B42) and recently acquired a Mac mini Server (Mid 2011) from my Aunty that was running an ancient version of OSX (and Server) that I upgraded to El Cap 10.11.1 (15B42). (probably irrelevant: The server came with an administrator account for my Aunty in her name that I haven't gotten rid of) After upgrading I created a new account for myself (Derwent) from the administrator account with (Admin access, local authentication) and signed in with my Apple ID, then enabled SMB and AFP File Sharing for all accounts, ensuring my account, Derwent had access to a folder called Movies. I could access this share remotely using SMB and AFP with the guest account, and with the administrator account, using terminal and Finder but no matter what I did, I couldn't access it using Derwent. I could also access my MBPr from my mini using Guest, Administrator and local authentication just fine. I created a new standard account test with the password test, so that I was sure that I was getting the password correct, (this account was not signed in to any apple ID) and still it wouldn't work. Here are some dumps of my console with different access methods. **Browsing to the share in Finder directly, and using "Connect as"** Get error message: Access to your account on the server “minimac” has been denied. Console dump on server end: Dec 1 00:24:53 minimac kdc: Got a canonicalize request for a LKDC realm from local-ipc Dec 1 00:24:53 minimac kdc: LKDC referral to the real LKDC realm name Dec 1 00:24:53 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:24:53 --- last message repeated 1 time --- Dec 1 00:24:53 minimac kdc: Client sent patypes: REQ-ENC-PA-REP Dec 1 00:24:53 minimac kdc: SRP announcing message of size 52 Dec 1 00:24:53 minimac kdc: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ Dec 1 00:24:53 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:24:53 --- last message repeated 1 time --- Dec 1 00:24:53 minimac kdc: Client sent patypes: SRP, REQ-ENC-PA-REP, FX-COOKIE Dec 1 00:24:53 minimac kdc: SRP step 1 Dec 1 00:24:53 minimac kdc: ccsrp server start for user: test Dec 1 00:24:53 minimac kdc: FAST factor needs more preauth data, feed it Dec 1 00:24:53 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:24:53 --- last message repeated 1 time --- Dec 1 00:24:53 minimac kdc: Client sent patypes: SRP, REQ-ENC-PA-REP, FX-COOKIE Dec 1 00:24:53 minimac kdc: SRP step 2 Dec 1 00:24:53 minimac kdc: SRP pre-authentication succeeded -- test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:24:53 minimac kdc: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96 Dec 1 00:24:53 minimac kdc: Requested flags: canonicalize Dec 1 00:24:53 minimac kdc: Client uses FAST Dec 1 00:24:53 minimac kdc: FAST strengthen reply key with strengthen-key Dec 1 00:24:53 minimac kdc: TGS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for cifs/localhost@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D [canonicalize] Dec 1 00:24:53 minimac kdc: FAST armor protection Dec 1 00:24:53 minimac smbd: check_account - :[permission denied] pam_acct_mgmt Dec 1 00:24:53 minimac digest-service: label: default Dec 1 00:24:53 minimac digest-service: dbname: od:/Local/Default Dec 1 00:24:53 minimac digest-service: mkey_file: /var/db/krb5kdc/m-key Dec 1 00:24:53 minimac digest-service: acl_file: /var/db/krb5kdc/kadmind.acl Dec 1 00:24:53 minimac digest-service: digest-request: uid=0 Dec 1 00:24:53 minimac digest-service: digest-request: netr probe 0 Dec 1 00:24:53 minimac digest-service: digest-request: init request Dec 1 00:24:53 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:24:53 minimac digest-service: digest-request: uid=0 Dec 1 00:24:53 minimac digest-service: digest-request: init request Dec 1 00:24:53 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:24:53 minimac digest-service: digest-request: uid=0 Dec 1 00:24:53 minimac digest-service: digest-request: od failed with -1561745588 proto=ntlmv2 Dec 1 00:24:53 minimac digest-service: digest-request: user=MINIMAC\test Dec 1 00:24:53 minimac digest-service: digest-request kdc: ok user=MINIMAC\test proto=ntlmv2 flags: ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM, NEG_TARGET, NEG_UNICODE Dec 1 00:24:53 minimac smbd: check_account - :[permission denied] pam_acct_mgmt Dec 1 00:24:53 minimac digest-service: digest-request: uid=0 Dec 1 00:24:53 minimac digest-service: digest-request: init request Dec 1 00:24:53 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:24:53 minimac digest-service: digest-request: uid=0 Dec 1 00:24:53 minimac digest-service: digest-request: init request Dec 1 00:24:53 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:24:53 minimac digest-service: digest-request: uid=0 Dec 1 00:24:53 minimac digest-service: digest-request: od failed with -1561745588 proto=ntlmv2 Dec 1 00:24:53 minimac digest-service: digest-request: user=MINIMAC\test Dec 1 00:24:53 minimac digest-service: digest-request kdc: ok user=MINIMAC\test proto=ntlmv2 flags: ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM, NEG_TARGET, NEG_UNICODE Dec 1 00:24:53 minimac smbd: check_account - :[permission denied] pam_acct_mgmt **using Finder, afp://test:test@minimac.local/Movies** Dec 1 00:12:15 minimac kdc: Got a canonicalize request for a LKDC realm from local-ipc Dec 1 00:12:15 minimac kdc: LKDC referral to the real LKDC realm name Dec 1 00:12:15 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:12:15 --- last message repeated 1 time --- Dec 1 00:12:15 minimac kdc: Client sent patypes: REQ-ENC-PA-REP Dec 1 00:12:15 minimac kdc: SRP announcing message of size 52 Dec 1 00:12:15 minimac kdc: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ Dec 1 00:12:15 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:12:15 --- last message repeated 1 time --- Dec 1 00:12:15 minimac kdc: Client sent patypes: SRP, REQ-ENC-PA-REP, FX-COOKIE Dec 1 00:12:15 minimac kdc: SRP step 1 Dec 1 00:12:15 minimac kdc: ccsrp server start for user: test Dec 1 00:12:15 minimac kdc: FAST factor needs more preauth data, feed it Dec 1 00:12:15 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:12:15 --- last message repeated 1 time --- Dec 1 00:12:15 minimac kdc: Client sent patypes: SRP, REQ-ENC-PA-REP, FX-COOKIE Dec 1 00:12:15 minimac kdc: SRP step 2 Dec 1 00:12:15 minimac kdc: SRP pre-authentication succeeded -- test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:12:15 minimac kdc: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96 Dec 1 00:12:15 minimac kdc: Requested flags: canonicalize Dec 1 00:12:15 minimac kdc: Client uses FAST Dec 1 00:12:15 minimac kdc: FAST strengthen reply key with strengthen-key Dec 1 00:12:15 minimac kdc: TGS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for afpserver/localhost@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D [canonicalize] Dec 1 00:12:15 minimac kdc: FAST armor protection Dec 1 00:12:19 minimac WindowServer: send_datagram_available_ping: pid 534 failed to act on a ping it dequeued before timing out. **Using Finder, smb://test:test@minimac.local/Movies** Dec 1 00:18:05 minimac digest-service: label: default Dec 1 00:18:05 minimac digest-service: dbname: od:/Local/Default Dec 1 00:18:05 minimac digest-service: mkey_file: /var/db/krb5kdc/m-key Dec 1 00:18:05 minimac digest-service: acl_file: /var/db/krb5kdc/kadmind.acl Dec 1 00:18:05 minimac digest-service: digest-request: uid=0 Dec 1 00:18:05 minimac digest-service: digest-request: netr probe 0 Dec 1 00:18:05 minimac digest-service: digest-request: init request Dec 1 00:18:05 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:18:05 minimac digest-service: digest-request: uid=0 Dec 1 00:18:05 minimac digest-service: digest-request: init request Dec 1 00:18:05 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:18:05 minimac kdc: Got a canonicalize request for a LKDC realm from local-ipc Dec 1 00:18:05 minimac kdc: LKDC referral to the real LKDC realm name Dec 1 00:18:05 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:18:05 --- last message repeated 1 time --- Dec 1 00:18:05 minimac kdc: Client sent patypes: REQ-ENC-PA-REP Dec 1 00:18:05 minimac kdc: SRP announcing message of size 52 Dec 1 00:18:05 minimac kdc: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ Dec 1 00:18:05 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:18:05 --- last message repeated 1 time --- Dec 1 00:18:05 minimac kdc: Client sent patypes: SRP, REQ-ENC-PA-REP, FX-COOKIE Dec 1 00:18:05 minimac kdc: SRP step 1 Dec 1 00:18:05 minimac kdc: ccsrp server start for user: test Dec 1 00:18:05 minimac kdc: FAST factor needs more preauth data, feed it Dec 1 00:18:05 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:18:05 --- last message repeated 1 time --- Dec 1 00:18:05 minimac kdc: Client sent patypes: SRP, REQ-ENC-PA-REP, FX-COOKIE Dec 1 00:18:05 minimac kdc: SRP step 2 Dec 1 00:18:05 minimac kdc: SRP pre-authentication succeeded -- test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:18:05 minimac kdc: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96 Dec 1 00:18:05 minimac kdc: Requested flags: canonicalize Dec 1 00:18:05 minimac kdc: Client uses FAST Dec 1 00:18:05 minimac kdc: FAST strengthen reply key with strengthen-key Dec 1 00:18:05 minimac kdc: TGS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for cifs/localhost@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D [canonicalize] Dec 1 00:18:05 minimac kdc: FAST armor protection Dec 1 00:18:05 minimac smbd: check_account - :[permission denied] pam_acct_mgmt Dec 1 00:18:05 minimac digest-service: digest-request: uid=0 Dec 1 00:18:05 minimac digest-service: digest-request: init request Dec 1 00:18:05 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:18:05 minimac digest-service: digest-request: uid=0 Dec 1 00:18:05 minimac digest-service: digest-request: init request Dec 1 00:18:05 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:18:05 minimac digest-service: digest-request: uid=0 Dec 1 00:18:05 minimac digest-service: digest-request: od failed with -1561745588 proto=ntlmv2 Dec 1 00:18:05 minimac digest-service: digest-request: user=MINIMAC\test Dec 1 00:18:05 minimac digest-service: digest-request kdc: ok user=MINIMAC\test proto=ntlmv2 flags: ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM, NEG_TARGET, NEG_UNICODE Dec 1 00:18:05 minimac smbd: check_account - :[permission denied] pam_acct_mgmt Dec 1 00:18:05 minimac digest-service: digest-request: uid=0 Dec 1 00:18:05 minimac digest-service: digest-request: init request Dec 1 00:18:05 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:18:05 minimac digest-service: digest-request: uid=0 Dec 1 00:18:05 minimac digest-service: digest-request: init request Dec 1 00:18:05 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:18:05 minimac digest-service: digest-request: uid=0 Dec 1 00:18:05 minimac digest-service: digest-request: od failed with -1561745588 proto=ntlmv2 Dec 1 00:18:05 minimac digest-service: digest-request: user=MINIMAC\test Dec 1 00:18:05 minimac digest-service: digest-request kdc: ok user=MINIMAC\test proto=ntlmv2 flags: ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM, NEG_TARGET, NEG_UNICODE Dec 1 00:18:05 minimac smbd: check_account - :[permission denied] pam_acct_mgmt Dec 1 00:18:08 minimac WindowServer: send_datagram_available_ping: pid 534 failed to act on a ping it dequeued before timing out. **Using Finder, cifs://test:test@minimac.local/Movies** Dec 1 00:31:20 minimac kdc: Got a canonicalize request for a LKDC realm from local-ipc Dec 1 00:31:20 minimac kdc: LKDC referral to the real LKDC realm name Dec 1 00:31:20 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:31:20 --- last message repeated 1 time --- Dec 1 00:31:20 minimac kdc: Client sent patypes: REQ-ENC-PA-REP Dec 1 00:31:20 minimac kdc: SRP announcing message of size 52 Dec 1 00:31:20 minimac kdc: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ Dec 1 00:31:20 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:31:20 --- last message repeated 1 time --- Dec 1 00:31:20 minimac kdc: Client sent patypes: SRP, REQ-ENC-PA-REP, FX-COOKIE Dec 1 00:31:20 minimac kdc: SRP step 1 Dec 1 00:31:20 minimac kdc: ccsrp server start for user: test Dec 1 00:31:21 minimac kdc: FAST factor needs more preauth data, feed it Dec 1 00:31:21 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:31:21 --- last message repeated 1 time --- Dec 1 00:31:21 minimac kdc: Client sent patypes: SRP, REQ-ENC-PA-REP, FX-COOKIE Dec 1 00:31:21 minimac kdc: SRP step 2 Dec 1 00:31:21 minimac kdc: SRP pre-authentication succeeded -- test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:31:21 minimac kdc: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96 Dec 1 00:31:21 minimac kdc: Requested flags: canonicalize Dec 1 00:31:21 minimac kdc: Client uses FAST Dec 1 00:31:21 minimac kdc: FAST strengthen reply key with strengthen-key Dec 1 00:31:21 minimac kdc: TGS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for cifs/localhost@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D [canonicalize] Dec 1 00:31:21 minimac kdc: FAST armor protection Dec 1 00:31:21 minimac smbd: check_account - :[permission denied] pam_acct_mgmt Dec 1 00:31:21 minimac digest-service: label: default Dec 1 00:31:21 minimac digest-service: dbname: od:/Local/Default Dec 1 00:31:21 minimac digest-service: mkey_file: /var/db/krb5kdc/m-key Dec 1 00:31:21 minimac digest-service: acl_file: /var/db/krb5kdc/kadmind.acl Dec 1 00:31:21 minimac digest-service: digest-request: uid=0 Dec 1 00:31:21 minimac digest-service: digest-request: netr probe 0 Dec 1 00:31:21 minimac digest-service: digest-request: init request Dec 1 00:31:21 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:31:21 minimac digest-service: digest-request: uid=0 Dec 1 00:31:21 minimac digest-service: digest-request: init request Dec 1 00:31:21 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:31:21 minimac digest-service: digest-request: uid=0 Dec 1 00:31:21 minimac digest-service: digest-request: od failed with -1561745588 proto=ntlmv2 Dec 1 00:31:21 minimac digest-service: digest-request: user=MINIMAC\test Dec 1 00:31:21 minimac digest-service: digest-request kdc: ok user=MINIMAC\test proto=ntlmv2 flags: ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM, NEG_TARGET, NEG_UNICODE Dec 1 00:31:21 minimac smbd: check_account - :[permission denied] pam_acct_mgmt Dec 1 00:31:21 minimac digest-service: digest-request: uid=0 Dec 1 00:31:21 minimac digest-service: digest-request: init request Dec 1 00:31:21 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:31:21 minimac digest-service: digest-request: uid=0 Dec 1 00:31:21 minimac digest-service: digest-request: init request Dec 1 00:31:21 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:31:21 minimac digest-service: digest-request: uid=0 Dec 1 00:31:21 minimac digest-service: digest-request: od failed with -1561745588 proto=ntlmv2 Dec 1 00:31:21 minimac digest-service: digest-request: user=MINIMAC\test Dec 1 00:31:21 minimac digest-service: digest-request kdc: ok user=MINIMAC\test proto=ntlmv2 flags: ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM, NEG_TARGET, NEG_UNICODE Dec 1 00:31:21 minimac smbd: check_account - :[permission denied] pam_acct_mgmt Dec 1 00:31:49 minimac kdc: Got a canonicalize request for a LKDC realm from local-ipc Dec 1 00:31:49 minimac kdc: LKDC referral to the real LKDC realm name Dec 1 00:31:49 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:31:49 --- last message repeated 1 time --- Dec 1 00:31:49 minimac kdc: Client sent patypes: REQ-ENC-PA-REP Dec 1 00:31:49 minimac kdc: SRP announcing message of size 52 Dec 1 00:31:49 minimac kdc: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ Dec 1 00:31:49 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:31:49 --- last message repeated 1 time --- Dec 1 00:31:49 minimac kdc: Client sent patypes: SRP, REQ-ENC-PA-REP, FX-COOKIE Dec 1 00:31:49 minimac kdc: SRP step 1 Dec 1 00:31:49 minimac kdc: ccsrp server start for user: test Dec 1 00:31:49 minimac kdc: FAST factor needs more preauth data, feed it Dec 1 00:31:49 minimac kdc: AS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for krbtgt/LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:31:49 --- last message repeated 1 time --- Dec 1 00:31:49 minimac kdc: Client sent patypes: SRP, REQ-ENC-PA-REP, FX-COOKIE Dec 1 00:31:49 minimac kdc: SRP step 2 Dec 1 00:31:49 minimac kdc: SRP pre-authentication succeeded -- test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D Dec 1 00:31:49 minimac kdc: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96 Dec 1 00:31:49 minimac kdc: Requested flags: canonicalize Dec 1 00:31:49 minimac kdc: Client uses FAST Dec 1 00:31:49 minimac kdc: FAST strengthen reply key with strengthen-key Dec 1 00:31:49 minimac kdc: TGS-REQ test@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D from local-ipc for cifs/localhost@LKDC:SHA1.861AE3F013165CCB522112A9BD16DAE8ED59CC1D [canonicalize] Dec 1 00:31:49 minimac kdc: FAST armor protection Dec 1 00:31:49 minimac smbd: check_account - :[permission denied] pam_acct_mgmt Dec 1 00:31:49 minimac digest-service: digest-request: uid=0 Dec 1 00:31:49 minimac digest-service: digest-request: init request Dec 1 00:31:49 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:31:49 minimac digest-service: digest-request: uid=0 Dec 1 00:31:49 minimac digest-service: digest-request: init request Dec 1 00:31:49 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:31:49 minimac digest-service: digest-request: uid=0 Dec 1 00:31:49 minimac digest-service: digest-request: od failed with -1561745588 proto=ntlmv2 Dec 1 00:31:49 minimac digest-service: digest-request: user=MINIMAC\test Dec 1 00:31:49 minimac digest-service: digest-request kdc: ok user=MINIMAC\test proto=ntlmv2 flags: ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM, NEG_TARGET, NEG_UNICODE Dec 1 00:31:49 minimac smbd: check_account - :[permission denied] pam_acct_mgmt Dec 1 00:31:49 minimac digest-service: digest-request: uid=0 Dec 1 00:31:49 minimac digest-service: digest-request: init request Dec 1 00:31:49 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:31:49 minimac digest-service: digest-request: uid=0 Dec 1 00:31:49 minimac digest-service: digest-request: init request Dec 1 00:31:49 minimac digest-service: digest-request: init return domain: MINIMAC server: MINIMAC indomain was: Dec 1 00:31:49 minimac digest-service: digest-request: uid=0 Dec 1 00:31:49 minimac digest-service: digest-request: od failed with -1561745588 proto=ntlmv2 Dec 1 00:31:49 minimac digest-service: digest-request: user=MINIMAC\test Dec 1 00:31:49 minimac digest-service: digest-request kdc: ok user=MINIMAC\test proto=ntlmv2 flags: ENC_128, NEG_VERSION, NEG_TARGET_INFO, NEG_NTLM, NEG_TARGET, NEG_UNICODE Dec 1 00:31:50 minimac smbd: check_account - :[permission denied] pam_acct_mgmt I don't really understand these messages but hopefully someone with more experience will. **Edit for clarification:** account name , privileges, appleID , machine ====================================================== derwent , Admin , derwent , minimac administrator, Admin , - , minimac test , Standard , - , minimac jacq(deleted), Admin , jacq , minimac derwent , Admin , derwent , ich machine, share , user , access ====================================== minimac, Movies, derwent , read & write minimac, Movies, test , read only minimac, Movies, Everyone, read only

I have a share on a netatalk server that exporting "Don's home" - I want to add to fstab so that it's handled by autofs as an indirect mount. I've tried using %60 and %20, quoting, escaping with backslash, \40, \040, etc. Anyone know the syntax? When there are no special characters this works fine: server:/share dummy url net,automounted,url==afp://user:pass@server/share 0 0

Apple Time Capsule related technical question. In short, - does there exist a way to **disable** at the Time Capsule the **SMB signing** **feature**? Regarding the original SMB1 protocol, the signing mechanism is slowing down the overall performance extremely. For example, writing to the Time Capsule network share is over a Gigabit LAN connection at around 15 MB/s and goes down to around 2 - 3 MB/s when a lot of smaller files are transferred. This behavior is **SMB1 related** and is therefore present on different operating systems and (older) NAS network devices. Newer SMB2+ versions have a different, more efficient, design which results in much reduced overhead in conjunction with the signing feature. I can confirm this for several older Windows 7 computers where their (SMB2 based) network shares can handle transfer speeds up to 100 MB/s. The usual solution is to disable the SMB signing. This can be done on macOS (and other OS) quite easy: https://dpron.com/os-x-10-11-5-slow-smb/ In my case, however, it is somewhat more complex. Regarding the Time Capsule -- I had to do this at the "server side" which is effectively the Time Capsule. I have experimented to deactivate the signing at the client side (Mac OS, Windows 7) but it shows no effect. The SMB1 network share speed is always very slow because the SMB1 signing remains active. So, my idea is to find a BSD command which deactivates the signing at the Time Capsule. The earlier Time Capsule models (up to the fourth generation) are NetBSD 4.0 based. The last model, the fifth generation, is based on NetBSD 6. There exists a non-official way to access the Time Capsule through SSH. ;-) And finally, a switch to the Apple AFP protocol is not a real solution because the Time Capsule share is also used under Linux and Windows. AFP is therefore only a solution for macOS based systems. However, Apple itself regards AFP as deprecated. It is no longer supported with the new APFS file system. Apple uses for APFS based network shares newer SMB versions.

My Mac runs a daily script (via cron) that mounts an AFP network share on a remote server, writes to it, and unmounts the share. Unfortunately, the script has a side-effect of opening a Finder window to view the network share, which pops up in the middle of the user's day, interrupting their work. Is there a way to mount the network share without opening the Finder window? I mount the network share using the open command (/usr/bin/open):

open afp://username:pw@server.com/MyVolumeName

I've already tried the -g option (*Do not bring the application to the foreground*) and the -j option (*Launches the app hidden*) for open, but the Finder window still appears. Thanks.

I have a publishing company as a client that has asked me to help them migrate an outdated Mac server to a cloud based model so they would be able to have a more resilient system, as well as easily accommodate some tasks that are currently not able to be done outside of the office. After looking into different systems to help accommodate this the main hurdle I seem to be running into is the user authentication pieces as this is a security step that we are feeling is necessary since ultimately they will have their entire staff on this system and as they leave they would like some control over access. My question is, since this is something I feel like a lot of organizations did a few years ago, what was the prefered path? Did you end up moving to a windows server, or just running a mac server in AWS, or did you use a different file system to accommodate the future growth you were projecting for the organization? I did see this post on here, and it almost answers the questions, but we are wanting a solution that can lock files while they are being viewed if possible. The team is currently about 15 people, and we are wanting to find the most cost effective solution while still utilizing something similar to the process they have now where they use the "Connect to Server" feature on the mac to mount the shared drive onto their desktop. I have found a few similar solutions, but ones like this feel a little outdated, and then you have a system that AWS manages that is a bit expensive for the amount of people utilizing it. Is there even a happy median between old software and expensive enterprise level for something like this? Thank you for all of your suggestions in advance!

Is there a way to mount an AFP share at boot so it is accessible to the system without a user logged in? I would like to run scripts via SSH or as a daemon on boot that check files on my AFP share. Unfortunately, the shares don't mount until a user logs in.

For some of my workflows, I need to mount a folder somewhere else, and this process should be transparent, meaning symbolic links don't work. Because macOS don't support mount --bind and the nullfs macOS uses to isolate quarantined programs aren't exposed to the end user, I use sshfs, but it's very slow to mount and hangs the system for a while during the mounting process. Since I have served smb/afp connections from my macbook before, I think maybe that will solve the problem. Trying to mount smb://localhost resulted in the error The file server is available on your computer. Access the volumes and files locally. I assume this failed because Apple think that there is no reason to mount a folder already present on your computer somewhere else on your computer, but I do have valid reasons for doing so. Trying to do this in the Terminal brings up even weirder errors. (To avoid permission errors, I'm doing this is a root shell). Trying with afp:

root@Joys-MacBook-Pro ~ # mount_afp afp://localhost /tmp/data
mount_afp: AFPMountURL returned error 22, errno is 3
root@Joys-MacBook-Pro ~ # mount_afp -i afp://localhost /tmp/data
User: tmp
Password:
mount_afp: AFPMountURL returned error 22, errno is 3
root@Joys-MacBook-Pro ~ # mount_afp -i afp://localhost /tmp/data
User: guest
Password:
mount_afp: AFPMountURL returned error 22, errno is 3
root@Joys-MacBook-Pro ~ # mount_afp -i afp://localhost /tmp/data
User: root
Password:
mount_afp: AFPMountURL returned error 22, errno is 3
root@Joys-MacBook-Pro ~ # mount_afp -i afp://localhost /tmp/data^C
root@Joys-MacBook-Pro ~ #
root@Joys-MacBook-Pro ~ # mount_afp -i afp://tmp:password/localhost /tmp/data
root@Joys-MacBook-Pro ~ # mount_afp -i afp://tmp:password@localhost /tmp/data
mount_afp: AFPMountURL returned error 22, errno is 3
root@Joys-MacBook-Pro ~ # mount_afp -i afp://guest@localhost /tmp/data
Password:
mount_afp: AFPMountURL returned error 22, errno is 3
root@Joys-MacBook-Pro ~ # mount_afp -i afp://tmp:password@localhost/data /tmp/data
mount_afp: AFPMountURL returned error -5023, errno is -5023
root@Joys-MacBook-Pro ~ # mount_afp -i afp://tmp:password@localhost/CCC1 /tmp/data
mount_afp: AFPMountURL returned error -5023, errno is -5023

Trying with smb:

root@Joys-MacBook-Pro ~# mount_smbfs -o nobrowse,soft //localhost /tmp/datra
mount_smbfs: could not find mount point /private/tmp/datra: No such file or directory
root@Joys-MacBook-Pro ~ # mount_smbfs -o nobrowse,soft //localhost /tmp/data
Password for localhost:
mount_smbfs: server rejected the connection: Authentication error
root@Joys-MacBook-Pro ~ #
mount_smbfs -o nobrowse,soft //tmp:passwd@localhost /tmp/data
mount_smbfs: server rejected the connection: Authentication error
root@Joys-MacBook-Pro ~ #
mount_smbfs -o nobrowse,soft //tmp:passwd@localhost/data /tmp/data
mount_smbfs: server rejected the connection: Authentication error
root@Joys-MacBook-Pro ~ # mount -t smbfs //tmp:passwd@localhost/data /tmp/data
mount_smbfs: server rejected the connection: Authentication error

How can I tell if this is something Apple is explicitly trying to prevent me from doing, due to wrong commands/arguments, or due to smb/afp configuration errors? Note: accessing smb shares served from my macbook from a Windows computer on the same network works without any problems.

I want to mount an external drive, connected on computer A, to computer B. I am able to access and mount the drive by connecting to the server through Finder (Command-K), but how can I do this exact action through the terminal? I've been using several formats of mount and mount_afp but nothing seems to work. Something along the lines of: mount_afp -i afp://user:pass@ipaddress/Volumes/SharedDrive /Volumes/Shared In Finder, I just type the IP of the Mac connected to the drive, input credentials, and mount the selected drive...but it's not working by simply entering the afp://ipaddress, just like the 'Connect Server' command through Finder, in the terminal. How do I do the same connection with a bash command? The end result will be the mounted drive on B.