Cannot use the $user instead of username on a SMB Connector

I’m trying to add a SMB connector, but I can’t use the $user variable for the remote subfolder… Any help ?

I’m guessing you’re following the instructions given on this page:

Could you give us more information about your setup?
Nextcloud version, Windows Server version, how the connection is made, etc?


I’m using Nextcloud 11 and Debian 8.

The connecion is made with an LDAP authentication.

My SMB connector works with the username instead the $user, but wont’t work with this last one,

Thank’s a lot for your help !

Did something happen here, is there a solution?

I’ve got the same problem with a nextcloud 12 on ubuntu 16.04. If I use /share/real.username it works, if I use /share/$user it doesn’t.

i once had it working… only disadvantage was: i needed to
mkdir /share/$user
for every user manually to make it work.

hmmm. So you created folders for each user like: /share/some.person /share/other.person …? or did you create /share/$some.person …?

In my case all the folders exist. If I set the path to /share/some.person it works well but not with /share/$user instead. But it should be the exact same name cause the accounts are synced with the ActiveDirectory.

i manually created a folder for every user under share. and it was exactly like the login-username. and then /share/$user worked exactly like expected.
mkdir /share/pers1 worked perfect for user pers1
mkdir /share/PeRs2 worked perfect for user PeRs2

so it seems as if $user isn’t pointing to the right folder. could you check that out?

Yes it seems like. Are there any logfiles where I can see what $user is resolved to? Or can I check it on the CLI somehow? Do you think the dot “.” in the middle of the username could cause a problem?

what about manually setting a value for $user yourself and check if you would be able to do a cd /share/$user from the terminal and where you would end up with it? try it with “” as well (could be a problem, indeed)
sure enough there are logfiles. but i don’t know which ones and where to find them.

I was pretty sure that this will work, but I’ve tested this as root on the shell:

# mkdir /root/test1
# mkdir /root/test.user

# user=test1
# echo $user
# cd /root/$user

# user=test.user
# echo $user
# cd $user

Or can I open a shell in the UI in the user context?

Anyway, I also tested it once again with a user without a dot in the name. Just the same:

works not:


also works:

and also works:

After the test I’ve checked the files:
/var/log/nginx/access.log (access.log.1)
/var/log/nginx/error.log (error.log.1)
/var/log/nginx/nextcloud.access.log (nextcloud.access.log.1)
/var/log/nginx/nextcloud.error.log (nextcloud.error.log.1)

but found nothing usefull…

just in case… have you tried setting it up like in example 1 just with a /$user instead of just $user - other than that i don’t know how to help you :frowning:

Same behavor:

I also just tested to set the loglevel from 2 to 0. But I can not realy see what $user resolves to. Only thing I found in /srv/nextcloud/nextcloud.log:

{"reqId":"jsmtZjP1ReyIOYp9iKBR","level":0,"time":"2017-08-08T15:38:13+02:00","remoteAddr":"","user":"7246DFBC-67F4-43B3-B37C-CA61B0469AB3","app":"user_ldap","method":"PROPFIND","url":"\/remote.php\/dav\/files\/7246DFBC-67F4-43B3-B37C-CA61B0469AB3\/","message":"Requested attribute gidnumber not found for cn=allplan,ou=benutzer,ou=messmer,dc=messmer,dc=local","userAgent":"Mozilla\/5.0 (Windows) mirall\/2.3.1 (build 8) (Nextcloud)","version":""}

But I don’t realy know if the missing gidnumber is what I’m looking for.

awww. could it be that $user isn’t translated into xxx.yyy but into the uid? that would explain why it would fail.
so try to find out where $user gets it’s value and point it to xxx.yyy instead ;o)

I made a folder named

And look at this…

So step one is done. But how can I point to the username instead of the UID? I could creat a link on the fileserver for everey user but that is not what I like to do :slight_smile:

as for now i’d say try and find it in the appcode itself… and change it there.
plus (as your changes are gonna vanish with the next update) go and talk to the maintainer of this app.

another possibility is: name your folders after the UID.

Now I see the exact problem… and it is easy like that:

My users look like that:

Because of:

The solution is:

and the result is:

But notice:

Changes will have effect only on newly mapped (added) LDAP users.


may someone can mark this as solved (solution) - I can not :slight_smile:

1 Like

very cool!
let’s get @jospoortvliet into it - maybe he can mark it solved…

1 Like

Just registered to say THANK YOU, this is exactly it!

I might add that it’s advisable to run
occ ldap:reset-user <ldapUid>
for every user that’s already been created before the configuration change. This will keep their Nextcloud account and everything connected with it (NC group memberships etc.), yet make the sAMAccountname the internal username, thus render the $user variable in External Storage Backends usable.