Is nolock a bad thing?

[JohDut]

I Just switched from an Thecus NAS to a QNap TS809 Pro. Basically because I wanted more storage capacity.

I use Ubuntu 10.04, and access the TS809 with NFS.
When trying to use OpenOffice working with files on the TS809 it would only allow to open files Read-only because "they were in use by another user".
Obviously this was not the case. And it would not allow to save any file to the NAS for the same reason.

On searching this forum I found the solution. That is, if I mount it with the 'nolock' option, I can work with files on the NAS.
So I mount like this:
sudo mount -t nfs -o nolock ts809:/sharename /mnt/mountpoint/

Somewhere it is described that the 'nolock' is for "older" NFS-servers (well my TS809 is brand new !), or that it is just a temporary workaround.

My question is: Is it a "bad" thing to mount your NAS with a 'nolock' option ?

Does it create problems with simultaneous file access. Or does it bring the risk of data loss?
Or am I just worried for no reason, and should I just always use the nolock option ?

Any insight would be appreciated.

[micke]

When trying to use OpenOffice working with files on the TS809 it would only allow to open files Read-only because "they were in use by another user".
:
My question is: Is it a "bad" thing to mount your NAS with a 'nolock' option ?

When one application isn't working as expected it is probably better to try to "fix" the application instead of changing the configuration of NFS Anyway, I don't expect you to be able to fix this bug in openoffice, but as a workaround you could disable the file locking in openoffice.

Open the soffice file (different location in different linux distributions, /usr/lib/openoffice/program/soffice, /usr/lib/openoffice.org3/program/soffice, etc.) You might be able to locate it with a simple 'which soffice". Find and comment out the following lines,

Code: Select all

SAL_ENABLE_FILE_LOCKING=1
export SAL_ENABLE_FILE_LOCKING

That is, it should look like this

Code: Select all

#SAL_ENABLE_FILE_LOCKING=1
#export SAL_ENABLE_FILE_LOCKING

Now, this could result in two users writing to a file at the same time, but in a small home network that shouldn't be much of a problem.

I believe this file locking problem will solve itself when we get NFSv4.

/Mike

[tmt]

You shouldn't have to use -o nolock, and yes it's a bad thing if you need to. What firmware version are you running on your ts809?

[JohDut]

@micke

I totally agree with your suggestion that I rather fix OpenOffice than use a nolock option to mount my NAS.

Unfortunately, your suggestion for setting SAL_ENABLE_FILE_LOCKING to 0, does not resolve the problem.
Still get a "file is in use by other user" error.
A friend of mine, having the same problem (albeit on a Synology NAS) had the same experience with the " SAL_ENABLE_FILE_LOCKING patch" not working for Ubuntu, while in fact it did solve his problem on Fedora.

When looking at soffice, in fact there seems to be a detection if...then for files on nfs volumes.
file_on_nfs(){
for i; do
case "$i" in -*) continue; esac
[ -f "$i" ] || continue
case $(stat -f -c %T "$i") in nfs|smb)
return 0
esac
done
return 1
}

And even attempting to force all files on NFS (which is true in my case anyway) and changing it to something like:
file_on_nfs(){
return 1
}


does not solve the problem either.

@tmt
My firmware is: 3.3.2 build0819
Which to my knowledge is the latest. It is dated 25-08-2010 !


The reason for my post was that I was not comfortable using a 'nolock' option all the time either.
I might add that I had the same problem with my previous Thecus N5200Pro NAS, but this was resolved by a firmware update, which made it possbile to edit OpenOffice files without a 'nolock' option on mount.

So if you have any suggestions, that would still be appreciated.

[micke]

A friend of mine, having the same problem (albeit on a Synology NAS) had the same experience with the " SAL_ENABLE_FILE_LOCKING patch" not working for Ubuntu, while in fact it did solve his problem on Fedora.

I have an old installation of ubuntu (9.04) on a laptop, but when I tried to open files on nfs it worked just fine. No problem at all (apart from making sure correct ownership is set on the files). Maybe something has changed in 10.04, so I started up a live CD of 10.04, installed nfs support, and tried to open the same file on nfs. Locked by unknown. After editing soffice it worked just fine again, but you have to make sure that both lines with 'export SAL_ENABLE_FILE_LOCKING' in the auto case are commented out (you could just as well comment out all lines with 'export SAL_ENABLE_FILE_LOCKING' in the file).

Try it and see if it works for you, too.

/Mike

[micke]

Unfortunately, your suggestion for setting SAL_ENABLE_FILE_LOCKING to 0, does not resolve the problem.

BTW, my suggestion was not to set SAL_ENABLE_FILE_LOCKING to 0. The important part is to not include the export of SAL_ENABLE_FILE_LOCKING no matter what value it has.

/Mike

[tmt]

@tmt
My firmware is: 3.3.2 build0819
Which to my knowledge is the latest. It is dated 25-08-2010 !

Yes, it's the latest.

