[Samba] Eclipse (Java) locking issues after upgrade (3.6.23 -> 4.4.3)

Discussion:

(too old to reply)

Luc Lalonde

2016-05-20 16:10:01 UTC

Hello,

We seem to not be able to use Eclipse with a network drive since we
upgraded our Samba server to version 4.4.3.

Here's the error we get:

mac-mini:MacOS user$ ./eclipse

java.lang.RuntimeException: Error initializing storage.

at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:68)

at org.eclipse.osgi.launch.Equinox.<init>(Equinox.java:31)

at org.eclipse.core.runtime.adaptor.EclipseStarter.startup(EclipseStarter.java:303)

at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:239)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:673)

at org.eclipse.equinox.launcher.Main.basicRun(Main.java:610)

at org.eclipse.equinox.launcher.Main.run(Main.java:1519)

Caused
by: java.io.IOException: An error occurred while locking file
"/home/user/.eclipse/org.eclipse.platform_4.6.0_1664049636_macosx_cocoa_x86_64/configuration/org.eclipse.osgi/.manager/.fileTableLock":
"Operation not supported". A common reason is that the file system or
Runtime Environment does not support file locking for that location.
Please choose a different location, or disable file locking by passing
"-Dosgi.locking=none" as a VM argument.

at org.eclipse.osgi.internal.location.Locker_JavaNio.lock(Locker_JavaNio.java:49)

at org.eclipse.osgi.storagemanager.StorageManager.lock(StorageManager.java:388)

at org.eclipse.osgi.storagemanager.StorageManager.open(StorageManager.java:701)

at org.eclipse.osgi.storage.Storage.getChildStorageManager(Storage.java:1785)

at org.eclipse.osgi.storage.Storage.getInfoInputStream(Storage.java:1802)

at org.eclipse.osgi.storage.Storage.<init>(Storage.java:128)

at org.eclipse.osgi.storage.Storage.createStorage(Storage.java:87)

at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:66)

... 10 more

mac-mini:MacOS user$ mount

/dev/disk0s2 on / (hfs, local, journaled)

devfs on /dev (devfs, local, nobrowse)

map -hosts on /net (autofs, nosuid, automounted, nobrowse)

map auto_home on /home (autofs, automounted, nobrowse)

map -fstab on /Network/Servers (autofs, automounted, nobrowse)

//***@sambafileserver.foo.bar/user <http://***@moe-180.gi.polymtl.ca/p302568> on /home/user (smbfs, nodev, nosuid, automounted, nobrowse, mounted by user)

The client is a Mac-Mini running OSX Yosemite with Java 8, update92. We
have no problems with Windows 10 clients.

Here are the pertinent configuration directives active on the Samba server:

kernel oplocks = yes
strict locking = No
oplocks = yes
level2 oplocks = yes
deadtime = 15
unix extensions = yes
wide links = yes
allow insecure wide links = yes

What's strange is this was working fine with Samba v3.6.23. We don't
have any problems with Windows clients.

Thank You!
--
Luc Lalonde, analyste
-----------------------------
Département de génie informatique:
École polytechnique de MTL
(514) 340-4711 x5049
***@polymtl.ca
-----------------------------

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

Jeremy Allison

2016-05-20 22:10:02 UTC

Permalink

Post by Luc Lalonde
Caused
by: java.io.IOException: An error occurred while locking file
"Operation not supported". A common reason is that the file system or
Runtime Environment does not support file locking for that location.
Please choose a different location, or disable file locking by passing
"-Dosgi.locking=none" as a VM argument.
at org.eclipse.osgi.internal.location.Locker_JavaNio.lock(Locker_JavaNio.java:49)
at org.eclipse.osgi.storagemanager.StorageManager.lock(StorageManager.java:388)
at org.eclipse.osgi.storagemanager.StorageManager.open(StorageManager.java:701)
at org.eclipse.osgi.storage.Storage.getChildStorageManager(Storage.java:1785)
at org.eclipse.osgi.storage.Storage.getInfoInputStream(Storage.java:1802)
at org.eclipse.osgi.storage.Storage.<init>(Storage.java:128)
at org.eclipse.osgi.storage.Storage.createStorage(Storage.java:87)
at org.eclipse.osgi.internal.framework.EquinoxContainer.<init>(EquinoxContainer.java:66)
... 10 more
mac-mini:MacOS user$ mount
/dev/disk0s2 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
map -fstab on /Network/Servers (autofs, automounted, nobrowse)
The client is a Mac-Mini running OSX Yosemite with Java 8, update92.
We have no problems with Windows 10 clients.
kernel oplocks = yes
strict locking = No
oplocks = yes
level2 oplocks = yes
deadtime = 15
unix extensions = yes
wide links = yes
allow insecure wide links = yes
What's strange is this was working fine with Samba v3.6.23. We
don't have any problems with Windows clients.

