Repeated trouble mounting unraid shares in linux systems

[daninet]

This forum is my last hope, please help. 🥺 I have been through ubuntu forums, then opensuse forums then multiple subreddits trying to get help but seemingly I have no grip on the problem. I was confident it is a linux problem (still might be)

I have an unraid home server and avarage number of laptops and PCs around the house. Everyone is a windows user and I never had any issue with SMB shares on windows. However I'm a linux user and I'm having a lot of trouble mounting my shares.

I have been through ubuntu, debian and now on opensuse tumbleweed and the issue is the same on all distro. Last year I was using windows on this PC and never had trouble mounting my shares. I have tried NFS and SMB shares mounting with the same result. (This was a very generic reply I got elsewhere why I dont use NFS, I do now, same problem)

 

This is what happening:

I'm mounting my shares with fstab (tried autofs also, same result), everything working fine then after some undefined period of time one or two of my shares are not accessible. It is always accessible on system startup. I have public and private shares, it is not related to the authentication, sometimes public is also inaccessible (on SMB).

There is no specific action that results in my shares inaccessible. Sometimes I'm just browsing the web, sometimes I work from the shares.

I -obviously- always notice it when I try to open a file from my share or save something there (so on linux it is either through dolphin or xdg-desktop-portal). My linux system's log has no entry on it, only when I try to open the path it throws a path unavailable error.

 

This is how my fstab looks like (currently using NFS)

#//192.168.1.200/Private                     /smb/Private    cifs   credentials=/home/daninet/.smbcredentials,uid=1000,gid=1000,vers=3.0,nounix,_netdev   0 0
#//192.168.1.200/Work                        /smb/Work       cifs   credentials=/home/daninet/.smbcredentials,uid=1000,gid=1000,vers=3.0,nounix,_netdev   0 0
#//192.168.1.200/Download                    /smb/Download   cifs   credentials=/home/daninet/.smbcredentials,uid=1000,gid=1000,vers=3.0,nounix,_netdev   0 0
192.168.1.200:/mnt/user/Private /smb/Private nfs defaults 0 0
192.168.1.200:/mnt/user/Work /smb/Work nfs defaults 0 0
192.168.1.200:/mnt/user/Download /smb/Download nfs defaults 0 0

 

My "Private" share is currently inaccessible, this is what I see: https://imgur.com/a/kZEMYGA

 

To solve the problem I always have to:

sudo umount /smb/Private
sudo mount -a

 

After this I can access it again: https://imgur.com/a/IoT7Nv8

 

As I have mentioned I have used the same fstab config on 3 different distros with the same result and always have this weird timeout error. I don't know if this is the problem with the linux kernel in general, fstab, cifs, unraid. I don't know where to look for any kind of error code and I certainly don't know why it is happening.

Diagnostics attached.

I'm open to any idea to resolve this. Thank you

 

tevenas-diagnostics-20240107-1714.zip

[bmartino1]

Unfortunate, unraid doesn't support this due to how they have a F* up samba/NFS config. 

 

What you have is 3 share not setup correctly under the unraid web GUI

 

Private, Work, Download

 

unraid - Open terminal and type testparm and click enter will give you your samba config that is running

 

You will see that under the webgui, shares that these are set to "export no"... they need to be set to  "hidden yes" or "yes" to be able to access smb share mounts.

 

In your case, as you are trying to set up nfs share, nfs needs export yes.

 

I recommended theses extra settings:

 

 

under smb extra:

####################

 

[global]

#Protocols:
    domain master = yes
    preferred master = yes
    os level = 200
    server role = standalone server

 

###################

 

Confirm that you have exported your 3 shares correctly

 

 

Now onto your linux system:

Make sure you have installed to correct packages for your distro to us smb cifs and NFS

https://linuxize.com/post/how-to-mount-an-nfs-share-in-linux/

 

unraid follows close to a Debian system. the fstab on your linux system should be flowing this example:

https://askubuntu.com/questions/890981/how-to-configure-a-nfs-mounting-in-fstab

 

the folders you are to mount need to exist first.

on your linux system, mkdir /smb/Work etc etc..

 

then mount your share manuly to test

 

Mount type nfs location locamachine path:

 

