multi-user installation does not work when user data is directed to a network drive

[MarkosMitsos]

• [x] I have read and acknowledged this HOWTO article:
  Submitting a MiKTeX problem report

1. Background

I'm installing MiKTeX in a multi-server and multi-user environment. I need the user data to reside on a network drive in order to use it properly. That fore I use the corresponding setup parameter "--user-data="<APPDATA>\MiKTeX\data"; %APPDATA% points to a network drive. For some time now I'm experiencing a fatal error with log4cxx when doing so.

To exclude factors like network performance, firewall, virus scanner or group policies, I created a minimal example on an isolated, free laptop. All data and shares involved are strictly confined to the laptop's local drive and no virtualization is involved.

2. Preparation I downloaded miktexsetup-5.5.0+1763023-x64.zip and, with its help, an "essential" package set. The first is included the second omitted for reasons of data volume. miktexsetup-5.5.0+1763023-x64.zip

On the laptop, I created a folder C:\MiKTeX that I mapped twice a) As local drive M: (using the DOS command subst) b) As "network" drive N: (using Properties/Sharing/Advanced Sharing/... to make it available in the "network") One the folder is the designated target of MiKTeX user data in each of the test installations.

I created primitive scripts in order to be able to repeat installation steps quickly a) MiKTeXsetup_user_data_.cmd installs MiKTeX with a minimal number of parameters using M or N as target for user data b) MiKTeXupdate_.bat executes pseudo update/upgrade to eliminate the corresponding "major issue" from the miktex report c) ini_admin_.bat creates a miktex report and tests its stability under the command "miktex --admin fndb refresh" in the admin context d) ini_user_.bat creates a miktex report and tests its stability under "miktex fndb refresh" in the user context They are designed to be run from a folder called C:\temp\test_essential. All scripts are included in "scripts.zip". ini_user_N.bat produces the error and leaves the system unusable for the user.

scripts.zip

3. Test installations

a) I started each test cycle by completely de-installing MiKTeX and manually removing any vestiges like user data from the system.

b) user data on local drive M I used the scripts 2.a-d to install MiKTeX with the user data mapped to M:\data i) install_M.txt records the installation ii) report_admin_M.txt contains the miktex admin report iii) check_admin_M.txt documents the reaction of miktex admin report to "miktex --admin fndb re-fresh" iv) report_user_M.txt contains the miktex user report v) check_user_M.txt documents the reaction of miktex user report to "miktex fndb refresh" vi) the folders miktex_admin_M and miktex_user_M contain the complete MiKTeX logging corre-sponding to i-v. All script outputs are included in "results_laptop_free.zip", the log folders as "miktex_admin_M.zip" and "miktex_user_M.zip" respectively. No problem occurred. miktex_user_M.zip miktex_admin_M.zip

c) user data on "network" drive N I used the scripts 2.a-d to install MiKTeX with the user data mapped to N:\data i) install_N.txt records the installation ii) report_admin_N.txt contains the miktex admin report iii) check_admin_N.txt documents the reaction of miktex admin report to "miktex --admin fndb re-fresh" iv) report_user_N.txt contains the miktex user report v) check_user_N.txt documents the reaction of miktex user report to "miktex fndb refresh" vi) the folders miktex_admin_N and miktex_user_N contain the complete MiKTeX logging corre-sponding to i-v. All script outputs are included in "results_laptop_free.zip", the log folders as "miktex_admin_N.zip" and "miktex_user_N.zip" respectively. The problem can be seen in v, after refreshing the FNDB the user data is not usable any more. miktex_admin_N.zip miktex_user_N.zip results_laptop_free.zip

d) b and c, especially b.v and c.v, use the same (local) data. However, b works fine whereas c fails catastrophically.

4. conclusion I suspect an error in MiKTeX or in [the configuaration of] log4cxx itself. Could you please check this out?

If any additional information is needed, please let me know! Thank you for your help!

[ragibson]

I think this is a duplicate of https://github.com/MiKTeX/miktex/issues/928 where @edocevoli mentioned it is an unsupported use case.

Seems that your setup is not compatible with MiKTeX requirements. I will check to see if I can update the documentation (system requirements). Something like: MiKTeX requires that the data directory is on a Windows drive.

You are getting basically the same error

Info: path="N:\data\miktex/data/le\"
Source: Libraries\MiKTeX\Core\FileSystemWatcher\win\winFileSystemWatcher.cpp
Line: 150

Sorry, but "MiKTeX Configuration Utility" did not succeed.
log4cxx: No appender could be found for logger (initexmf).
log4cxx: Please initialize the log4cxx system properly.