Turn off "kernel oplocks = yes", you don't need this
if all access is via Samba.

Do you have a debug level 10 log from the server
showing access requests at the time of the failure ?

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

Luc Lalonde

2016-05-24 16:50:01 UTC

Permalink

Hello Jeremy,

Sorry for the long delay for responding to your request (just came back
to the office after long Victoria day weekend).

I'm not sure if it's Ok to send such large attachements to the list.
So here's a Dropbox public link to download it:

https://www.dropbox.com/s/o2617jtqfbwlyhc/eclipse-java-samba-level10.log.gz?dl=0

All our connections to this share are not all via Samba. We use it for
Linux diskless (via kernel, Pam_Mount) and Windows clients.

That's why we use 'kernel oplocks = yes'. Maybe we don't need it? Could
it be the source of our problem?

Please don't hesitate to get in touch if you need more info...

Thanks for the help, Luc.

Post by Jeremy Allison

Turn off "kernel oplocks = yes", you don't need this
if all access is via Samba.
Do you have a debug level 10 log from the server
showing access requests at the time of the failure ?

--
Luc Lalonde, analyste
-----------------------------
Département de génie informatique:
École polytechnique de MTL
(514) 340-4711 x5049
***@polymtl.ca
-----------------------------

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

Jeremy Allison

2016-05-27 23:20:01 UTC

Permalink

Post by Luc Lalonde
Hello Jeremy,
Sorry for the long delay for responding to your request (just came
back to the office after long Victoria day weekend).
I'm not sure if it's Ok to send such large attachements to the list.
https://www.dropbox.com/s/o2617jtqfbwlyhc/eclipse-java-samba-level10.log.gz?dl=0
All our connections to this share are not all via Samba. We use it
for Linux diskless (via kernel, Pam_Mount) and Windows clients.
That's why we use 'kernel oplocks = yes'. Maybe we don't need it?
Could it be the source of our problem?
Please don't hesitate to get in touch if you need more info...

Start by removing all access other than Samba, and see if
you can still reproduce the problem. If not, then it's
the cross-protocol issue.

If you can still reproduce with only SMB clients, ping
me again :-).

Cheers,

Jeremy.

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

Luc Lalonde

2016-05-30 13:50:01 UTC

Permalink

Hello Jeremy,

Could you send me some references to the ‘cross-protocol issue’ (Bugzilla, documentation, etc)?

I’ll disable the ‘kernel oplocks’ and see what happens.

We’re getting all sorts of weirdness from our Mac SMB clients since we upgraded to Samba v4.4.3.

In particular, when we open a session with an OSX (Yosemite) client with SMB autommount directories, we see multiple SMBD processes that take up almost 100% of the Samba server’s processes.

I have to kill all of the SMBD processes on the server and reboot the client to get out of this situation!

If I can’t resolve this before classes begin in September, I’ll have to go back to using AFP (Netatalk) for our Mac labs.

My Windows 8.1 and Windows 10 clients work fine and do not cause this problem.

Best regards, Luc.

Post by Jeremy Allison

Start by removing all access other than Samba, and see if
you can still reproduce the problem. If not, then it's
the cross-protocol issue.
If you can still reproduce with only SMB clients, ping
me again :-).
Cheers,
Jeremy.

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba

Jeremy Allison

2016-06-01 22:40:02 UTC

Permalink

Post by Luc Lalonde
Hello Jeremy,
Could you send me some references to the ‘cross-protocol issue’ (Bugzilla, documentation, etc)?

https://sambaxp.org/archive_data/SambaXP2014-DATA/wed/track2/Mathias_Dietz-Sambainacrossprotocolenvironment.pdf

Post by Luc Lalonde
I’ll disable the ‘kernel oplocks’ and see what happens.

Ensure all access is via SMB-only and you won't have any of
these issues.

Post by Luc Lalonde
We’re getting all sorts of weirdness from our Mac SMB clients since we upgraded to Samba v4.4.3.
In particular, when we open a session with an OSX (Yosemite) client with SMB autommount directories, we see multiple SMBD processes that take up almost 100% of the Samba server’s processes.
I have to kill all of the SMBD processes on the server and reboot the client to get out of this situation!
If I can’t resolve this before classes begin in September, I’ll have to go back to using AFP (Netatalk) for our Mac labs.
My Windows 8.1 and Windows 10 clients work fine and do not cause this problem.

That's a completely different issue.

--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba