Trying to mount Azure Files snapshot with following command: >sudo /bin/mount -t cifs //storageAccountName.file.core.windows.net/fileShareName /home/userName/mount -o vers=3.0,credentials=/home/userName/cred,dir_mode=0444,file_mode=0444,serverino,snapshot=132888855100000000 It fails with: >mount error(22): Invalid argument Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg) /var/log/kern.log contains: >Feb 9 18:16:58 VmName kernel: [ 3963.812792] cifs: Bad value for 'snapshot' Without snapshot option it works as expected. OS details from hostnamectl: > Virtualization: microsoft Operating System: Ubuntu 20.04.3 LTS Kernel: Linux 5.11.0-1028-azure Architecture: x86-64 it appears to be a regression, works with 5.8, OS details for 5.8 from hostnamectl: > Virtualization: microsoft Operating System: Ubuntu 20.04.3 LTS Kernel: Linux 5.8.0-1043-azure Architecture: x86-64 Commit "24e0a1eff9e2b9835a6e7c17039dfb6ecfd81f1f" looks suspicious: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/fs/cifs/fs_context.c?h=v5.17-rc3&id=24e0a1eff9e2b9835a6e7c17039dfb6ecfd81f1f in fs/cifs/fs_context.c there is this line: >"fsparam_u32("snapshot", Opt_snapshot)," I think the issue with that is, it should be "fsparam_u64" as snapshot value is expected to be 64 uint. But since it is checked again u32 it fails with "Bad value" message. If you look for this part of code (still in fs/cifs/fs_context.c): > case Opt_snapshot: > ctx->snapshot_time = result.uint_32; You can see it is even assigned to the 64bit "__u64 snapshot_time" value in "smb3_fs_context" (fs/cifs/fs_context.h) struct. Also cifs-utils sends it as "%llu" and it always did: https://salsa.debian.org/samba-team/cifs-utils/-/blob/master/mount.cifs.c#L1296 If I am not wrong fix should be easy. If possible please merge up to 5.11.
Good catch. Patch tentatively pushed to cifs-2.6.git for-next pending additional testing/review and marked for stable v5.11+
Created attachment 300442 [details] fix for snapshot mounts (due to incorrect u32 vs u64 in this option due to conversion to the new mount API)