What happens if you run the "flock" command on the client machine, to a regular file on the NAS NFS-mounted volume? Do this without the nolock option when mounting.

$ flock /mnt/NAS/ordinaryfile sleep 2

[tmt]

Looks like NFS file locking is broken on 3.3.2 (and maybe others).

Wireshark trace shows normal NFS and NLM traffic, but NLM_DENIED_NOLOCKS coming back from the QNAP server. This trace uses a Fedora 11 client.

Code: Select all

[tmt@tmt-f11 ~]$  flock /mnt/movelocks sleep 2
flock: /mnt/movelocks: No locks available
[tmt@tmt-f11 ~]$ 

Code: Select all

No.     Time        Source                Destination           Protocol Info
      2 1.882951    172.16.91.129         192.168.0.100         NFS      V3 ACCESS Call (Reply In 4), FH:0xb9471a89
      3 1.883142    192.168.0.100         172.16.91.129         TCP      nfs > 959 [ACK] Seq=1 Ack=117 Win=64240 Len=0
      4 1.891862    192.168.0.100         172.16.91.129         NFS      V3 ACCESS Reply (Call In 2)
      5 1.891942    172.16.91.129         192.168.0.100         TCP      959 > nfs [ACK] Seq=117 Ack=125 Win=8576 Len=0
      6 1.892264    172.16.91.129         192.168.0.100         NFS      V3 LOOKUP Call (Reply In 8), DH:0xb9471a89/movelocks
      7 1.892315    192.168.0.100         172.16.91.129         TCP      nfs > 959 [ACK] Seq=125 Ack=245 Win=64240 Len=0
      8 1.893074    192.168.0.100         172.16.91.129         NFS      V3 LOOKUP Reply (Call In 6), FH:0xe1dbbee5
      9 1.893175    172.16.91.129         192.168.0.100         NFS      V3 ACCESS Call (Reply In 11), FH:0xe1dbbee5
     10 1.893221    192.168.0.100         172.16.91.129         TCP      nfs > 959 [ACK] Seq=373 Ack=369 Win=64240 Len=0
     11 1.893980    192.168.0.100         172.16.91.129         NFS      V3 ACCESS Reply (Call In 9)
     12 1.894273    172.16.91.129         192.168.0.100         TCP      48358 > sunrpc [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=1992000 TSER=0 WS=6
     13 1.897238    192.168.0.100         172.16.91.129         TCP      sunrpc > 48358 [SYN, ACK] Seq=0 Ack=1 Win=64240 Len=0 MSS=1460
     14 1.897338    172.16.91.129         192.168.0.100         TCP      48358 > sunrpc [ACK] Seq=1 Ack=1 Win=5840 Len=0
     15 1.897570    172.16.91.129         192.168.0.100         Portmap  V2 GETPORT Call (Reply In 17) NLM(100021) V:4 TCP
     16 1.897693    192.168.0.100         172.16.91.129         TCP      sunrpc > 48358 [ACK] Seq=1 Ack=97 Win=64240 Len=0
     17 1.898657    192.168.0.100         172.16.91.129         Portmap  V2 GETPORT Reply (Call In 15) Port:49009
     18 1.898717    172.16.91.129         192.168.0.100         TCP      48358 > sunrpc [ACK] Seq=97 Ack=33 Win=5840 Len=0
     19 1.898781    172.16.91.129         192.168.0.100         TCP      48358 > sunrpc [FIN, ACK] Seq=97 Ack=33 Win=5840 Len=0
     20 1.898848    172.16.91.129         192.168.0.100         NLM      V4 LOCK Call (Reply In 25) FH:0xe1dbbee5 svid:5 pos:0-0
     21 1.898951    192.168.0.100         172.16.91.129         TCP      sunrpc > 48358 [ACK] Seq=33 Ack=98 Win=64239 Len=0
     22 1.899011    192.168.0.100         172.16.91.129         TCP      49009 > 941 [ACK] Seq=1 Ack=193 Win=64240 Len=0
     23 1.899749    192.168.0.100         172.16.91.129         TCP      sunrpc > 48358 [FIN, PSH, ACK] Seq=33 Ack=98 Win=64239 Len=0
     24 1.899815    172.16.91.129         192.168.0.100         TCP      48358 > sunrpc [ACK] Seq=98 Ack=34 Win=5840 Len=0
     25 1.901569    192.168.0.100         172.16.91.129         NLM      V4 LOCK Reply (Call In 20) NLM_DENIED_NOLOCKS
     26 1.901630    172.16.91.129         192.168.0.100         TCP      941 > 49009 [ACK] Seq=193 Ack=41 Win=5840 Len=0
     27 1.930257    172.16.91.129         192.168.0.100         TCP      959 > nfs [ACK] Seq=369 Ack=497 Win=9648 Len=0

[JohDut]

BTW, my suggestion was not to set SAL_ENABLE_FILE_LOCKING to 0. The important part is to not include the export of SAL_ENABLE_FILE_LOCKING no matter what value it has.

OK, that made things more clearly !

Actually the code block in soffice looks like this:
if [ -z "$SAL_ENABLE_FILE_LOCKING" ]; then
case "$FILE_LOCKING" in
auto)
home_on_nfs "$@"
if [ $? = 0 ]; then
STAR_PROFILE_LOCKING_DISABLED=1
export STAR_PROFILE_LOCKING_DISABLED
fi
file_on_nfs "$@"
if [ $? = 0 ]; then
SAL_ENABLE_FILE_LOCKING=0
export SAL_ENABLE_FILE_LOCKING
# for safety
STAR_ENABLE_FILE_LOCKING=0
export STAR_ENABLE_FILE_LOCKING
else
# file locking now enabled by default
SAL_ENABLE_FILE_LOCKING=1
export SAL_ENABLE_FILE_LOCKING
fi
;;
yes)
SAL_ENABLE_FILE_LOCKING=1
export SAL_ENABLE_FILE_LOCKING
;;
no)
SAL_ENABLE_FILE_LOCKING=0
export SAL_ENABLE_FILE_LOCKING
# for safety
STAR_ENABLE_FILE_LOCKING=0
export STAR_ENABLE_FILE_LOCKING
STAR_PROFILE_LOCKING_DISABLED=1
export STAR_PROFILE_LOCKING_DISABLED
esac
fi

