MooseFS PRO only.
Windows Client problems
This page starts from what you see on the Windows machine with the MooseFS drive: the disk that cannot be opened, the letter missing from Explorer, the warning about time synchronization. The page also names the two readouts that the diagnoses below use, .params and the Windows Event Log. Problems common to every mount, whatever the system, are collected in client and mount problems.
Connection parameters
If the Windows Client is correctly connected to the cluster, a new drive letter appears in the system. A special file system object is also created during the connection. This object is not visible from the system, but it can be read as a regular file from PowerShell or the command line. This object is called .params and shows the current connection parameters. To read the contents of this object, type this command in PowerShell: cat M:\.params. The output looks similar to the following example:
PS C:\Users\tt> cat m:\.params
MASTER_HOST: mfsmaster.mfs.lan
MASTER_PORT: 9421
MASTER_BIND: ( EMPTY )
MASTER_PATH: /
MASTER_PASSWORD: ( **** )
MOUNT_POINT: M:
PREFERRED_LABELS: ( EMPTY )
READ_CACHE_MB: 100
WRITE_CACHE_MB: 128
IO_TRY_CNT: 30
IO_TIMEOUT: 0
MIN_LOG_ENTRY: 5
READAHEAD_LENG: 2097152
READAHEAD_TRIGGER: 20971520
ERROR_ON_LOST_CHUNK: 0
ERROR_ON_NO_SPACE: 0
UID2SID: LDAP
LDAP_HOST:
LDAP_PORT: 0
LDAP_USER_DN: ( EMPTY )
LDAP_USER_PASS: ( EMPTY )
LDAP_BASE_DN: DC=mfs,DC=lan
MFSIO Version: 4.43.0-pro (build 1593)
MooseFS Windows Client Version: 0.10.1
In Command Prompt, use this command: type M:\.params
MooseFS Operations Log
The Windows Client logs each operation performed on the Windows Client inside a special file system object. This log helps with any kind of debugging of Windows Client behavior. For example, it helps to debug undesirable application behavior or application performance. The operation log shows what is happening on the Windows Client side.
The special file system object is named .oplog. Open it from PowerShell as in this example:
cat M:\.oplog
The output is constantly updated. To stop it, press Ctrl+C.
12.13 16:57:06.122: uid:10010 gid:10010 pid:3620 cmd:open_file path:/desktop.ini status:No such file or directory
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:0 status:OK
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:1 status:OK
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:1 status:OK
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.123: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:1 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:0 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:1 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:0 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:read_directory path:/ fd:1 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:1 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.124: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:0 status:OK
12.13 16:57:06.125: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:0 status:OK
12.13 16:57:06.126: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.126: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:0 status:OK
12.13 16:57:06.126: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:1 status:OK
12.13 16:57:06.126: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:1 status:OK
12.13 16:57:06.127: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:1 status:OK
12.13 16:57:06.204: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:2 status:OK
12.13 16:57:06.205: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:2 status:OK
12.13 16:57:06.205: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:2 status:OK
12.13 16:57:06.217: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:2 status:OK
12.13 16:57:06.218: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:2 status:OK
12.13 16:57:06.218: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:2 status:OK
12.13 16:57:06.218: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:2 status:OK
12.13 16:57:06.218: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:2 status:OK
12.13 16:57:06.482: uid:10010 gid:10010 pid:3620 cmd:open_directory path:/ fd:2 status:OK
12.13 16:57:06.483: uid:10010 gid:10010 pid:3620 cmd:stat path:/ fd:2 status:OK
12.13 16:57:06.483: uid:10010 gid:10010 pid:3620 cmd:close path:/ fd:2 status:OK
Time synchronization
When a time difference between the Master Server and the Windows Client is detected, the system Event Log shows a warning from the "MooseFS" source:
Module=MooseFS
Message=time desync between client and master is higher than a second -
it might lead to strange atime/mtime behaviour -
consider time synchronization in your moosefs cluster
This warning means that the Windows® machine and the MooseFS Master Server do not use the same NTP servers, or that there is no time synchronization between these components.
In a production environment where all Windows® machines use Active Directory for time synchronization, also synchronize all MooseFS components (Master Servers, Chunkservers, Metaloggers, Linux Clients) to the Active Directory clock.
Can't open MooseFS disk
If the Windows Client connected to the cluster and the new drive letter is available in the system, but you cannot open the device, then check the Event Log first:
Level Date and Time Source Event ID Task Category
Information 13.12.2022 17:54:34 MooseFS 1 None Module=MooseFS Message=DokanCreateFileSystem success
Information 13.12.2022 17:54:34 MooseFS 1 None Module=MooseFS Message=Mounted
Information 13.12.2022 17:54:34 MooseFS 1 None Module=MooseFS Message=Windows client is allowed
These messages mean that the connection has been accepted and that the file system has been created on the Windows® machine. Now, check the connection parameters in PowerShell with this command:
cat M:\.params
...
MASTER_PATH: /winmfs
...
MFSIO Version: 4.43.0-pro (build 1593)
MooseFS Windows Client Version: 0.10.1
If you can read this object, the client is connected to the MooseFS cluster.
Next, make sure that the user who is currently logged in has the correct permissions.
To check this, use PowerShell again and list all objects on the MooseFS disk:
PS C:\Users\test> ls m:\
ls : Access to the path 'M:\' is denied.
At line:1 char:1
+ ls m:\
+ ~~~~~~
+ CategoryInfo : PermissionDenied: (M:\:String) [Get-ChildItem], UnauthorizedAccessException
+ FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand
In this example, the user accesses the /winmfs subfolder on a MooseFS cluster. The user test, who is logged in through Active Directory, has the value 10010 assigned to uidNumber and gidNumber in the object tree of Active Directory:
uid=10010
gid=10010
The /winmfs folder on the MooseFS cluster belongs to a different uid and a different gid:
drwxrwx--- 2 1000 1000 2.0M Dec 13 15:58 winmfs
That's why the Windows Client refuses to access the /winmfs share.
The same situation can occur if an Active Directory user does not have uidNumber and gidNumber assigned in the object tree of Active Directory.
The mount does not show up in Explorer
If the drive letter does not appear in Explorer, the cause may be that the client's service mounted the drive before Explorer had fully started. This happens most often right after system startup.
The checks described in Can't open MooseFS disk may all pass: the connection parameters can be read and the share is accessible from the command line. If the drive is still not visible in Explorer, restart explorer.exe and/or restart the MooseFS Pro Windows Client service, as described in managing the client's service.