versus

Info: path="\\SHARE\miktex-portable\texmfs/config\miktex/data/le\"
Source: Libraries\MiKTeX\Core\FileSystemWatcher\win\winFileSystemWatcher.cpp
Line: 150

Sorry, but "MiKTeX Configuration Utility" did not succeed.
log4cxx: No appender could be found for logger (initexmf).
log4cxx: Please initialize the log4cxx system properly.

[MarkosMitsos]

Hello Ryan, may I ask a question: is "Windows drive" understood to be a strictly local drive? In my example I'm using a "network" drive, but it is faked, the data lies on C:\

On the other hand, one of MiKTeX's strengths is the support of a multi-user system. This leads naturally to a multi-server one. Is it not natural for such a system to keep the user data separately (on a network drive)?

Thank you for your help and explanations!

[ragibson]

is "Windows drive" understood to be a strictly local drive?

It looks like that is the case at the moment.

In any case, I was able to replicate this in a Windows 10 VM and work around it with a symlink for the networked user directories. Every drive letter here other than C:\ is a network location.

C:\Users\Ryan-VM\Desktop>mklink /D data-link "Y:\data"
symbolic link created for data-link <<===>> Y:\data

and then in a separate command prompt,

C:\Users\Ryan-VM\Desktop>X:\miktexsetup_standalone.exe ^
--trace --verbose ^
--local-package-repository=X:\miktex ^
--user-config=C:\Users\Ryan-VM\Desktop\data-link ^
--user-data=C:\Users\Ryan-VM\Desktop\data-link ^
--user-install=C:\Users\Ryan-VM\Desktop\data-link ^
install --package-set=essential

I will note that the resulting installation is incredibly janky and frequently throws internal errors from miktex-pdftex. I do not think MiKTeX supports the functionality needed for this sort of setup (perhaps I/O Completion Ports).

[ragibson]

Also note that MiKTeX's deployment tutorial for rolling the software out to multiple users appears to assume local installation on each of the client machines.

[MarkosMitsos]

OK, I still hope you can find a solution. By the way, it worked fine for us for something like 7 years, with a common root on a network drive, and user data, config and install all on network drives. Then we had a break of more than two years, because IT was involved in a major project, and afterwards we encountered the log4cxx problem in the newet version --- but only for user data, everything else is still on network drives.

Even if the problem is no so easily solved, couldn't you add it as a requirement? I think that the idea of having a great number of users, each working on a different machine every day, and synchronizing user content through separate drives does makes sense, or not?

Again thank you for bearing with me...

[ragibson]

If the problem is upstream in log4cxx, it might be fixed by https://github.com/MiKTeX/miktex/issues/1316.

Up to @edocevoli if this is a supported use case, though he'd probably accept a PR for it. Looking back, I think his earlier comment may have been about a Windows client using networked directories from a Linux installation.

[MarkosMitsos]

Yes, our problem seems to be log4cxx (and hopefully only this) and possibly a version is involved (but which version is installed on a machine is rather opaque)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[MarkosMitsos]

just added a comment because the stale bot was threaneting to close the issue...

[knappmk]

I am facing the same problem when I want to deploy MiKTeX at our university. We use Romaing profiles (user profiles are synchronized on servers). Since I don't want to pre-install all packages, a user must be able to install packages in "userspace" if necessary. However, if the directory is not located in a network folder (but in %APPDATA%), the data would have to be copied with every logon/logoff process. Depending on the user, several Gigabytes could have to be copied for this alone - hardly practical. If the directory is defined outside the user directory (%USERPROFILE%), the data is no longer available when the PC is changed. The problem still occurs with version 23.12. The workaround from @ragibson does not work for me (same error).

[ragibson]

However, if the directory is not located in a network folder (but in %APPDATA%), the data would have to be copied with every logon/logoff process. Depending on the user, several Gigabytes could have to be copied for this alone - hardly practical. If the directory is defined outside the user directory (%USERPROFILE%), the data is no longer available when the PC is changed.

I've fixed a similar issue in the past by changing the installation directory to a local user directory, and then the remaining configuration files in %APPDATA% amount to around 10 MB.

That said, that solution may still have issues if running from a network location.

[knappmk]

In my case, the problem may not be as serious as it previously seemed to me. Since the packages are only installed in user-install, the problem can be avoided by leaving user-data at the default value and only redirecting user-install and user-config to a network share. However, I do not yet know whether there are any undesirable side effects in this configuration. So far it works and the packages installed by the user do not seem to have to be copied during the logon/logoff process.