mount -t nfs 192.168.1.200:/mnt/user/Work /smb/Work

 

verify access if yes we are rady to make a fstab path if no check unraid permission of folder

 

Fix File permissions. Open eveything to test. as we don't know what user is accessing write or executing what...

 

chmod -R 777 /mnt/user/Work

cd /mnt/user/Work

chmod -R 777 *

chown -R nobody:nogroup the folder path and all files with in...

 

then fstab time:

 

vim / nano /etc/fstab

 

192.168.1.200:/mnt/user/Work /smb/Work nfs defaults 0 0

 

Your linux system is either missing the necessary packages to use nfs / samba cifs or your unraid share is set up incorrectly.

 

You may need to specify a timeout and retry for the nfs connection.

https://serverfault.com/questions/889860/how-to-configure-reasonable-timeout-for-nfs

 

faulty network configuration can drop packets, need for NFS to maintain a share.

Edited January 14 by bmartino1

[daninet]

Hello,

Thank you for your answer.

First, for the SMB:

As I mentioned in my original post, I have multiple windows machines and SMB shares work flawlessly. On my linux system the SMB mount works for... hours. Then suddenly it is unreachable. Then I have to umount and mount -a to make it work again. I posted above the fstab mount points I have used, I don't think I have any error in my setup on client side. It is working. Just the connection is dropping randomly for one of the share.

The only settings I dont have are the global parameters you have defined, although looking on them I doubt they are responsible for this.

I'm pretty much stalled why it is not working so yes, as you said I decided to move to NFS.

As you see in my first post I already have those defined in fstab, the SMB is commented out, I kept it for reference.

I have NFS enabled, export yes, set to private and have defined the rules for my linux system's IP address to be sys,rw

Now the following is happening:

I'm unable to mount the share called Private, only the other two (work and downloads), I get permission denied message in terminal. The settings are same for all 3 mounts word to word. I found no logic why one is working why the other not. So for private I have used SMB and NFS for the rest.

SMB still disconnects after an hour or so, so I'm at where I started.

 

For the record, I'm distrohopping from time to time and the same happened of Debian, Ubuntu and OpenSuse Tumbleweed (that is my current system).

Edited January 15 by daninet

[bmartino1]

Ok, Thank you for clarifying.

 

My first thought is the network in how they are connected. I have not experienced a timeout nor share issues. So my first thoughts are the network switch / vlan that may be dropping packets for connection. Unraid is not as simple to make smb nor nfs config changes.

 

When using samba and running a linux samba server, I have found windows to be super finicky, if your Windows system have no issues translating hostnames to access SMB share don't add the samba settings.

 

In your Linux Box. If you are getting a good mount and are able to (touch a file/ edit the file and save / and remove the file) you should be good if any of that failes you have to fix your unraid Linux file permissions. We first need to be able to do that before looking into increasing the rule on the share for connection and stream numbers for the time-out you are experiencing. netstat and time mount comand check dmesg and other to get error of the actual time out on your linux box.

 

https://superuser.com/questions/1700514/how-to-debug-nfs-client-connection-timeout

 

https://www.ibm.com/docs/en/zos/2.1.0?topic=environment-nfs-client-system-performance-tuning

 

So lets First check NFS:

 

in unraid terminal as unraid also predefines some config settings for nfs:

cat /etc/nfsmount.conf

 

setting Private for to private and not setting file ACL is why you can't access it...

see post: 

 

 

*NFS does not have concept of passwords for security. it relies on network ACLs and filesystem ACLs

*Security = Secure make eveything readonly

*Security = Private requries a rule to allow a machine to read and write

 

What is your rule?

 

These have to be set under the share web gui.

 

Edited January 15 by bmartino1

[bmartino1]

see also:

as Linux distro have, file systems timeout by default and don't keep network shares available all the time. Did the Linux system sit idle or go into hibernation?

Were you interacting with the share at that time?

 

The default is to give a time-out and reconnect if able, did it reconnect? This is all normal Linux behavior.

 

What is not a correct time-out error is while editing the file making changes or large data transfer to the Mount point. In which case, check your network cables to and from the machine first.

 

