Ubuntu xenial has GDAL 1.11.3 and the ubuntugis-unstable PPA has GDAL 2.1.0, and quite a lot of changes to the NetCDF driver have been made between those release. Valgrid reports the following for the gdalinfo command with the gdal & netcdf debug packages installed: ==9254== Invalid read of size 1 ==9254== at 0x4C30F62: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==9254== by 0x53F2EC2: NCDFSafeStrcat(char**, char*, unsigned long*) (netcdfdataset.cpp:6268) ==9254== by 0x53F3124: NCDFGetAttr1(int, int, char const*, double*, char**, int) (netcdfdataset.cpp:6426) ==9254== by 0x53F3DC3: NCDFGetAttr (netcdfdataset.cpp:6449) ==9254== by 0x53F3DC3: netCDFDataset::ReadAttributes(int, int) (netcdfdataset.cpp:4085) ==9254== by 0x53FBCF1: netCDFDataset::Open(GDALOpenInfo*) (netcdfdataset.cpp:4809) ==9254== by 0x554A10C: GDALOpenInternal(GDALOpenInfo&, char const* const*) (gdaldataset.cpp:2314) ==9254== by 0x554A365: GDALOpenInternal(char const*, GDALAccess, char const* const*) (gdaldataset.cpp:2263) ==9254== by 0x402BB4: ??? (in /usr/bin/gdalinfo) ==9254== by 0x642B82F: (below main) (libc-start.c:291) ==9254== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==9254== ==9254== ==9254== Process terminating with default action of signal 11 (SIGSEGV) ==9254== Access not within mapped region at address 0x0 ==9254== at 0x4C30F62: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==9254== by 0x53F2EC2: NCDFSafeStrcat(char**, char*, unsigned long*) (netcdfdataset.cpp:6268) ==9254== by 0x53F3124: NCDFGetAttr1(int, int, char const*, double*, char**, int) (netcdfdataset.cpp:6426) ==9254== by 0x53F3DC3: NCDFGetAttr (netcdfdataset.cpp:6449) ==9254== by 0x53F3DC3: netCDFDataset::ReadAttributes(int, int) (netcdfdataset.cpp:4085) ==9254== by 0x53FBCF1: netCDFDataset::Open(GDALOpenInfo*) (netcdfdataset.cpp:4809) ==9254== by 0x554A10C: GDALOpenInternal(GDALOpenInfo&, char const* const*) (gdaldataset.cpp:2314) ==9254== by 0x554A365: GDALOpenInternal(char const*, GDALAccess, char const* const*) (gdaldataset.cpp:2263) ==9254== by 0x402BB4: ??? (in /usr/bin/gdalinfo) ==9254== by 0x642B82F: (below main) (libc-start.c:291) ==9254== If you believe this happened as a result of a stack ==9254== overflow in your program's main thread (unlikely but ==9254== possible), you can try to increase the size of the ==9254== main thread stack using the --main-stacksize= flag. ==9254== The main thread stack size used in this run was 8388608. ==9254== ==9254== HEAP SUMMARY: ==9254== in use at exit: 1,789,968 bytes in 6,243 blocks ==9254== total heap usage: 11,605 allocs, 5,362 frees, 2,340,923 bytes allocated ==9254== ==9254== LEAK SUMMARY: ==9254== definitely lost: 0 bytes in 0 blocks ==9254== indirectly lost: 0 bytes in 0 blocks ==9254== possibly lost: 0 bytes in 0 blocks ==9254== still reachable: 1,789,968 bytes in 6,243 blocks ==9254== of which reachable via heuristic: ==9254== length64 : 56,956 bytes in 61 blocks ==9254== newarray : 288 bytes in 16 blocks ==9254== suppressed: 0 bytes in 0 blocks ==9254== Rerun with --leak-check=full to see details of leaked memory ==9254== ==9254== For counts of detected and suppressed errors, rerun with: -v ==9254== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault The GDAL 1.11.3 code in question (frmts/netcdf/netcdfdataset.cpp): 6265 CPLErr NCDFSafeStrcat(char** ppszDest, char* pszSrc, size_t* nDestSize) 6266 { 6267 /* Reallocate the data string until the content fits */ 6268 while(*nDestSize < (strlen(*ppszDest) + strlen(pszSrc) + 1)) { 6269 (*nDestSize) *= 2; 6270 *ppszDest = (char*) CPLRealloc((void*) *ppszDest, *nDestSize); 6271 #ifdef NCDF_DEBUG 6272 CPLDebug( "GDAL_netCDF", "NCDFSafeStrcat() resized str from %ld to %ld", (*nDestSize)/2, *nDestSize ); 6273 #endif 6274 } 6275 strcat(*ppszDest, pszSrc); 6276 6277 return CE_None; 6278 } ncdump does handle the file successfully and reports that the ctth_quality variable has the ushort type, GDAL 2.1.0 added full read/write support for new NetCDF4 types like this. So I think we can conclude that GDAL 1.11.3 in xenial doesn't support NetCDF4 sufficiently. Since backporting a fix for this issue doesn't seem feasible, and the GIS packages in Ubuntu are not actively maintained (because the manpower is in Debian), a fix for the package in xenial can pretty much be ruled out. Using the newer packages from UbuntuGIS is a good alternative until the next LTS.