SliMat Posted January 20, 2021 Share Posted January 20, 2021 (edited) Hi I have been reading and trying, for a couple of days, to mount an UnRAID share in an Ubuntu VM... without success. It is frustrating as I have done it in the past - but didn't note down how to do it. The closest I have got is by editing the XML file to add... <filesystem type='mount' accessmode='passthrough'> <source dir='/mnt/user/nextcloud/'/> <target dir='nextcloud'/> <alias name='nc'/> <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/> </filesystem> Then in the VM, I edited \etc\fstab and added... nextcloud /nextcloud 9p trans=virtio,version=9p2000.L,_netdev,rw 0 0 Once this is done and rebooted, I do have a \nextcloud folder, as expected, but when I try to access it I get a permission denied error - obviously I can't sudo cd \nextcloud I am guessing that the access error is because the VM has a different username/password to the allowed users to the share - if so, do I need to create a user based on my login/password - or change the root password to match the UnRAID servers root users credentials? I did deviate from this and tried to get it working by mounting the SMB share - but that was even less successful. Can anyone help? Oh, yes - before anyone asks this is a new NextCloud Server as I have been using the Linuxserver Nexcloud docker for ages, but everytime there is an update I end up with it failing to update, so this time followed the manual process as is said that it wasnt compatible with PHP7.3 and wouldnt even let me login... but now after the manual process I have this error; So decided that the more robust way is to create a Nextcloud VM on 20.04 LTS rather than using a docker and mounting my \mnt\user\nextcloud share from UnRAID (which is where all my data is) then using occ on the Nextcloud VM to rescan all my users data 🤔. Any assistance will be greatly appreciated as I know I am so close with mounting the share in my VM and my Nexcloud Server has been offline for 3 days now 🤨 Thanks Edited January 20, 2021 by SliMat Quote Link to comment
John_M Posted January 20, 2021 Share Posted January 20, 2021 4 hours ago, SliMat said: I am guessing that the access error is because the VM has a different username/password to the allowed users to the share - if so, do I need to create a user based on my login/password This. More specifically, it's the UID that has to match, rather than the username. Quote Link to comment
SliMat Posted January 21, 2021 Author Share Posted January 21, 2021 2 hours ago, John_M said: This. More specifically, it's the UID that has to match, rather than the username. Thanks for the pointer @John_M - can you advise what the correct UID should be, or where I can find it, to allow the VM access to the UnRAID share and I will try to change it to match. Thanks Quote Link to comment
Tom3 Posted January 21, 2021 Share Posted January 21, 2021 (edited) At the command prompt: root@Tower:~# id uid=0(root) gid=0(root) groups=0(root) root@Tower:~# Similarly at the VM's command prompt will probably give you something like UID=1000 PID=1000 Groups=1000 (typical for Ubuntu VM). Edited January 21, 2021 by Tom3 Quote Link to comment
SliMat Posted January 21, 2021 Author Share Posted January 21, 2021 Thanks @Tom3 On UnRAID I got; uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),17(audio),281(docker) On the Ubuntu VM; uid=1000(username) gid=1000(username) groups=1000(username),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),116(lxd) So, do I need to force the UID, GID & groups for [username] to 0 to match root on UnRAID... or is 0 reserved for root only? Quote Link to comment
John_M Posted January 21, 2021 Share Posted January 21, 2021 16 hours ago, SliMat said: can you advise what the correct UID should be It doesn't matter what it is, as long as it's the same inside the container and outside, in Unraid. Avoid UID=0, because that's the root user. The nobody user has UID=99. If you start adding users to Unraid (Settings -> Users -> Add User) the first one will be given UID=1000, then next one UID=1001, etc. So if the share you want to access is public then nobody (UID=99) would be a good choice. If you want to make the share private then create a new user with an appropriate name. You can then confirm that new user's UID by cat /etc/passwd You'll see a line at the end that looks like this: john_m:x:1000:100:John M:/:/bin/false the 1000 in that line is the UID. If you use the same username with the same UID across your network of computers, life is so much easier. Quote Link to comment
Tom3 Posted January 21, 2021 Share Posted January 21, 2021 Hi Slimat, root always has UID=0 (it doesn;t necessarily have to be called root, that could be changed). You may want to look at the permission for the share on the server. Just open a command line to /mnt/user/to_your_share then do a ls -la The will show you something like: dxwrxwrxwr 1 root root 4096 date ./ dxwrxwrxwr 1 root root 171 date ../ --wr-wr--- 1 root root 227594 date the_file_name ... etc ... If the owner and group are root root (as above) and the file permissions (the trailing --- above on the filenbame) prohibit wr access to the user then you won't have permission to read or write as UID=1000. Unraid uses nobody users to mean the anonymous owner/group. chown command changes the owner/group (lookup syntax via google) chmod command changes the permissions. If you want to open it up to anybody, chmod the permissions to 777 on the file(s). (again, lookup syntax via google). I use a share to backup my computers, using anonymous access because my backup program only understands that. Then I go in afterwards and change the backup files owner/group to root root and permissions to 444 (allowing read-only access). This makes the backup files usable for restoration, but they can't be changed. -- Tom Quote Link to comment
SliMat Posted January 21, 2021 Author Share Posted January 21, 2021 Thanks @Tom3 - I'll have a play tonight when I get a chance and test it out. Quote Link to comment
SliMat Posted January 21, 2021 Author Share Posted January 21, 2021 29 minutes ago, John_M said: It doesn't matter what it is, as long as it's the same inside the container and outside, in Unraid. Avoid UID=0, because that's the root user. The nobody user has UID=99. If you start adding users to Unraid (Settings -> Users -> Add User) the first one will be given UID=1000, then next one UID=1001, etc. So if the share you want to access is public then nobody (UID=99) would be a good choice. If you want to make the share private then create a new user with an appropriate name. You can then confirm that new user's UID by cat /etc/passwd You'll see a line at the end that looks like this: john_m:x:1000:100:John M:/:/bin/false the 1000 in that line is the UID. If you use the same username with the same UID across your network of computers, life is so much easier. Thanks @John_M - hopefully I may get a chance to play with this later tonight and see how it goes Quote Link to comment
SliMat Posted January 22, 2021 Author Share Posted January 22, 2021 21 hours ago, Tom3 said: Hi Slimat, root always has UID=0 (it doesn;t necessarily have to be called root, that could be changed). You may want to look at the permission for the share on the server. Just open a command line to /mnt/user/to_your_share then do a ls -la The will show you something like: dxwrxwrxwr 1 root root 4096 date ./ dxwrxwrxwr 1 root root 171 date ../ --wr-wr--- 1 root root 227594 date the_file_name ... etc ... If the owner and group are root root (as above) and the file permissions (the trailing --- above on the filenbame) prohibit wr access to the user then you won't have permission to read or write as UID=1000. Unraid uses nobody users to mean the anonymous owner/group. chown command changes the owner/group (lookup syntax via google) chmod command changes the permissions. If you want to open it up to anybody, chmod the permissions to 777 on the file(s). (again, lookup syntax via google). I use a share to backup my computers, using anonymous access because my backup program only understands that. Then I go in afterwards and change the backup files owner/group to root root and permissions to 444 (allowing read-only access). This makes the backup files usable for restoration, but they can't be changed. Hi @Tom3@John_M OK, the /mnt/user/nextcloud share on the UnRAID server was 770... I tried 776 but was still getting permission denied - unsurprisingly I set the nextcloud folder permissions to 777 and was allowed in - but I have noticed files are 775 which means I will be able to read and not write to them. Also I am not keen on setting 777 permissions unless absolutely needed. The /mnt/user/nextcloud folder ownership on UnRAID is; drwxrwx--- 1 nobody users 108 Oct 3 2019 nextcloud/ so, is the best/safest way to give my new VM full read/write to this share and all its files/folders to chmod 777 recursively (simple), or to change the UID & GID of the VM's user to nobody:users (99:100 ?). If this is the best way - I have the user I login with and the unused root account... do I need to create a "nobody" user and a "users" group? If so, how do I do this? This nextcloud server is only being used for family - so I dont have any real concerns about security so if 777 recursively is simplest and reasonably safe then I can do this. Many thanks Many thanks Quote Link to comment
Tom3 Posted January 22, 2021 Share Posted January 22, 2021 Hi Slimat - I would not change the UID/PID in the VM. The nobody/users ownership in UNRAID allows anonymous access, so changes should not be needed. You can recursively change permissions of the files. Pick whatever access attributes you feel comfortable, they need to apply also to the last field (i.e. not 770, but 777 or maybe 776 (R/W but not X) or 774 (read only). On my system I have the . and .. directories set to 777 and nobody/users, while the individual files are set to 444 read-only. You have multiple choices to meet your needs. -- Tom Quote Link to comment
SliMat Posted January 22, 2021 Author Share Posted January 22, 2021 4 minutes ago, Tom3 said: Hi Slimat - I would not change the UID/PID in the VM. The nobody/users ownership in UNRAID allows anonymous access, so changes should not be needed. You can recursively change permissions of the files. Pick whatever access attributes you feel comfortable, they need to apply also to the last field (i.e. not 770, but 777 or maybe 776 (R/W but not X) or 774 (read only). On my system I have the . and .. directories set to 777 and nobody/users, while the individual files are set to 444 read-only. You have multiple choices to meet your needs. -- Tom Hi @Tom3 I set permissions to 776 and still get access denied - on the UnRAID server it shows; drwxrwxrw- 1 99 users 108 Oct 3 2019 nextcloud So its odd that with RW permissions I still cant access the share - so it looks like I may have to set everything to 777 recursively for files and folders... obviously going forward when I get NextCloud back online, any new files created will show what UID/GID is being assigned by the Nextcloud VM. Thanks Quote Link to comment
Tom3 Posted January 22, 2021 Share Posted January 22, 2021 HI SLimat - it appears you have the ownership set incorrectly. The user should be 'nobody' and the group 'users'. It looks like the user is 'users' and the group is blank. Not sure what happens when the group is unspecified. You can chown nobody:users on the affected directories/files. -- Tom Quote Link to comment
John_M Posted January 22, 2021 Share Posted January 22, 2021 Some containers allow you to set the UID and GID under which they run, others don't. If you can change them in your container (I know nothing about Nextcloud) then change them to UID=99 and GID=100, so as to match those of the Unraid 'nobody' user. If you can't change them, then you'll need to determine what the container uses and change the ownership of the /mnt/user/nextcloud directory, accordingly. Quote Link to comment
strike Posted January 23, 2021 Share Posted January 23, 2021 I just do this on every linux install I have, works like a charm: https://forums.linuxmint.com/viewtopic.php?f=42&t=144997 I have saved the auto.sambashares file on my share so I only need to install the packages and put the file in the right place and I'm good to go, access to all the shares I want in a minute. Quote Link to comment
SliMat Posted January 23, 2021 Author Share Posted January 23, 2021 Thanks @strike@Tom3@John_M Theres a lot to go through here and to compound it I dont seem able to change (or define during setup) where my Nextcloud VM stores its datafiles... so it may look like I will end up setting up a new Linxserver Nextcloud Docker instead as this worked... but I will look to see if theres any info on how to get my new NextCloud VM to use the mounted \nextcloud share for its file store. I have a lot going on at the moment, including a failed Exchnage server, which is taking priority - but I will feedback what happens in the end in case anyone else stumbles on this post with similar issues. Many thanks for all the great advice and I'll let you know how I get on. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.