NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Home Folders won't deploy for already created users
Model: ReadyNas 3220
Firmware: 6.10.5 Hotfix 1
Environment: Win10 20H2-21H1 | Domain
I'm having an issue where after I've enabled Home Folders, already present user profiles on client machines can't access their Home Folders. Any new user I create on the domain, and have login to a client machine (creating a new profile) will be granted access, but for any user that already had a profile on a machine prior to me enabling Home Folders, they get an error:
"Windows cannot access \\ReadyNas\ProfileName
You do not have permission to access. Contact your network admin" etc.
Affected users do appear to have UserName folders within Shares>Home Folder on the ReadyNAS. Access permissions appear to be the issue here. Home Folder>Settings>Access is set to SMB>On, and nothing else.
As a work-around, I'm having to copy their entire User folder to the NAS, delete their profile from the target machine, have them login again to create their profile folder, and then drop everything back in. This works, but it's timely and I'm looking for a better solution.
I read here: kb.netgear.com
"Note: A user's home folder will only be created when that user accesses the ReadyNAS for the first time using his or her account." and suspect that has something to do with it, as we have had, for a long time prior to implementing Home Folders, a Group Policy Object that pushes a desktop shortcut to all end users for \\ReadyNas\CompanyShare. So maybe there isn't a "first time" for affected users, as they've already been connected.
Any help or experience on the matter is greatly appreciated.
OK, so mwilliams' personal folder is assigned to user 33397, which does not exist, and group 32897, which probably doesn't either.
drwx------ 1 33397 32897 0 Jan 30 2020 mwilliams
His proper user GUID is 33988 and his group is 33281:
uid=33988(mwilliams) gid=33281(domain users)
So I think chown -R mwilliams:33281 mwilliams from the .home share should fix the problem.
If not, then chown -R 33988:33281 mwilliams.
If the first one works, then this script should do it for all:
cd /home
for dir in */; do chown -R "${dir%?}:33281" "$dir"; done
chown -R admin:admin adminI'm using the GID for the group because I'm not entirely sure how to handle the group name "domain users" with a space in it.
If you have to use the UID instead of the name to make it work, then it'll take a lot more to get that info, and it's probably easier to just do it manually unless hou have a huge number of affected users.
15 Replies
Are you comfortable wiith the Linux command prompt via SSH? If so, go to the home folder and see if those users' folders belong to the:
cd /home
ls -all
The listing for User1 should look like:
drwx------ 1 User1 users 22 Nov 6 2019 User1
Then go into one of the users' folders and see about the file ownership:
cd <username>
ls -all
A file should look like:
-rw-r--r-- 1 User1 users 136364 Nov 16 2010 MyPic.jpg
This is assuming your default group is users and all are a member of that group. If anything is wrong, you can use Linux commands to fix it. If you need help, come back and paste in some results and we can give you the appropriate commands. It will still take some of your time, but not nearly as much as copying the files back and forth.
If you have a whole lot of users, a command script could be written to do it all.
So, if the problem is ownership and all the users' primary group is users, then the following should fix it:
cd /home
for dir in */; do chown -R "${dir%?}:users" "$dir"; done
chown -R admin:admin admin
If you are unsure that ownership is the issue, come back and let us verify from a sample listing from the ls -all commands.
Make absolutely certain you are in the /home directory before giving the second command.
The last command sets the group for admin back to admin since the other changed it to users. If you have just a couple other users with a different primary group, then you can manually fix them like I did with admin. If you have multiple primary groups, it'll take a lot more effort to write the script.
Okay, I'm a bit new at Linux, but was able to get this far with few issues.
Permissions appear to be the same drwx------ on all user accounts within /home/DOMAIN, where the profile folders exist for Home Folders.The only differences I see are that the affected users are missing information for columns "User1", and the column that would normally list "domain", and the very next column that should say "users" only lists a number "32897".
Sorry, I couldn't figure out a Format-Table equivalent for Linux that would work. Columns 3,5, and 6 if I were to guess.
I've bolded the columns in question:
Affected Users:
drwx------ 1 emptycolumn 33397 emptycolumn 32897 0 Jan 30 2020 usernameMade-up example of a Working Profile:
drwx------ 1 username 33397 domain users 2.3K Sep 20 2021 username
There are no files in the affected user directories.
Do I need to manually change these columns?
I think we are on the right track, but I don't have an AD system, and it's obviously different in that case, so can't tell you how to fix it.
Linux will use the GUID for a user or group if it can't resolve it into a name, so that's what those numbers are. That definitely seems to be a part of the puzzle, though I'm surprised that the ones that work also seem to have an undefined user name.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