Commenting out all references to SAL_ENABLE_FILE_LOCKING (and it exports) did not do the trick.

But there seems to be somehting like STAR_ENABLE_FILE_LOCKING as well.
And as the code block seems only to set SAL_ENABLE_FILE_LOCKING and STAR_ENABLE_FILE_LOCKING to either 0 or 1, and you suggested not to export anything, I tried removing this codeblock completely.

And yes indeed ! This does the trick.
It allows me to open and save files directly to the NAS.
So problem solved for me

What happens if you run the "flock" command on the client machine, to a regular file on the NAS NFS-mounted volume? Do this without the nolock option when mounting.

When I use the flock command you suggest I get:

joost@aci7:~$ flock /mnt/qnas8a/mydocs/test.odt sleep 2
flock: /mnt/qnas8a/mydocs/test.odt: Geen vergrendelingen meer beschikbaar

Which roughly translates to "no locks available any more" (I'm dutch so I use a dutch version of Ubuntu).

Not exactly sure what this means. But seems to be a problem with locking the file form flock as well....

[micke]

I tried removing this codeblock completely.

And yes indeed ! This does the trick.
It allows me to open and save files directly to the NAS.
So problem solved for me

Well, solving the problem (or symptom) is important

Actually, when I tried out Ubuntu 10.04, I started with removing the exports of both SAL_ENABLE_FILE_LOCKING and STAR_ENABLE_FILE_LOCKING. When I found that it worked I added back the exports one by one to find out how much I really had to remove. In my case it worked just fine with the STAR_ENABLE_FILE_LOCKING exported.

/Mike

[JohDut]

Looks like NFS file locking is broken on 3.3.2 (and maybe others).

Wireshark trace shows normal NFS and NLM traffic, but NLM_DENIED_NOLOCKS coming back from the QNAP server. This trace uses a Fedora 11 client.

Obviously you posted this when I was typing my reply.

I kinda get what your saying.
But seems something for QNap firmware development right?

Not much an end-user like me can do?

For now I'll use the OpenOffice workaround, and keep a close look at firmware upgrades.

Thanx for all the input.

[tmt]

Yes, it's a bug for QNAP. There may be a workaround on the QNAP server but I don't have time to look for it, now. Your OpenOffice workaround is probably the best you can do at the moment. Be sure you don't do any file sharing! You might have file corruption if two instances update the same file.

[micke]

Looks like NFS file locking is broken on 3.3.2 (and maybe others).
:

Code: Select all

[tmt@tmt-f11 ~]$  flock /mnt/movelocks sleep 2
flock: /mnt/movelocks: No locks available
[tmt@tmt-f11 ~]$ 

As far as I know, NFS doesn't support flock()-style locking (neither does POSIX require that the flock() system call supports locking over NFS). The flock command is only a wrapper to the system call, so unless that has changed recently I guess it won't work over NFS.

/Mike

[tmt]

No, flock() works over NFS since 2.6.<somesingledigit>. It's true that 2.4 didn't, and it's also true that you can't mix Posix and flock style. But the flock commandline utility does work over NFS and the trace shows the server failed the request (as I bet it's doing to OpenOffice too). Bug.

Here's a message from the NFS maintainer, for instance.

[micke]

No, flock() works over NFS since 2.6.<somesingledigit>.

If that is true, then the man page for flock(2) should be updated,

flock() does not lock files over NFS. Use fcntl(2) instead: that does
work over NFS, given a sufficiently recent version of Linux and a
server which supports locking.

/Mike