Access UnRAID shares from Ubuntu 20.04 LTS VM


SliMat

Recommended Posts

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;

 

Nextcloud.jpg.ef2d1221f726f52e84cbc01649c9daab.jpg

 

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 by SliMat
Link to comment
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.

Link to comment
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

Link to comment

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 by Tom3
Link to comment

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?

Link to comment
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.

 

Link to comment

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

 

 

 

 

 

 

Link to comment
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 ;-)

Link to comment
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

Link to comment

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

Link to comment
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

Link to comment

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

 

Link to comment

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.

 

Link to comment

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.

Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.