high sierra file ownership

Hello John,

Is the machine just attached to the Windows network or is it fully bound to the network? Can you log in to the machine itself with your Windows account?

Unfortunately, I don't have access to an SMB account anymore, so I can't give you any more specific tips other than questions like that. The last time I used SMB was with Sierra. It was fairly flaky then. Although auto mount still worked, the network mounts would regularly lock up due to the buggy Finder. Trying to do quicklook on network file would inevitably result in a lock up. I quickly got into the habit of editing files by dragging them to the desktop, making my changes, and then copying them back. That was easier than restarting when it got hung up. This was in 2016. If it makes you feel any better, things seem even worse now. Between all my Macs here at home, I no longer even bother using the network. I've got a USB flash drive with USB-C on one end and USB-3 on the other. In 2018, I'm back to sneaker-net.

One useful suggestion I can make is to tell you to simply not do that. The Mac isn't intended for that kind of use anymore. If you are doing development work, you should be using git. Then all your files will be local. That is really the only thing that is supported. You'll have to use the command line too. Xcode's SCM support gets worse every year.

Sorry to be such a downer, but that has been my experience. If I knew of any magical tricks to make it work, I would certainly tell you. Instead, my suggestions are more palliative.

Hi,

Just a very small point of detail you probably have already noticed: Using SMB, the command is very slow. You can get "Fetching ..." several minutes, actually, before the info be really displayed in Get Info.

Regards.

John Dallman wrote:

It claims complete SMB support; I was wanting to get some idea of the state of SMB on Mac. You've given me that, for which many thanks, although I could wish the news was better.

There are different aspects to that. The Mac definitely doesn't claim "complete SMB support". In some cases, if you don't have just the right settings or just the right server configuration, your SMB won't work or will be horribly slow.

But even if you have top-notch SMB settings, there may be other Mac issues. The SMB itself could be just fine. If you were running some kind of software tests, especially something that is cross-platform, I would expect it to work fine 90% of the time. But if you are using Finder, Quicklook, or other OS features that expect not only a local disk, but likely an SSD as well, then you'll have problems.

But if your issues is truly about permissions only, I think you need to reconsider your architecture. Unless you are truly losing money on the Mac and iOS business, don't dump the platform because your tests are no good.

Hi,

For the moment, put everybody on SMB seems to me the best way to slow down all Macs of this network, to the point their actual cooperative, operational efficiency on this network could be bring down, actually, to a very similar equivalent of not to be at all connected to this network.

(I think I'm clear, there, but not certain at 100%) (I'm definitely not English speaking).

That's at least the feeling we have all, as Mac users, when we are connected to a SMB network: that horror, or no network, can't decide....

I mean (basically, in my state of pondering) AFP is clearly superior to SMB or NFS for Mac. While SMB/CIFS is the preferred protocol for Windows clients.....

A Linux server could be able to manage two separate networks, one on SMB the other on AFP, in a way that could appear transparent for the users.

Assuming that Macs and PCs don't exchange tons of data directly from the ones to the others on your network, of course, but only between Mac-to-Mac or PC-to-PC (what I assume actually is the case in the real world, but I may be totally wrong... only you knows the — actual — amount of data exchanged machine by machine).

There's a bonding driver in most Linux kernels that provides a method for aggregating multiple network interfaces into a single logical bonded interface. Users transferring presently files with few bandwith usage may perfectly do not notice any change. While the high bandwith-consuming machines will be able to communicate with the best possible protocol for them, on the (physically) same network. Not by force on a network protocol better adapted for another OS.

In my opinion this method could be way simpler to implement than it may appear at first.

And probably — unless one waits 5 years more that Apple decides at last to give us SMB at its real speed — the best way to make function all the machines of this network at their best performance/network connectivity.

Regards.

PS: To go considerably simpler than rewiring all the company, I would have well advised you to rather set your Windows machines to use AFP... But when I asked on a Windows forum the best/simplest/third-party/any way possible to connect my PC to an afp network, the most common answer was "You would probably be better off using SMB". LOL. More seriously it seems obvious to me that ANY other protocol than SMB — and as told etresoft, they are MANY — would be better, not only for the Macs, but imo, also for the PCs.

