[opensuse] NFS client woes (Windows)
I am running an openSUSE 15.1 NFS server in a cluster with a mix of Linux and Windows clients. The Linux side of everything seems to be working great. The NFS clients on Windows 10 seem unstable. They seem always to have trouble maintaining the connection. There are four Windows computers that are doing the same thing. They are pretty much identical. Wait a minute. Why am I asking what appears to be a Windows question here? Well, I can't be 100% positive it is simply that the official Windows 10 NFS client from Microsoft is so unstable, I do not see any discussions about this. Surely there would be a blip on the radar. All I see are things about speed comparisons. So, I am thinking that the server and client are somehow mismatched. So I'm starting by asking: Is anyone using the MS NFS client for Windows 10 with an openSUSE NFS server? Why NFS? Mainly because it is easy to share and unshare directories independently. The server maintains a disk array with 24 removable disks (hot swappable). These disks come and go independently. So they need to be exported and unexported independently. I do not see how to do this with SAMBA. All is in one big file and they are shared and unshared together. We do not want to disrupt some disks while changing others. So NFS seemed a way to go. If I have missed something in SAMBA, I would be ever so happy. That was question two. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
Why NFS? Mainly because it is easy to share and unshare directories independently. The server maintains a disk array with 24 removable disks (hot swappable). These disks come and go independently. So they need to be exported and unexported independently. I do not see how to do this with SAMBA. All is in one big file and they are shared and unshared together. We do not want to disrupt some disks while changing others. So NFS seemed a way to go. If I have missed something in SAMBA, I would be ever so happy. That was question two.
You have 24 disks with 24 individual filesystems, and those are exported via NFS. I am sure you can do the same with samba. A samba share: [photos] comment = Photos directory path = /home/per/photos read only = No inherit acls = Yes No reason why you shouldn't have 24 of those ? I expect shares can also be added and removed dynamically, I just don't know how :-) -- Per Jessen, Zürich (15.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jul 7, 2020 at 9:29 AM Per Jessen <per@computer.org> wrote:
Roger Oberholtzer wrote:
Why NFS? Mainly because it is easy to share and unshare directories independently. The server maintains a disk array with 24 removable disks (hot swappable). These disks come and go independently. So they need to be exported and unexported independently. I do not see how to do this with SAMBA. All is in one big file and they are shared and unshared together. We do not want to disrupt some disks while changing others. So NFS seemed a way to go. If I have missed something in SAMBA, I would be ever so happy. That was question two.
You have 24 disks with 24 individual filesystems, and those are exported via NFS. I am sure you can do the same with samba.
A samba share: [photos] comment = Photos directory path = /home/per/photos read only = No inherit acls = Yes
No reason why you shouldn't have 24 of those ? I expect shares can also be added and removed dynamically, I just don't know how :-)
I know that I tried this initially with NFS. We mount everything under /array (not very creative). A udev rule senses when a disk is inserted, and it is then automatically mounted and exported based on the physical slot. We thought we would just mount /array on the clients, and the things under this would just be there or not. This did not work as we expected. I think that we later found that there is an option to NFS (client or server, I don't remember) that causes it to keep what the client sees up-to-date when things in the export are changed (unmounted/mounted things somewhere in the share). But I think we never did get that to work as expected. I should add that on the Linux NFS clients, the remote disks are automounted as they are needed. This has the advantage that if a disk is not inserted on the server (it is not exported), it cannot be mounted on the client, and the mount point remains unavailable. Otherwise one can wind up writing to the directory 'under' the mount point, if you know what I mean. If they only mount /array, I don't know how the clients will see if a disk under /array is really mounted, or if they are just writing to the directory on which the disk should have been mounted. I think we need to explore this option for NFS again. As long as the clients will know when a disk is in fact not available. As to CIFS, I have no idea. I will definitely try simply sharing /array and see what happens. I am just curious what happens when a disk is not in the array. What does the client see? What happens if they try to write to the directory where the disk would have been had it been inserted? It is interesting that on Windows, there is a mount/umount command. It has basically the same syntax as the Unix/Linux command. What is strange is that it is per login. So, if two people have ssh to the Windows computer at the same time, each will need to mount/umount the shares. I cannot decide if that is good or bad. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
Otherwise one can wind up writing to the directory 'under' the mount point, if you know what I mean. If they only mount /array, I don't know how the clients will see if a disk under /array is really mounted, or if they are just writing to the directory on which the disk should have been mounted.
If it were me, I would probably not want to make my clients aware, but if you have to, maybe put some marker file on the filesystem for the client to check. if present => mounted.
As to CIFS, I have no idea. I will definitely try simply sharing /array and see what happens. I am just curious what happens when a disk is not in the array. What does the client see? What happens if they try to write to the directory where the disk would have been had it been inserted?
If a disk is not in the array, only the empty mount point is seen. The client will just write to that. It sounds like you do need to make your clients aware of the mount-status. -- Per Jessen, Zürich (17.9°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jul 7, 2020 at 11:04 AM Per Jessen <per@computer.org> wrote:
Roger Oberholtzer wrote:
Otherwise one can wind up writing to the directory 'under' the mount point, if you know what I mean. If they only mount /array, I don't know how the clients will see if a disk under /array is really mounted, or if they are just writing to the directory on which the disk should have been mounted.
If it were me, I would probably not want to make my clients aware, but if you have to, maybe put some marker file on the filesystem for the client to check. if present => mounted.
As to CIFS, I have no idea. I will definitely try simply sharing /array and see what happens. I am just curious what happens when a disk is not in the array. What does the client see? What happens if they try to write to the directory where the disk would have been had it been inserted?
If a disk is not in the array, only the empty mount point is seen. The client will just write to that.
It sounds like you do need to make your clients aware of the mount-status.
Using automount actually solves this. If the directory can be mounted, you can access it. Otherwise you get an error when trying to access it. It is one of the things I really like about automount. At least this works on the Linux clients. Windows is a bit more problematic. As usual. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Tue, Jul 7, 2020 at 11:04 AM Per Jessen <per@computer.org> wrote:
It sounds like you do need to make your clients aware of the mount-status.
Using automount actually solves this. If the directory can be mounted, you can access it. Otherwise you get an error when trying to access it.
Really ? is that with systemd automount or the "oldfashioned" automount daemon ? -- Per Jessen, Zürich (19.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jul 7, 2020 at 11:40 AM Per Jessen <per@computer.org> wrote:
Roger Oberholtzer wrote:
On Tue, Jul 7, 2020 at 11:04 AM Per Jessen <per@computer.org> wrote:
It sounds like you do need to make your clients aware of the mount-status.
Using automount actually solves this. If the directory can be mounted, you can access it. Otherwise you get an error when trying to access it.
Really ? is that with systemd automount or the "oldfashioned" automount daemon ?
They are the same. All systemd does is set up automount via whatever you put in /etc/fstab. I use the systemd method. It works extremely well for me. In our measurement systems, we sometimes use removable disks (SATA in a drive bay) where the operator can choose to collect data. Prior to using automount, if the operator forgot to put in a disk, he would unknowingly collect data to the directory on which it should have been mounted. With automount, accessing that directory fails if the disk is not inserted. Problem solved. Since we use systemd, we have service files that act on when the drives are mounted. We can ensure mount point permissions or do whatever we want automatically when they are mounted. It works very well once you figure out the way systems thinks. In the current example, we use systemd to manage exporting and unexporting the disks as they are mounted and unmounted. I just wish we had better knowledge of some aspects of systemd so that we could be better at defining our service. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
On Tue, Jul 7, 2020 at 11:40 AM Per Jessen <per@computer.org> wrote:
Using automount actually solves this. If the directory can be mounted, you can access it. Otherwise you get an error when trying to access it.
Really ? is that with systemd automount or the "oldfashioned" automount daemon ?
They are the same. All systemd does is set up automount via whatever you put in /etc/fstab. I use the systemd method. It works extremely well for me.
I wouldn't perhaps call them "the same" - I have both in use, for different purposes. I agree, the systemd automount works very well. I guess it makes sense for it to also prevent access if a mount point could not be mounted.
Since we use systemd, we have service files that act on when the drives are mounted. We can ensure mount point permissions or do whatever we want automatically when they are mounted. It works very well once you figure out the way systems thinks. In the current example, we use systemd to manage exporting and unexporting the disks as they are mounted and unmounted. I just wish we had better knowledge of some aspects of systemd so that we could be better at defining our service.
Sounds like a pretty neat solution. -- Per Jessen, Zürich (19.3°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 07 Jul 2020 11:04:11 +0200 Per Jessen <per@computer.org> wrote:
Roger Oberholtzer wrote:
Otherwise one can wind up writing to the directory 'under' the mount point, if you know what I mean. If they only mount /array, I don't know how the clients will see if a disk under /array is really mounted, or if they are just writing to the directory on which the disk should have been mounted.
If it were me, I would probably not want to make my clients aware, but if you have to, maybe put some marker file on the filesystem for the client to check. if present => mounted.
It is perfectly possible and sensible to set the permissions of the underlying mount point to 000. Then nobody will be writing anything to the underlying filesystem :) Mounting something on top changes the permissions to whatever it has. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
On Tue, 07 Jul 2020 11:04:11 +0200 Per Jessen <per@computer.org> wrote:
Roger Oberholtzer wrote:
Otherwise one can wind up writing to the directory 'under' the mount point, if you know what I mean. If they only mount /array, I don't know how the clients will see if a disk under /array is really mounted, or if they are just writing to the directory on which the disk should have been mounted.
If it were me, I would probably not want to make my clients aware, but if you have to, maybe put some marker file on the filesystem for the client to check. if present => mounted.
It is perfectly possible and sensible to set the permissions of the underlying mount point to 000. Then nobody will be writing anything to the underlying filesystem :) Mounting something on top changes the permissions to whatever it has.
There was something like that lurking in the back of my mind, thanks for digging it out :-) -- Per Jessen, Zürich (19.2°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jul 7, 2020 at 12:02 PM Dave Howorth <dave@howorth.org.uk> wrote:
It is perfectly possible and sensible to set the permissions of the underlying mount point to 000. Then nobody will be writing anything to the underlying filesystem :) Mounting something on top changes the permissions to whatever it has.
More than one way to skin a cat. This is interesting. I will look in to this. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/07/2020 01:52 AM, Roger Oberholtzer wrote:
Why NFS? Mainly because it is easy to share and unshare directories independently. The server maintains a disk array with 24 removable disks (hot swappable). These disks come and go independently. So they need to be exported and unexported independently. I do not see how to do this with SAMBA. All is in one big file and they are shared and unshared together. We do not want to disrupt some disks while changing others. So NFS seemed a way to go. If I have missed something in SAMBA, I would be ever so happy. That was question two.
There are pluses and minuses for NFS usage. About 15+ years ago, I went to straight smb and samba for Windows Linux filesystem interoperability. Somewhere around Samba 2.02a on either SuSE 7 or 8 pro. I made the switch and never looked back. Samba still has a "standalone" file-server mode which is what I use (but it has grown way beyond simply file server/filesystem access control to a full blown domain controller (I just don't have a need for that enterprise level interoperability or complexity. The good news is as a file server and SMB application, configuration with the good-ole smb.conf is all that is still required. If your windows NFS connections are flaky, just CIFS mount the windows shares as part of the Linux side of your cluster and just work with them as if they were Linux.It's not that bad to get on top of. It works for so long without having to mess with it -- I end up having to re-learn (or at least refresh on it) any of the very rare times I need to make changes. That's a good measure of a setup. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jul 7, 2020 at 11:26 AM David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
On 07/07/2020 01:52 AM, Roger Oberholtzer wrote:
Why NFS? Mainly because it is easy to share and unshare directories independently. The server maintains a disk array with 24 removable disks (hot swappable). These disks come and go independently. So they need to be exported and unexported independently. I do not see how to do this with SAMBA. All is in one big file and they are shared and unshared together. We do not want to disrupt some disks while changing others. So NFS seemed a way to go. If I have missed something in SAMBA, I would be ever so happy. That was question two.
There are pluses and minuses for NFS usage. About 15+ years ago, I went to straight smb and samba for Windows Linux filesystem interoperability. Somewhere around Samba 2.02a on either SuSE 7 or 8 pro. I made the switch and never looked back. Samba still has a "standalone" file-server mode which is what I use (but it has grown way beyond simply file server/filesystem access control to a full blown domain controller (I just don't have a need for that enterprise level interoperability or complexity. The good news is as a file server and SMB application, configuration with the good-ole smb.conf is all that is still required.
smb.conf is in fact the source of the problem. When the disks to share are changing independently, and one cannot interrupt one disk to change the status of another, a single file that controls them all is not a good thing. The exportfs/mount/umount commands operate per disk. That is the main reason I choose NFS. Also, it allowed me to have one file server setup on the disk array server that did not need to care if the client was Linux or Windows. But the ability to manage each disk independently was a big deciding factor. I will report back on what I find relative to Per's suggestion. Can you share the same directory both via NFS and CIFS at the same time? I was trying to avoid this kind of thing.
If your windows NFS connections are flaky, just CIFS mount the windows shares
These are not Windows shares. They are shared by a Linux server. The clients are a mix of Linux and Windows. And the Windows clients are the ones that have some odd stability issue. I don't have any religious connections to NFS or CIFS. I just want whatever is stable and reliable. And that has the disk independence that I require. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Roger Oberholtzer wrote:
smb.conf is in fact the source of the problem. When the disks to share are changing independently, and one cannot interrupt one disk to change the status of another, a single file that controls them all is not a good thing. The exportfs/mount/umount commands operate per disk.
I just looked up the samba 'net' utility - I _think_ you might be able to achieve this single file manageability using 'net usershare'. Just a wild guess, I have never looked at it in any detail. -- Per Jessen, Zürich (19.4°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/07/2020 08.52, Roger Oberholtzer wrote:
I am running an openSUSE 15.1 NFS server in a cluster with a mix of Linux and Windows clients. The Linux side of everything seems to be working great. The NFS clients on Windows 10 seem unstable. They seem always to have trouble maintaining the connection. There are four Windows computers that are doing the same thing. They are pretty much identical.
Wait a minute. Why am I asking what appears to be a Windows question here? Well, I can't be 100% positive it is simply that the official Windows 10 NFS client from Microsoft is so unstable, I do not see any discussions about this. Surely there would be a blip on the radar. All I see are things about speed comparisons.
I did hear about the windows client not being stable, but I did not pay much attention. It could of course be openSUSE servers. Perhaps asking on other places :-? -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
* Roger Oberholtzer <roger.oberholtzer@gmail.com> [07-07-20 02:53]:
I am running an openSUSE 15.1 NFS server in a cluster with a mix of Linux and Windows clients. The Linux side of everything seems to be working great. The NFS clients on Windows 10 seem unstable. They seem always to have trouble maintaining the connection. There are four Windows computers that are doing the same thing. They are pretty much identical.
Wait a minute. Why am I asking what appears to be a Windows question here? Well, I can't be 100% positive it is simply that the official Windows 10 NFS client from Microsoft is so unstable, I do not see any discussions about this. Surely there would be a blip on the radar. All I see are things about speed comparisons.
So, I am thinking that the server and client are somehow mismatched. So I'm starting by asking: Is anyone using the MS NFS client for Windows 10 with an openSUSE NFS server?
Why NFS? Mainly because it is easy to share and unshare directories independently. The server maintains a disk array with 24 removable disks (hot swappable). These disks come and go independently. So they need to be exported and unexported independently. I do not see how to do this with SAMBA. All is in one big file and they are shared and unshared together. We do not want to disrupt some disks while changing others. So NFS seemed a way to go. If I have missed something in SAMBA, I would be ever so happy. That was question two.
I to had "flakey" connections with nfs and switched to cifs/sshfs and both have been rather solid. I cannot say that there not been interruption but they have been very few and far between. <user> crontab: @reboot echo "<passwd>" | sshfs -p 22 -C -o password_stdin,reconnect,delay_connect,ServerAliveInterval=15,ServerAliveCountMax=3,allow_other carolyn@carolyn:/C:/ /home/paka/carol/ /etc/fstab //192.168.1.100/C-Share/ /home/paka/cifs cifs credentials=/root/.smbcredentials,guest,nofail,_netdev,iocharset=utf8,sec=ntlmssp,uid=1000,gid=100,file_mode=0777,dir_mode=0777,noserverino 0 0 those are single lines. and permissions are not exactly the same, sshfs reveals more files on the windows side. <passwd> on sshfs can be directed to use a file as "credentials" does in fstab. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2020-07-07 02:52 AM, Roger Oberholtzer wrote:
So, I am thinking that the server and client are somehow mismatched. So I'm starting by asking: Is anyone using the MS NFS client for Windows 10 with an openSUSE NFS server?
How do you know it's not a Windows problem? MS has a long history of breaking things. That said, I have long used Samba for sharing files. The last time I used NFS on a non *nix system was when I configured NFS on OS/2. Back then, NFS was a separate package for it. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Jul 7, 2020 at 2:56 PM James Knott <james.knott@jknott.net> wrote:
On 2020-07-07 02:52 AM, Roger Oberholtzer wrote:
So, I am thinking that the server and client are somehow mismatched. So I'm starting by asking: Is anyone using the MS NFS client for Windows 10 with an openSUSE NFS server?
How do you know it's not a Windows problem? MS has a long history of breaking things. That said, I have long used Samba for sharing files. The last time I used NFS on a non *nix system was when I configured NFS on OS/2. Back then, NFS was a separate package for it.
I agree that it could be the Window's NFS client. But surely there would be a mention of this in a Google search. Or is an openSUSE server (and it's NFS defaults) so rare that no one uses it with a Windows 10 NFS client? I have tried Per's suggestion of sharing the directory in which all the drives are mounted, using CIFS. I can say that the adding/removing of a disk under the mount did show up as desired on the client. The main thing that we miss is being able to see how much space is available on each disk from the client. Our plan of attack is first to see if CIFS makes things more stable. If that is the case, then we will explore using the SAMBA net program to manipulate each individual disk in much the same way we did with NFS' exportfs. It's always nice to have things to try. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
I can now verify that using CIFS on the Windows client is stable. I do not know if it is the Windows 10 NFS client that is the problem, or some mismatch in NFS settings between the openSUSE 15.1 server and the client that is the problem. But the NFS client is simply unusable. RIP. I was happy that the SAMBA net command was mentioned. That made using CIFS in our setup possible. We will now transition our openSUSE server to use SAMBA/net instead of NFS/exportfs to manage dynamic CIFS shares. On Tue, Jul 7, 2020 at 5:42 PM Roger Oberholtzer <roger.oberholtzer@gmail.com> wrote:
On Tue, Jul 7, 2020 at 2:56 PM James Knott <james.knott@jknott.net> wrote:
On 2020-07-07 02:52 AM, Roger Oberholtzer wrote:
So, I am thinking that the server and client are somehow mismatched. So I'm starting by asking: Is anyone using the MS NFS client for Windows 10 with an openSUSE NFS server?
How do you know it's not a Windows problem? MS has a long history of breaking things. That said, I have long used Samba for sharing files. The last time I used NFS on a non *nix system was when I configured NFS on OS/2. Back then, NFS was a separate package for it.
I agree that it could be the Window's NFS client. But surely there would be a mention of this in a Google search. Or is an openSUSE server (and it's NFS defaults) so rare that no one uses it with a Windows 10 NFS client?
I have tried Per's suggestion of sharing the directory in which all the drives are mounted, using CIFS. I can say that the adding/removing of a disk under the mount did show up as desired on the client.
The main thing that we miss is being able to see how much space is available on each disk from the client.
Our plan of attack is first to see if CIFS makes things more stable. If that is the case, then we will explore using the SAMBA net program to manipulate each individual disk in much the same way we did with NFS' exportfs.
It's always nice to have things to try.
-- Roger Oberholtzer
-- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Carlos E. R. -
Dave Howorth -
David C. Rankin -
James Knott -
Patrick Shanahan -
Per Jessen -
Roger Oberholtzer