When the Linux hits the time-out while messing with files in the mount, what of the Windows machines? If windows can't access during the same time, you may have an unstable unraid instance running and freezing.

 

I would give you file system time out commands, but as you are distro hoping, i can't be sure they would translate. And we haven't tested other contingency that may be causing the problem to disclose unraid as the culprit for the timeout.

 

ATM you still have 3 share that are not configured right base on your second post. Please review the forum links i have sent you and re-setup you web gui nfs shares.

Edited January 15 by bmartino1

[bmartino1]

If your looking for a good distro with a trusted repository, I would recommend these two depending on your needs.

 

Debian Based Ubuntu Mate. Using the original Gnome 2.0 form ubuntu 7... Debain is a general all-purpose OS

https://ubuntu-mate.org/download/

 

For Gaming and all around support, I would recommend Arch Linux distro Manjaro running the rpi twister UI

https://manjaro.org/download/

 

You would need to run xfce to install the twister ui https://twisteros.com/twisterui.html

 

Both of these distros and gui come with the correct packages for smb / nfs and I can confirm with my own test with them of their working with unraid shares.

Edited January 15 by bmartino1

[daninet]

Thank you for the detailed answer. There is a lot to unpack and I will dig myself through the settings.

As for some of your questions:

Quote

Did the Linux system sit idle or go into hibernation?

Were you interacting with the share at that time?

I initially thought xdg-desktop-portal is somehow responsible (the window that lets you pick or save a file). Very often the following happens: I download a file (any file really, pdf, image etc) from the internet, save the file to my share with the xdg-desktop-portal and when I open dolphin the share is no longer reachable.

 

Edit:

I'm really happy now, I was able to trigger it with xdg-desktop-portal and record it also.

See video attached. This is an SMB mount.

This also happens if I just let it be for an hour.

2024-01-16_10-54-59.mkv

Edited January 16 by daninet

[bmartino1]

on unraid ls -a and ls -l to get the file permission list of the directory.

 

This is a theory. You are using a linux user on the linux box to access a mount. The mount access is mounted by root at the fstab system level. When you use the application at launch it is launched as your linux_User and not as root_User. therefore, when you access the path your access is as Linux_User here is where 

 

Fix File permissions. Open everything to test. As we don't know what user is accessing write or executing what...

 

chmod -R 777 /mnt/user/Private

cd /mnt/user/Private

chmod -R 777 *

chown -R nobody:nogroup /mnt/user/Private

cd /mnt/user/Private

chmod -R 777 *

 

I even mentioned earlier. I recommend you run the above commands just to test. As in the end, we don't know what user access unraid Linux at the user / group level from your Linux box. And unraid acl permission kicked, saying you don't have access to this location. This would have been fixed with samba share setting

 

[Private]

force user=nobody (or a samba user with user/group permission to write to that folder)

 

^This is not easy to add to the premade samba config on unraid...

That way, anything writing in the share writes as the unraid permission user nobody (which translate to any account / anonymous). 

Without the file permission being ##7 your Linux user done't have read write access to that path which is why you see what looks to be a error in the mount...

 

The reason why the Linux box can still see and use it in terminal as the time-out reconnect is still there from fstab running as root... as that mounted the path correctly as it was told. What is not normal is the gui dolphin explorer switch to and from multiple network path and failing. sadly, that would be a ting for the dolphin team as its not a bug, but not normal behavior. 

 

You have shown me prof that your unraid permission on the unraid linux side are not setup correctly and should be properly set to be 755 or 705 as we need unraid to have other user read write and execute for nfs and samba.

 

in unraid I recommend you use midnight command by typing mc to move to the folder path and use advance crown to see what file permissions are set to the individual folders.

[daninet]

Hi,

Thank you for your replies. I think I have cracked it and it is related to inodes and unraid's cache. The file inode changes when unraid moves the file from cache to hdd and the share unmounts.

Adding noserverino flag to the smb mount resolves the problem.

This is the proper config for unraid cached shares with fstab:

//server_address/share_name                     /mount/path    cifs   credentials=/home/username/.smbcredentials,uid=1000,gid=1000,vers=3.0,noserverino,nounix,_netdev   0 0

 

Thank you for all the help it was really useful and have learnt a lot.