Regards.

quote: "AFP was removed from Windows over a decade ago."

I know, alas: we're looking for third-party solutions on Windows since about the same decade....

SMB is working well on Windows, I admit. At least, it has became such a common norm in all companies that it should be indeed simpler to implement than all other methods, but I'm unsure about its actual performances, transfer speed, etc. over the network. I mean, I never tested it personally with high bandwith-consuming tasks, only office work.

Also, I'm not sure that the low speed of Macs over such a network be entirely the fault of Apple, I suspect rather some "programmed" incompatibility coming from the other party...

IMO, if the Macs aren't too much numerous on your network, try to make them work at best of their possibilities — even at the price/hassle of a secondary network, still remains imo, the "less worse" solution. Macs are potentially, individually, extremely powerful machines, it would be too bad to be forced to abandon them for just a network protocol hassle.

Regards.

You still haven't commented on the permissions issue. That is heavily dependent on your SMB testing issues too. Which of these is true?

1) Your product is fundamentally an SMB product. Therefore, your tests require an SMB network with appropriate read and write permissions controlling access to test data.

2) Your product is protocol-agnostic. It is designed to work on any supported file system, network or local. You are using SMB to access test data as a convenience.

If #1 is true, then you are going to have to figure out how to produce a viable product within the limits of the Mac's SMB support. If you were desperate enough, you could use a FUSE-based network driver. Or just drop the Mac because it doesn't work and isn't worth the effort.

If #2 is true, then there is no practical limit to your options. Just pick one.

In either case, you don't want to have read/write access to your test data. Otherwise, one platform with flaky SMB support could invalidate tests for other platforms.

There is no problem with SMB performance on the Mac. The problem is with reliability. If the server isn't configured the way the Mac wants, it will run like molasses. Apple has published specifications for Time Machine over SMB. I'm sure if you conform to these expectations you should have maximum performance and reliability, relatively speaking of course. However, there is a deprecation notice on that documentation. I have no idea what that means. Maybe it means SMB itself is deprecated, Time Machine is deprecated, Time Machine over SMB is deprecated, or that is just boilerplate they've put on all existing documentation. Are you concerned that Apple might deprecate all of macOS, the UNIX interface, and all legacy networking other than HTTPS? If not, you should be. 🙂

John Dallman wrote:

This. I need aworking filing system, and NFS worked just fine for me, until it was removed at High Sierra.

NFS was not removed from High Sierra. NIS was removed. NFS should still work fine. You won't get the benefit of NIS directory services, but that shouldn't be a show-stopper.

test data is read from one volume of the file server, and results are written to a different one.

I don't know what the issues is then. You only need read access to the shared data. You can write the data anywhere, as any user and it shouldn't matter.

Well, that states SMBv3, and if I have SMBv3 turned on, very little works. So I think my NetApp is not configured the way the Mac likes.

SMB was designed for Windows. Most SMB services are primarily for Windows. And Windows does all kinds of crazy things to work with even the most misconfigured services. Apple sticks to the specifications and that makes many products incompatible.

I'm expecting that they will change macOS to being ARM-based, but I would not expect that to be a problem for us. We had no major difficulties with the PowerPC to Intel transition. If they take the UNIX interface or networking away, that will completely kill our development environment, and we'll consider if we want to create a new one or drop them.

That isn't anything the worried about in the near term. But in the long term, it is important to remember that macOS is UNIX because NeXTSTEP was UNIX. It was a convenience. But Apple has never been interested in cross-platform support. If anything, Apple is quite hostile to it. Same goes for enterprise support.

But for now, I'm still mystified about what your exact problem might be. All development platforms require workarounds and they always have. Certainly macOS is different from Linux. But then one Linux distro is significantly different from another. All Linux distros are different than Solaris (RIP). All the above are significantly different than Windows. This is not a new problem.