4

I'm having some issues using NFS to access files on a small PC via a home LAN.

It appears to work perfectly when I'm using Nautilus or the command line, but when I try to save an application such as LibreOffice or GIMP, I get a few second delay, then a "Write error". When opening an existing file from the NFS share it tells me "This file is locked for editing by Unknown User".

These applications can open and save files on local drives without problems.

My current workaround is to open as Read-only and save the file onto my desktop, then use Nautilus to copy it to the location from where I originally opened it.

My local PC is using Ubuntu 20.04, and the server says it's on: "5.3.0-53-generic #47~18.04.1-Ubuntu SMP"

My local /etc/fstab entry:

192.168.50.186:/nas/shared /shared nfs rsize=8192,wsize=8192,timeo=14,hard,nfsvers=3

On the server my /etc/exports file:

/nas/shared   192.168.50.186/255.255.255.0(rw,insecure,no_subtree_check,async)

In 18.04 this problem only affected LibreOffice, but now it also affects the GIMP and Krita and probably others.

James Bradbury
  • 325
  • Can you give more details on what operations you perform with Nautilus or the command line, which work well? Same for failing operations with LibreOffice/GIMP. – sancho.s ReinstateMonicaCellio Jul 14 '20 at 09:57
  • Does this error happen on new files or when you edit an existing file? – Thomas Aichinger Jul 14 '20 at 10:56
  • Can you create a new file with echo "Hello world" > /shared/test? Do you have the same user on both machines and does this user have the apporpriate rights? – Thomas Aichinger Jul 14 '20 at 11:02
  • Is it possible that LibreOffice wants to save the file in some sub-directory where your local user does not have access rights? – Thomas Aichinger Jul 14 '20 at 11:05
  • The "hello world" test works without complaint. – James Bradbury Jul 16 '20 at 21:40
  • @sancho.sReinstateMonicaCellio I've described what happens open and save - what else do you need to know? – James Bradbury Jul 16 '20 at 21:44
  • @ThomasAichinger It happens on both new files and existing file. Every file (that I've tried) on the NAS drive has this problem. – James Bradbury Jul 16 '20 at 21:45
  • 1
    Are these snaps installs? I had a similar situation and the synopsis ended up being that snaps are configured to confine actions to their own operation space (which I believe was configurable in some cases). There was nothing I could do to make the software application see symbolic links or mount point that led to the separate drive. – WU-TANG Jul 17 '20 at 03:41
  • @WU-TANG Interesting point! I can't see a snap install for LibreOffice as it came pre-installed, but the GIMP and Krita are both installed via snap. I'll do some testing and find out. – James Bradbury Jul 17 '20 at 09:18
  • I followed these instructions to remove snap from my system. https://www.kevin-custer.com/blog/disabling-snaps-in-ubuntu-20-04/ For GIMP and Keepassxc this solves the problem! LibreOffice still has the problem. Perhaps that's installed in a different way. – James Bradbury Jul 17 '20 at 12:46
  • @JamesBradbury... so what was the effect of that process? Did it remove the applications and you had to reinstall them via apt-get or compiling the source? or did it just remove the snap architecture? Were there any side affects? I wasn't that bold to experiment, I just tried to decided to find a similar app in the apt repository... First I tried and failed to change the snap permissions described here: https://askubuntu.com/questions/964377/snap-application-doesnt-see-files-from-another-partition.... coincidentally it mentions Keepassxc – WU-TANG Jul 17 '20 at 13:37
  • Yes, it was a bit drastic, but it's a new install so I don't mind too much. I removed the snap applications and reinstalled via apt. However, it seems that LibreOffice is not installed via snap, so it might be a completely different problem. – James Bradbury Jul 17 '20 at 19:54

2 Answers2

1

I finally worked out what the issue is - group permissions.

The files on the NAS server all have R/W/X permissions for a group called "nasusers" with id=1002.

This can be seen with a simple ls -la in the folder on the server.

Doing the same command locally shows the group as "1002" because the group "nasusers" does not exist on the local client machine. To fix this I ran (locally on my client):

sudo groupadd -g 1002 nasusers

Running id shows that my user is not a member of this group. To add myself to the group I ran (locally on my client):

sudo adduser james nasusers

Also, on the server I set the permissions of the shared files to 770, so owner and group have full permissions and others have none.

This has allowed me to open and save files from the NAS server from LibreOffice and the GIMP without errors.

James Bradbury
  • 325
0

based on the link(and the testing you've done so far), add another mount to a subdirectory of your share from your home directory and test with libreoffice.
(you can change the current mount but, I'm trying not to be too invasive of your current setup)

192.168.50.186:/nas/shared/Libreofficestuff /home/yourusername/sharefoldername nfs rsize=8192,wsize=8192,timeo=14,intr,nfsvers=3

I think you may have to use subtree_check

/nas/shared   192.168.50.186/255.255.255.0(rw,insecure,subtree_check,async)
WU-TANG
  • 3,071
  • Thanks for the suggestion, but the subtree_check didn't make any difference for LibreOffice. – James Bradbury Jul 17 '20 at 19:52
  • @JamesBradbury just making sure... you realize i didn't suggest to ONLY change to subtree_check right? I actually wrote it wrong... so my bad.... I will edit those directions... see above. The subtree_check change was for the "NEW" mount point that points to a NEW subdirectory on your current nfs share... – WU-TANG Jul 17 '20 at 20:23
  • Yes, thank you for this, but I'm afraid it didn't help. – James Bradbury Jul 20 '20 at 17:17