Musescore and NFS volumes
Musescore cannot see my NFS mounted volumes which are mounted on my Linux machines.
Is Musescore completely NFS unaware or is there something I am missing.
The volumes are mounted and every user account can access them from terminals, File Managers, browsers and all applications can load and save files to and from from NFS volumes. Only Musescore seems blind to NFS and do not even list them when opening or saving a file..
This usually happens if a program was written for Windows and then ported to Linux. Is this the case or what is the problem ?
Comments
I'm not aware of anything within MuseScore that would prevent it using files via NFS.
In reply to I'm not aware of anything… by Jojo-Schmitz
Well you should try it and see. It clearly is NFS unaware.
In reply to Well you should try it and… by retnev
I'm not on Linux, so no NFS either. However, whatever filesystem a file is on, this is not MuseScore's business and transparent to it. Also there is no code in MuseScore that would explicitly deny NFS.
And actually Musescore was originally developed on and for Linux and got ported to Mac and Windows.
In reply to I'm not on Linux, so no NFS… by Jojo-Schmitz
If you are not a Linux user then you would not know what this is about. EVERY other application can access the filesystem and it is transparent on Linux. ONLY musescore ignores the NFS volumes. The problem lies how musescore access the filesystem.
This is usually an old QT troltech problem as I can remember.
Does musescore use QT Troltech as a library ?
In reply to If you are not a Linux user… by retnev
I am occasionally a Linux User, actually since 25 years. But not on my desktop and not for musescore. Yes, it uses Qt (not QT).
In reply to I am occasionally a Linux… by Jojo-Schmitz
I am a Unix user for 30+ years.
Pedantics unfortunately wont fix the problem.
You can fix it by looking at the Qt code or Troltech or whoever owns the unfortunate toolkit.
This is a usual problem with the toolkit if you misunderstand the implementation.
In reply to I am a Unix user for 30+… by retnev
Well, the Musescore developers sure won't look into and fix Qt code. If there really is a bug in Qt reg. NFS, which a quick Google search didn't give hints at, do you have further information about that?
If there is, and there are possible workarounds in how Musescores uses the Qt libs, that might be am option.
I would prefer Linux users comment on this thread to make it more to the point:
Are there any Musescore users on Linux using NFS on the group ?
Can you verify the problem ?
Thanks
In reply to I would prefer Linux users… by retnev
You brought that up yourself a couple months ago, see https://musescore.org/en/node/270440
That and this post seem to be the only ones on this topic.
In reply to You brought that up yourself… by Jojo-Schmitz
Yes, thank you, but upgrading to Stretch did not help a bit, so I had to ask the question again.
The question now is:
Anyone using Linux with NFS volumes and have Musescore access all the NFS volumes ?
I would like to hear from Linux users please.
Thanks
I have been a Linux user on and off, a MuseScore user for somewhat longer, and an NFS user going way way way back, but can't recall ever trying that specific combination before (MuseScore on Linux using NFS), so i can't address that.
I can speak to the specific question you asked about whether MuseScore was written for Windows then ported to Linux. Answer: no, precisely the opposite. MuseScore began life on Linux and was only ported to Windows years later. But in any case, that shouldn't matter. MuseScore uses the Qt libraries, which is probably the most common way for cross-platform applications to be developed. If Qt supports NFS on a given platform, then probably so does MuseScore. I don't see anything in a quick search to suggest it doesn't, nor can I recall any other Linux users (besides you a few months ago) reporting problems here. So I have to assume it does work and it's just some configuration issue on your system. Have you carefully checked the left panel of the file dialogs to be sure you are accessing all of the available drives? I do recall there being some non-obvious things about how that works when I needed to access a volume mounted in some unusual way, but it was there when I expanded everything on the left.
In reply to I have been a Linux user on… by Marc Sabatella
Marc, thank you for the response.
I installed on several systems, same issue, NFS Volumes ignored.
I can migrate right down the \ directory and still no NFS is shown in the panel when opening or trying to save a file. Absolutely NONE of the 100's of applications running on the systems has any problems with NFS.
ONLY Musescore has problems with NFS and ONLY Musescore.
It definitely doesnt work and it must be an issue off Qt libraries. I had this problem about 10 years or so ago with an application and the problem was with implementation of Qt back then.
I can say 99% sure with this version, that Musescore doesnt access nfs.
On the lighter side: Curious that I am the only person that uses Musescore on Linux with NFS.
Did civilization come to a standstill lately ?
In reply to Marc, thank you for the… by retnev
If you mean that MuseScore doesn't show NFS shares in File > Open or File > Save as, It could be due to the use of non native QFileDialog on Linux. You should be able to set nativeDialogs to "true" in ~/.config/MuseScore/MuseScore.ini (or something similar) to run MuseScore with native dialogs.
In reply to If you mean that MuseScore… by [DELETED] 5
If so this might be a reason to enable that setting in preferences again (like it was in MuseScore 1.x). Maybe in the new advanced settings only.
In reply to Marc, thank you for the… by retnev
If it's a general issue with Qt, then LibreOffice at least should be experiencing the same. Probably other of the 100's of application you use - Qt is quite common in the Linux world. The non-native dialogs may indeed be masking your ability to see these filesystems in the dialogs. I wonder what happens if you just enter the pathname manually?
In reply to If it's a general issue with… by Marc Sabatella
If I save a file and enter the pathname to the nfs folder NOTHING is saved in the nfs directory.
In fact if I try to resave it it comes up with the previous filename and nfs directory path, but it dropped the "/" in front of the nfs volume, which is a serious problem. I assume since it saved my previous path, it is clear that it saves it without a / in front as the nfs volumes lives in / and without that it will never see the nfs volumes or save for that matter.
Just an observation about how musescore obviously "saved" my path wrong.
Attached 1.png as I tried to save it.
Attached 2.png as Musescore remembered it (clearly wrong)
In reply to If I save a file and enter… by retnev
That looks very stange. But since you consider yourself a knowlegeable linux user how about some trivial d ebuging? Open up a terminal, change to your NFS-mounted directory and run 'sudo fatrace -c'.
Then try to access a file in this directory from within MuseScore and watch the output in the terminal.
BTW, what's the version of MuseScore you are running? From the distro or home-made or from an App-Image?
In reply to That looks very stange. But… by rmattes
Did you figure out why musescore incorrectly remembers a save path ? That is pretty serious as it may indicate a backslash-less path sent to the operating system which clearly will cause this problem !
I create a new file in musescore then save it to the nfs volume /public by entering it in cl.
musescore completes save without error message. However the file is not there on the volume so musescore fails to alert the user of an error saving. ( it should at least check !! )
Doing fatrace on the client started before the above file creation and save...
root@ter01:/public# sudo fatrace -c
Absolute Nothing......
root@ter01:/public#
I obviously had to close down all other applications which uses nfs access.
It was libreoffice or other applications which created events like
root@ter01:/public# sudo fatrace -c
ls(2542): O /public
ls(2542): R /public
ls(2542): RC /public
root@ter01:/public#
In reply to Did you figure out why… by retnev
Then it's time for ye olde 'strace'.
$ strace -o <pid-of-your-mscore> -o trace.log
Also, after closing MuseScore, do a:
grep lastSaveDirectory ~/.config/MuseScore/MuseScore2.ini
Look at the log file, this will tell you where mscore actually tries to save the file (and probably succeeds,otherwise you'd see an error message).
Did you figure out why musescore incorrectly remembers a save path ?
No, but as I said, it's working here.
In reply to Then it's time for ye olde … by rmattes
just irritating pedantics, but I guess you meant strace -p .
I will see what I get.
Right there is the problem
root@ter01:/public# strace -p 5199 -o trace.log
strace: Process 5199 attached
^Cstrace: Process 5199 detached
root@ter01:/public# cat trace.log |grep -i 1.mscz
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a7220) = -1 ENOENT (No such file or directory)
stat("//home/user01/Documents/MuseScore2/Scores/public", 0x7ffe563a71e0) = -1 ENOENT (No such file or directory)
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a6fb0) = -1 ENOENT (No such file or directory)
stat("//home/user01/Documents/MuseScore2/Scores/public", 0x7ffe563a7120) = -1 ENOENT (No such file or directory)
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a7340) = -1 ENOENT (No such file or directory)
CLEARLY Muscore incorrectly expands the nfs foldername to mean a subfolder of the home directory musescore folder
/home/user01/Documents/MuseScore2/Scores/public/ and not /public/1.mscz which I entered.
This EXACTLY why it remembers public/filename and not /public/filename, the latter which is the nfs volume.
This is clearly a Musescore issue as I entered /public/a.mscz which is an nfs folder and Musescore then goes and try to find a directory public in my HOME directory.
In reply to Marc, thank you for the… by retnev
Slow, slow. I just checked: NFS file access works flawless here, I can create new files, save, open and 'save as' without any problems (both, server and client are Linux boxes, on different networks).
Why shouldn't it work? Userspace file system access on Unix and Linux always passes through the operating systems virtual filesystem layer, programs would have a hard time even finding out on what filesystem a file actually resides.
Anyway: there's a good chance that you miss-configured your NFS setup. Care to share?
In reply to Slow, slow. I just checked:… by rmattes
Good to know it works at least for someone.
However, the nfs server serves 6 remote terminals on the network with no NFS issues.
Runs other supposed Qt based applications such as Libreoffice (which was mentioned) without any hickups over remote X-sessions and natively and accesses NFS flawlessly.
Samba works with it too for the unfortunate do$e machine that needs to be connected.
ONLY Musescore has this problem.
Also see the path error Musescore interprets my nfs volumes as in a post above.
That is an obvious sign of trouble.
Which nfs config files do you want ?
In reply to Which nfs config files do… by retnev
Did you try that native file dialog thing mentioned above?
In reply to Which nfs config files do… by retnev
"Good to know it works at least for someone."
Hmm, looking at this forum at least it seems more like you are so far the only one with this problem...
As for the config files - there really are only two interesting bits: the line in the servers /etc/exports where you export the file system and the mount options on the client box (and, aof course the NFS version you are using).
In reply to "Good to know it works at… by rmattes
Rather than the nfs sever, I would guess that Qt has nsBIND problems.
I can now remember that was an issue about 10 years ago using Qt in a development when it still was Troltech.
They were sloow to fix trouble, so the problem might still persist.
On the nfs server running
nfs-common (1:1.3.4-2.1ubuntu2)
nfs-kernel-server (1:1.3.4-2.1ubuntu2)
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=17.10
DISTRIB_CODENAME=artful
DISTRIB_DESCRIPTION="Ubuntu 17.10"
NAME="Ubuntu"
VERSION="17.10 (Artful Aardvark)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 17.10"
VERSION_ID="17.10"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=artful
UBUNTU_CODENAME=artful
One of the 15 volumes that cannot be accessed by Musescore but available on ALL other applications. Musescore is the SOLE application with nfs trouble.
On the NFS -server /etc/exports
/public *(rw,no_root_squash,sync,secure,subtree_check)
mount on client is just
mount -t nfs nfsserver:/volume pathtoclientvolume
Cant see why this can be the issue.
In reply to Rather than the nfs sever, I… by retnev
"Rather than the nfs sever, I would guess that Qt has nsBIND problems."
Please, this is rubbish. Neither Qt nor MuseScore have anything whatsoever to do with the NFS protocol.
That's all handled by your kernel. Pretty much the only way an application might even notice the underlying file system type is if it (wrongly) expects local file system locking semantics (a problem that tends to show up with databases and servers. I strongly doubt that MuseScore has such problems).
"I can now remember that was an issue about 10 years ago using Qt in a development when it still was Troltech. They were sloow to fix trouble, so the problem might still persist."
Since you seem to have more info on this than anyone else here would you care to share some information? My Google foo found nothing relevant ....
/public *(rw,no_root_squash,sync,secure,subtree_check)
Let's really hope this is not your actual configuration - that's a giganormous security hole you have.
/no_root_squash/ on a world-mountable share? I guess you already tried the obvious no_subtree_check, esp. since subtree_check doesn't make sense here?
What does the 'fatrace' logging show?
In reply to "Rather than the nfs sever,… by rmattes
It's fine, your trash is my gold.
I used Qt years ago with a company with a troltech license. In my opinion it was the worst toolkit ever. The craziest bind problems. They seemed to try and implement their own bind daemons under different names and mimic all other protocols to become platform independent. I really don like it and will never use it. it's a ratsnest. Probably why troltech got sold.
As for mounting nfs on ..
The best thing I ever did.
As soon as someone try something the system locks up.
I started to use it like this years ago and wont go back.
Dont drink all the coolaid......
What is detestible for one is great for another and for me it worked great for almost 20 years.
Never a breach.
But, I guess you believed that SELinux was a good thing too....?
Maybe you can google and see how I exposed it about 8 years ago for what it was.
That is a gaping security hole on steroids and to add the entire SUDO garbage is nothing else than to make it easier for hackers. Why the Linux community fell for that hook-line & sinker I dont know. It is easy to see the malicious intent in order to suggest something like SUDO. They in effect transferred the root password to a user account and password. I mean really !?
Userspace is much more promiscuous and you get a user's password much easier than a root password. (Therefore it was peddled as Koolaid).
First thing I do is to rid my systems of sudo, so that there is no chance anyone can get root access through a user account. By default systems now install with a sudo user. What a gaping security hole on every general users system. This was all invented to circumvent the root user account.
Second I mount nfs on / and have good reason to do it from experience.
And so on.
YOUR security is not MY security and your opinion is just that.
An opinion.
Vice Versa.
I didnt get a response after clearly showing that Musescore has the problem on Linux for misinterpreting nfs volumes present and try to save data to them in the nfs folder in the user's account. As I mentioned before "/public" is the nfs volume used.
In another post I also showed that Musescore incorrectly remember path names by ommiting the / from nfs directory paths. It returns NOT what was entered.
Since I dont get a response, should I post it in bug tracker ?
Right there is the problem
root@ter01:/public# strace -p 5199 -o trace.log
strace: Process 5199 attached
^Cstrace: Process 5199 detached
root@ter01:/public# cat trace.log |grep -i 1.mscz
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a7220) = -1 ENOENT (No such file or directory)
stat("//home/user01/Documents/MuseScore2/Scores/public", 0x7ffe563a71e0) = -1 ENOENT (No such file or directory)
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a6fb0) = -1 ENOENT (No such file or directory)
stat("//home/user01/Documents/MuseScore2/Scores/public", 0x7ffe563a7120) = -1 ENOENT (No such file or directory)
stat("/home/user01/Documents/MuseScore2/Scores/public/1.mscz", 0x7ffe563a7340) = -1 ENOENT (No such file or directory)
CLEARLY Muscore incorrectly expands the nfs foldername to mean a subfolder of the home directory musescore folder
/home/user01/Documents/MuseScore2/Scores/public/ and not /public/1.mscz which I entered.
This EXACTLY why it remembers public/filename and not /public/filename, the latter which is the nfs volume.
This is clearly a Musescore issue as I entered /public/a.mscz which is an nfs folder and Musescore then goes and try to find a directory public in my HOME directory.
Reply
In reply to I didnt get a response after… by retnev
NFS is legendary for being cantankerous talking with linux ....
I've had issues with different applications and different versions of NFS I will be surprised if it is a MuseScore issue.
Wonder if you have tried to mount with following format mount -t nfs -o umask=0022,gid=XXX,uid=YYY 192.168.1.5:/NFS_SHARE /mnt/nfs_repo/ where the ipaddress of your repo is replaced with the 192....
In reply to NFS is legendary for being… by Ron Southworth
I'm using Linux than more as 20 years ago (and during a short time MuseScore too), but never used NFS. So excuse if I'm wrong and misunderstand the topic because of my limited technical skills, but maybe here are some useful resources?: https://doc.qt.io/archives/qtextended4.4/running-qtextended.html
In reply to NFS is legendary for being… by Ron Southworth
I am a certified linux sysadmin.
I know how nfs work.
AND
There is about 1000+ processes on this server that uses NFS all WITHOUT any trouble, The only application that has problems with NFS is Musescore and from the debug in my last post the reason is clear..
Musescore ignore the NFS mounts which are mounted and used by countless applications.,
The problem is somewhere with Musescore's interpretation of NFS through Qt. It is most likely triggered by something.
There is no way an NFs volume is mounted and can be accessed by everything on a Linux client even Libreoffice which purportedly also uses Qt, and I have NO problem with that.
It is only Musescore, and the wrong path saved by musescore when you enter it is a clear indication that Musescore is at fault as it drops the / from the path which will disallow it from seeing the NFS mount and will default to the NFS directory name in the user account. Simple.
Probably a misconfiguration of the Qt libraries, but it is no my place to figure out what is wrong in Musescore.