Mosyle Dock Profiles - Question Marks for Network Home

[Gongalong]

Hi folks,

 

We're using Mosyle to manage a classroom of iMacs.

 

We have configured several profiles, one of which adds the iMac to a Windows domain, and another which forces a dock. On the dock profile we have added "Network Home" as a button, and several SMB network shares as buttons. It works for many students, but for many others they don't get the Network Home button at all, and the rest show as question marks. It can happen to users in the same year group, but some year groups anecdotally seem to be better than others. I have looked at the AD accounts for the different year groups but can spot no difference in the way they are configured. The users it doesn't work for seem to be consistent across mutliple iMacs, and ditto for those who it does work for. It doesn't seem to be a function of the network home folder itself, as by chance I tested with a user whose home folder was missing, and the dock icons displayed correctly.

 

Any ideas as to what could be causing this?

 

Mosyle's support have been very patient, and have tried many things, but are stumped.

 

Thanks

[AntonioRocco]

This could be down to a permissions issues and not necessarily anything to do with accounts themselves?

 

If you're nesting student homes within other folders (usual practice for Windows Networks) then you may see this behaviour if you don't allow at least list and/or read permissions downstream to the folder containing the student homes. Permissions may have been iterated for some but not all? Worth investigating perhaps?

 

I've also seen this in networks where .local is used for domain suffix. This can cause timeouts when DNS lookups performed by the Macs conflict with Bonjour. I've also seen the problem with RJ45 splitters being used to share one network port with two workstations especially on 100 BaseT networks.

 

Does nothing happen or do you get an error when you click on the question mark or does the network home icon appear?

 

Antonio Rocco (ACSA)

[Gongalong]

I did wonder about nested folders. They're in a structure Home Folders\Year Group\Student Name, shared from the root folder. Students don't actually have access to the root or the year group folder, or at least they didn't, yet it still works for a lot of students. Because I wondered if it was a permissions issue I added read only access to the year group folder for the specific year groups. I also seem able to browse the whole structure, even as a student who has the issue. I will have a look at this again though.

 

We're using .local, not using splitters. It works for some students, but not for others, and oddly it's consistent across all iMacs. So if student A can get it working, it works on all iMacs. If it doesn't work for Student B on a particular iMac, then it won't work for them on any iMacs. I've also found some students within the same year group where it works, and others where it doesn't.

 

In terms of the dock itself, the home folder doesn't display at all as a dock icon. We then have two SMB shares and a web link, all of which display as question marks. Odd that the web link doesn't display correctly, as that doesn't require permissions.

[AntonioRocco]

That's the problem with using .local. You get random oddness that, sometimes, make no sense. Are logins slower than usual for the students affected when compared to those that are OK or are they the same? Look at what permissions are set for invisible files such as the ".TemporaryItems" folder that macOS creates whenever a folder is accessed. It's possible invisible folders are owned by admin users and disallowed for everyone else or (possibly) only those affected?

 

Are student homes all on one share or spread across multiple shares on separate servers/network drives?

 

Antonio Rocco (ACSA)

[Gongalong]

I'll time the logins and see. It's definitely not a noticeable difference. It almost seems like newer created AD accounts have less problems, for example newer test accounts created in the same year group all seem to work and students that have more recently joined seem to work also. If I could just recreate the AD accounts I would try that, but they're connected into O365.

 

I don't see a .TemporaryItems folder in an affected or unaffected student's. I do see .DS_Store in both affected and unaffected, which I think is a MacOS file.

 

Student home folders are all on one share, but the year groups are in different folders.

[AntonioRocco]

". . . newer accounts have less problems . . ."

 

Sounds like it could be all the crud and cruft (junk in the attic) that builds up over time with any computer? I would focus on existing users' Home/Library folders. Specifically cache files (bin them), ByHost files (in fact bin the whole ByHost folder) and files in the Preferences folder. Depending on how many users you have it's a lot of work and if it turns out to be corrupted files in the Home/Library folder then think about developing a strategy that bypasses the problem. Ideally and if time allows in the summer recess I would refresh/rebuild all Macs as a matter of course as well as treating existing users as if they were new users. There should be nothing they could want or need in their home folder anyway as their data should be elsewhere. A lot depends on what courses the students are using the Macs for. If for Video they should be working locally anyway and saving their data to a network share or locally attached drive. Music and Graphic Design not so much although that depends on what software they're using and the complexity and size of projects they're working on.

 

It's been obvious that with each successive macOS upgrade - the last 2 (Mojave & Catalina) at least - Apple are making it more difficult to work with home folders stored on a network share. Only my opinion but I think their strategy is focused on BYOD (iPhone, iPad or Mac) regardless of whether its Business or Education.

 

Good luck!

[Gongalong]

Sounds like it could be all the crud and cruft (junk in the attic) that builds up over time with any computer?

These are brand new iMacs though. We've just started using them in September. The first iMacs we've ever had in the school, so it's been quite the learning curve, including Mosyle.

 

I can see a .DS_Store file in both affected and unaffected user accounts, but nothing else that's jumping out at me as MacOS related.

 

I might have mentioned above, but the bizarre thing is that the icons worked for a student who didn't have a home directory at all on the server (something had gone wrong during their account creation). That almost suggests it's nothing to do with the folder and permissions at all.

[AntonioRocco]

Does not matter whether they're new or not, it's all about the home folder which can get quite large quickly. Simply logging in will create almost 200MB of data and that's before a program is launched. It won't take long to accumulate 1GB of data and more especially with the courses schools tend to use Macs for. If you're applying quotas that could be an area you could investigate further?

 

Looking ahead and only if time and inclination allows you could try creating a smaller stand-alone testing network where .local is not used and see if the problem disappears.

 

Antonio Rocco (ACSA)

Edited October 1, 2020 by AntonioRocco

[Gongalong]

After some further troubleshooting with Mosyle support, who have been super helpful, they tracked it down to a sort of bug with MacOS. The users that were affected did not have anything in the display name field of their AD record. When MacOS tried to process the user for this part of the dock profile it failed to do it, whereas users that it worked for had a display name. The fix is to have the proper display name in that field - although I have to figure out a way to update those on mass!

 

Kudos to Noelmo in Mosyle support for figuring this out :whoo: